IDOR

agnusdei·2025년 6월 22일

CTF

목록 보기
31/185

문제: IDOR(Insecure Direct Object Reference)에 대해 설명하시오.

1. IDOR의 개념

IDOR(Insecure Direct Object Reference, 안전하지 않은 직접 객체 참조)는 웹 애플리케이션 보안 취약점의 한 종류로, 사용자가 URL이나 양식 매개변수와 같은 참조를 통해 내부 구현 객체(파일, 데이터베이스 레코드, 키 등)에 직접 접근할 수 있을 때 발생합니다. 이 취약점이 있으면 공격자가 권한 없이 다른 사용자의 데이터에 접근하거나 조작할 수 있으며, OWASP(Open Web Application Security Project, 오픈 웹 애플리케이션 보안 프로젝트) Top 10에서 중요한 보안 위협으로 분류됩니다.

2. IDOR의 역할 및 목적(악용 관점)

IDOR 공격의 주요 목적은 다음과 같습니다:

  • 권한 우회: 인증된 사용자가 접근 권한이 없는 리소스에 접근
  • 민감한 정보 유출: 다른 사용자의 개인 정보나 기밀 데이터 열람
  • 데이터 조작: 권한 없는 데이터 수정, 삭제 또는 생성
  • 수평적 권한 상승(Horizontal Privilege Escalation): 동일한 권한 수준의 다른 사용자 리소스에 접근
  • 수직적 권한 상승(Vertical Privilege Escalation): 높은 권한 수준의 리소스에 접근

3. IDOR의 구조 및 작동 원리

3.1 기본 메커니즘

IDOR 취약점은 일반적으로 다음과 같은 구조로 발생합니다:

  1. 객체 참조 노출: 웹 애플리케이션이 내부 객체(예: 데이터베이스 ID)를 사용자에게 직접 노출
  2. 불충분한 접근 제어: 해당 객체에 대한 접근 권한 검증이 불충분하게 구현됨
  3. 요청 조작 가능: 사용자가 객체 참조를 쉽게 조작하여 의도하지 않은 접근을 시도할 수 있음

3.2 IDOR 취약점 발생 위치

IDOR 취약점은 주로 다음과 같은 위치에서 발생합니다:

  • URL 매개변수: example.com/account?id=123
  • 폼 필드 데이터: <input type="hidden" name="user_id" value="123">
  • 쿠키: user_id=123
  • JSON/XML 요청 본문: {"invoice_id": 123}
  • REST API 엔드포인트: api/v1/users/123/profile

4. IDOR 취약점의 구성요소

4.1 직접 객체 참조

  • 예측 가능한 ID: 순차적인 숫자(1, 2, 3...) 또는 쉽게 추측 가능한 식별자
  • 노출된 내부 식별자: 데이터베이스 키, 파일 경로, 시스템 식별자 등
  • 불변하는 참조: 사용자 세션 간에 변경되지 않는 참조

4.2 불충분한 접근 제어

  • 인증 부재: 사용자 로그인 상태만 확인하고 권한은 확인하지 않음
  • 권한 검증 부재: 현재 사용자가 요청된 리소스에 접근할 권한이 있는지 확인하지 않음
  • 클라이언트 측 제한: 서버 측에서 권한을 확인하지 않고 클라이언트 UI에만 의존

5. IDOR 공격 유형 및 사례

5.1 일반적인 IDOR 공격 유형

  1. 기본 IDOR: URL 매개변수 변경 (/account?id=123/account?id=124)
  2. 숨겨진 필드 조작: HTML 폼의 숨겨진 필드 값 수정
  3. 쿠키 변조: 사용자 정보가 담긴 쿠키 값 수정
  4. 예측 가능한 리소스 위치: 예측 가능한 리소스 경로 추측 (/download/invoice_123.pdf)
  5. HTTP 메서드 변경: GET에서 PUT/DELETE로 변경하여 리소스 수정/삭제
  6. 참조 대체: 정식 참조를 악의적인 참조로 대체 (SSRF 공격과 결합)

5.2 실제 IDOR 사례

  1. Facebook(2019): 페이스북 페이지 관리자 권한 없이 페이지 설정을 변경할 수 있는 IDOR 취약점
  2. HackerOne(2016): 보고서 ID를 조작하여 다른 보안 연구원의 취약점 보고서에 접근할 수 있는 취약점
  3. Uber(2019): 다른 사용자의 여행 정보에 접근할 수 있는 IDOR 취약점

6. IDOR 탐지 방법

6.1 수동 테스트 방법

  • 매개변수 조작: URL 및 폼 매개변수 값 변경 시도
  • 인증 우회 테스트: 로그아웃 상태에서 직접 URL 접근 시도
  • 항목 열거: 예측 가능한 ID를 사용하여 다른 사용자 리소스 접근 시도
  • 다중 계정 테스트: 여러 테스트 계정으로 교차 접근 시도

6.2 자동화된 탐지 도구

  • 동적 애플리케이션 보안 테스팅(DAST): Burp Suite, OWASP ZAP
  • 코드 검토 도구: Checkmarx, Fortify
  • 웹 취약점 스캐너: Acunetix, Nessus

7. IDOR 방어 및 완화 방법

7.1 간접 참조 매핑

  • 직접 참조 피하기: 내부 데이터베이스 ID 대신 임의 생성된 식별자 사용
  • 간접 참조 맵: 실제 데이터베이스 ID와 사용자에게 노출되는 참조 간에 매핑 테이블 유지
  • 세션 기반 매핑: 사용자 세션에 특정한 참조 생성 (세션이 끝나면 만료됨)

7.2 강력한 접근 제어

  • 세분화된 접근 제어: 각 객체에 대한 사용자 권한을 세밀하게 확인
  • 다중 계층 검증: 세션 확인, 권한 확인, 소유권 확인 등 여러 계층의 검증 구현
  • 컨텍스트 기반 접근 제어: 사용자 역할, 시간, 위치 등 다양한 컨텍스트 요소 고려

7.3 리소스 정책 강화

  • 최소 권한 원칙: 사용자에게 필요한 최소한의 권한만 부여
  • 정규 표현식 검증: 객체 참조에 대한 엄격한 형식 검증
  • 속도 제한: 과도한 요청에 대한 제한으로 무작위 추측 시도 차단

8. IDOR 관련 핵심 용어

  • 접근 제어(Access Control): 리소스에 대한 접근 권한을 관리하는 메커니즘
  • 최소 권한 원칙(Principle of Least Privilege): 작업 수행에 필요한 최소한의 권한만 부여
  • 수평적 권한 상승(Horizontal Privilege Escalation): 동일한 권한 수준의 다른 사용자 데이터에 접근
  • 수직적 권한 상승(Vertical Privilege Escalation): 높은 권한 레벨의 기능이나 데이터에 접근
  • RBAC(Role-Based Access Control): 사용자 역할에 기반한 접근 제어 방식
  • ABAC(Attribute-Based Access Control): 다양한 속성에 기반한 접근 제어 방식
  • 간접 객체 참조(Indirect Object Reference): 안전한 방식으로 매핑된 객체 참조

9. IDOR와 다른 보안 취약점의 비교

취약점주요 특징IDOR와의 차이
SQL 인젝션악의적인 SQL 쿼리 주입을 통한 데이터베이스 조작코드 실행 대신 리소스 접근에 초점
XSS(Cross-Site Scripting)웹 페이지에 악성 스크립트 삽입클라이언트 측 공격 vs. 서버 측 접근 제어 우회
CSRF(Cross-Site Request Forgery)사용자의 의도와 관계없이 요청 실행피해자의 행동 필요 vs. 직접적인 접근
인증 우회인증 메커니즘을 완전히 우회인증은 성공하나 권한 검사를 우회
서버 측 요청 위조(SSRF)서버를 통해 내부 네트워크 자원에 접근내부 네트워크 vs. 애플리케이션 데이터

10. IDOR의 영향 및 위험

10.1 비즈니스 영향

  • 데이터 유출: 민감한 고객 정보나 비즈니스 데이터 노출
  • 규정 위반: GDPR, HIPAA, PCI DSS 등 데이터 보호 규정 위반으로 인한 법적 결과
  • 평판 손상: 보안 사고로 인한 기업 이미지 및 고객 신뢰 손상
  • 금전적 손실: 벌금, 소송, 고객 이탈로 인한 재정적 손실

10.2 위험 수준 결정 요소

  • 노출된 데이터의 민감도: 개인식별정보(PII), 금융 정보, 의료 정보 등
  • 공격 난이도: 참조 조작의 쉬움 정도
  • 잠재적 영향 범위: 영향받는 사용자 및 데이터 양
  • 발견 및 악용 가능성: 취약점이 발견되고 악용될 가능성

11. IDOR 방어의 장단점

11.1 방어 방식의 장점

  • 보안성 강화: 권한 없는 접근으로부터 데이터 보호
  • 규정 준수: 데이터 보호 규정 준수 지원
  • 신뢰성 향상: 사용자 데이터 보호를 통한 신뢰 구축
  • 구조적 보안: 애플리케이션 전체에 일관된 보안 적용

11.2 방어 방식의 단점

  • 개발 복잡성 증가: 간접 참조 매핑 및 접근 제어 구현이 복잡
  • 성능 영향: 추가적인 검증 단계로 인한 성능 저하 가능성
  • 유지보수 부담: 접근 제어 정책 관리에 추가적인 노력 필요
  • 사용자 경험: 과도한 접근 제어가 사용자 경험을 저하시킬 가능성

12. 어린이 버전 요약

IDOR는 웹사이트나 앱에서 발생하는 보안 문제의 한 종류예요. 이것은 마치 학교 사물함과 비슷해요. 원래는 자신의 사물함 번호(예: 15번)만 열 수 있어야 하는데, IDOR 문제가 있으면 다른 친구의 사물함 번호(예: 16번)도 마음대로 열어볼 수 있게 되는 것이에요.

웹사이트에서는 주소창에 있는 숫자를 바꾸는 것만으로도 다른 사람의 개인정보나 비밀 내용을 볼 수 있게 되어버려요. 예를 들어, mywebsite.com/profile?id=123에서 id=123id=124로 바꾸면 다른 사람의 프로필에 접근할 수 있게 되는 거예요.

좋은 웹사이트는 "이건 네 사물함이 맞니?"라고 항상 확인하지만, IDOR 문제가 있는 웹사이트는 이런 확인을 제대로 하지 않아요. 그래서 보안 전문가들은 이런 문제를 찾아서 고치는 일을 중요하게 여긴답니다!

profile
DevSecOps, Pentest, Cloud(OpenStack), Develop, Data Engineering, AI-Agent

0개의 댓글