테마
08. 인증·인가·접근 통제·IDOR
로그인한 사용자가 곧 모든 권한을 가진 사용자는 아니다. 현대 웹 보안에서 가장 자주 터지는 문제는 "누가 로그인했는가"보다 "이 사용자가 이 자원에 접근해도 되는가"를 서버가 제대로 확인하지 않는 데서 나온다.
학습 목표
- 인증(AuthN)과 인가(AuthZ)의 차이를 설명할 수 있다.
- 원문의 파라미터 변조, URL 접근 제한 미흡을 현대적으로
Broken Access Control,IDOR관점에서 이해할 수 있다. - 객체 단위 소유권 검증이 왜 중요한지 설명할 수 있다.
- 비밀번호 저장, MFA, 관리자 재인증 같은 계정 보호 요소를 접근 통제와 함께 볼 수 있다.
1. 인증과 인가는 다르다
| 개념 | 질문 |
|---|---|
| 인증(AuthN) | 이 사용자가 누구인가 |
| 인가(AuthZ) | 이 사용자가 이 동작을 해도 되는가 |
많은 서비스가 인증은 잘하지만 인가에서 무너진다.
- 로그인은 되어 있다
- 하지만 다른 사람의 게시글 ID를 넣으면 수정이 된다
- 일반 사용자가 관리자 전용 API를 호출할 수 있다
- URL을 직접 입력하면 숨겨진 화면이 열린다
이런 문제를 원문에서는 파라미터 변조, URL 접근 제한 미흡으로 설명했는데, 현재는 더 넓게 Broken Access Control로 보는 편이 맞다.
2. IDOR는 왜 자주 생길까?
IDOR(Insecure Direct Object Reference)는 객체 식별자를 직접 받아 처리하면서 권한 검증이 빠질 때 자주 생긴다.
중요한 점은 ID 자체가 노출된 것이 문제가 아니라, 서버가 소유권과 권한을 확인하지 않은 것이 문제라는 점이다.
3. 안전한 객체 접근 패턴
잘못된 방향
GET /posts/123요청이 오면 바로 123번 게시글 조회DELETE /users/42요청이 오면 관리자 여부 확인 없이 삭제- 프론트엔드에서 버튼을 숨겼으니 서버도 안전하다고 생각
더 나은 방향
- 현재 로그인 사용자의 권한과 소유 관계를 함께 조건에 넣는다
- 관리자 기능은 서버 측에서 별도 역할 확인을 한다
- 화면에서 숨기는 것과 서버 차단을 분리한다
예를 들면 다음과 같은 사고방식이 필요하다.
- "이 게시글 ID가 존재하는가?"가 아니라
- "이 사용자가 이 게시글을 볼 수 있는가?"를 먼저 묻는다
4. URL을 숨기는 것은 방어가 아니다
원문에는 관리자 페이지 이름 추측, robots.txt, 파일 이름 규칙 같은 이야기가 나온다.
이 내용은 현실적인 공격 단서가 될 수는 있지만, 방어 관점에서는 우선순위가 아니다.
왜냐하면 다음이 더 중요하기 때문이다.
- 관리자 URL을 숨겨도 서버 검증이 없으면 무의미
robots.txt는 크롤링 안내 문서이지 접근 제어 장치가 아님- 프론트엔드 라우트 보호만으로는 API를 막을 수 없음
즉, 보이지 않게 만드는 것이 아니라 들어와도 못 하게 만드는 것이 본질이다.
5. 역할 기반 권한과 객체 소유권을 함께 본다
접근 통제는 보통 두 층으로 생각하면 정리하기 쉽다.
| 층 | 예시 |
|---|---|
| 역할 기반 권한 | 관리자만 회원 목록 조회 가능 |
| 객체 소유권 기반 권한 | 본인 게시글만 수정 가능 |
둘 중 하나만 있으면 빈틈이 생기기 쉽다.
- 관리자 여부만 보면 일반 사용자 간 데이터 경계가 무너질 수 있다
- 소유권만 보면 운영자 기능이 부족할 수 있다
그래서 서버 코드는 보통 현재 사용자 역할 + 대상 객체 관계를 같이 확인해야 한다.
6. 계정 보호도 접근 통제의 일부다
인가를 잘 짜도 계정 보호가 약하면 결국 권한이 탈취될 수 있다.
현재 기준에서 최소한 봐야 할 것은 다음과 같다.
- 비밀번호는
argon2id또는bcrypt로 저장 - 로그인 시도 제한과 이상 징후 감지
- 관리자나 민감 계정에 phishing-resistant MFA 적용 검토
- 가능하면 Passkeys / WebAuthn 같은 피싱 저항성이 높은 수단을 우선 검토
- 비밀번호 변경, 관리자 권한 변경, 결제 변경 시 재인증
- 세션과 토큰 수명 관리, 로그아웃 시 무효화
원문처럼 단순히 관리자 계정 생성 후 기능 테스트를 하는 수준에서 끝내지 말고, 권한이 탈취될 때까지 포함한 흐름을 봐야 한다.
7. 로그와 감사 흔적도 필요하다
접근 통제는 차단만이 아니라 탐지도 중요하다.
- 권한 없는 자원 접근 시도
- 관리자 기능 접근 시도
- 반복적인 객체 ID 탐색 패턴
- 비정상적인 다운로드 시도
이런 이벤트가 구조화된 로그로 남아야 한다.
다만 로그에는 비밀번호, 세션 토큰, 주민번호 같은 민감정보를 남기지 않는다.
8. 원문을 현대적으로 다시 정리하면
| 원문 주제 | 현재식 표현 |
|---|---|
| 파라미터 변조 | IDOR/BOLA와 서버 측 권한 검증 문제 |
| URL 접근 제한 미흡 | Broken Access Control의 전형적인 사례 |
| 관리자 페이지 추측 | 보조 정보일 뿐, 핵심 방어는 서버 측 인가 |
| 패스워드 확인 로직 | 민감 조작 재인증과 비밀번호 저장 정책까지 확장 |
9. PR 리뷰 체크리스트
- 모든 자원 조회, 수정, 삭제 요청에 서버 측 권한 검증이 있는가
- 프론트엔드 UI 숨김과 별도로 API 차단이 구현되어 있는가
- 객체 ID만 맞으면 접근되는 코드 경로가 없는가
- 관리자 기능에 역할 확인과 감사 로그가 있는가
- 비밀번호 저장이
argon2id또는bcrypt기반인가 - 민감 동작에 재인증이나 MFA가 필요한가
핵심 정리
- 인증은 신원 확인이고, 인가는 권한 확인이다
- 현재 웹 보안에서 가장 흔한 문제는 로그인 여부만 보고 자원 권한을 충분히 보지 않는 것이다
- IDOR는 객체 ID 노출보다 서버 측 소유권 검증 부재가 본질이다
- 접근 통제는 계정 보호, 세션 관리, 감사 로그와 함께 봐야 제대로 작동한다