IDOR

agnusdei·2025년 6월 22일
0

CTF

목록 보기
31/154

문제: 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 ⚙️ + CTF🚩

0개의 댓글