접근 통제 누락 (IDOR)
앞의 두 개(SQL 인젝션, XSS)가 “입력을 안 믿어서” 생기는 문제였다면, IDOR은 성격이 다르다. 권한을 안 지켜서 생긴다. 해킹 기술이 거의 필요 없는데 피해는 가장 클 수 있는 취약점이다.
정의
자원(문서·주문·계정)에 접근할 때 “이 사용자가 이걸 볼 권한이 있는가”를 서버가 확인하지 않아, 식별자만 바꾸면 남의 자원이 보이는 취약점. IDOR은 Insecure Direct Object Reference의 약자다.
왜 생기나
URL이나 파라미터에 식별자가 그대로 노출되는데, 서버가 로그인 여부만 확인하고 소유권은 확인하지 않을 때 생긴다.
/document?id=1001 ← 내 문서
/document?id=1002 ← 숫자만 바꾸면?로그인은 했으니 통과, 그런데 1002가 내 것인지는 확인 안 함. 그러면 남의 문서가 그대로 열린다.
공격 방식
- URL의 번호를
1002,1003으로 바꿔가며 남의 자원을 순차적으로 긁는다(스크래핑). - API 요청 본문의 계정 번호를 바꿔 타인 정보를 조회·수정한다.
- 식별자가 순차적인 숫자면 자동화 도구로 전체를 훑기 쉽다. 이게 IDOR을 치명적으로 만드는 핵심이다.
실제 사례
- 퍼스트 아메리칸(미국 부동산 보험사, 2019): 문서 열람 URL의 번호를 하나씩 바꾸면 로그인 없이 타인의 계약 문서가 열렸다. 계좌·신분 정보가 담긴 팔억 건 이상의 문서가 노출됐다. IDOR의 교과서 사례로 늘 인용된다.
- 팔러(Parler, 2021): 게시글 번호가 순차적이라, 전체 게시물과 위치정보가 담긴 데이터를 통째로 수집당했다.
둘 다 정교한 해킹이 아니다. 주소의 숫자를 바꾼 것뿐이다.
막는 법
서버가 매 요청마다 “이 자원이 요청한 사용자의 것인가”를 확인한다(소유권 검증). 추가로 순차적 숫자 대신 추측하기 어려운 식별자(UUID)를 쓰면 자동 스크래핑을 늦출 수 있다. 다만 UUID는 보조일 뿐, 근본 대책은 서버 측 권한 검증이다.
접근 통제 모델 자체(MAC·DAC·RBAC)는 접근 통제 노트에 따로 정리해뒀다.