IDOR ( Insecure Direct Object Reference )
-> 직역으로는 비안전 직접 객체 참조, 부적절 인가라고 표현한다.
IDOR은 접근 권한 취약점의 한 유형이다. 웹 서버가 사용자 제공에 의한 입력 (파일, 데이터, 문서 등)을 검색할 때 발생할 수 있고, 입력 데이터에 너무 많은 신뢰나 유저 리퀘스트를 받을 때 서버단에서의 비검증으로 발생할 수 있다.
권한에 관련된 취약점이라고 해석할 수 있을 것 같다.
온라인서비스에서 내 정보를 변경하고자 할 때, 쿼리파라미터 유형으로
이렇게 리퀘스트를 보내는데, 그저 궁금증으로 user_id=1000으로 리퀘스트를 보냈더니 다른 사용자의 정보를 보게되는 (그런 경우는 없겠지만) 경우 IDOR 취약점을 발견한 것이다.
- Encoded IDs
POST 데이터, 쿼리 스트링, 쿠키와 같은 페이지에서 페이지로 넘어가는 데이터는 웹 개발자가 raw 데이터를 가지고 인코딩할 것이다.
인코딩은 웹 서버가 컨텐츠를 이해할 수 있도록 할 것이고, 바이너리 데이터를 ASCII 문자열로 변환할 것이다.
일반적인 인코딩 방식은 base64이므로 일반적으로 쉽게 알아낼 수 있다.
잘 알려진
같은 사이트에서 디코딩하고 데이터를 편집하여 다시 인코딩할 수 있고 리퀘스트를 다시 재출해서 리스폰스를 확인할 수 있겠다.
- Hashed IDs
인코딩 방식보다 더 복잡한 방식이지만, 정수값 버전의 해싱 같이 어떤 정형화된 패턴을 따를 수 있다.
예를 들어 ID 123은 md5 해싱함수를 통해 202cb962ac59075b964b07152d234b70 라는 해시값을 가진다. (스태틱함)
- Unpredictable IDs
말 그대로 예측할 수 없는 ID이다. 인코딩, 해싱으로 식별할 수 없으면, 계정 두개를 생성하고 ID를 바꾸는 것이다.
만약 다른 ID로 로그인 중(혹은 로그인하지 않은 상태)에 그 유저의 컨텐츠를 열람할 수 있으면 검증된 IDOR 취약점을 발견한 것이다.
해당 취약점은 url에 존재하지 않을 수도 있다. AJAX 리퀘스트나 JS파일에서 찾을 수 있다.
엔드포인트에 참조되지 않은 변수 중 개발 과정에서 사용된 파라미터가 프로덕션에서 푸시된 경우가 있을 수도 있다.
예를 들어서 세션에서 인증된 사용자 정보를 표시할 때 /user/details에 대한 호출이 parameter mining을 통해서 다른 사용자 정보를 표시하는데 사용되는 user_id와 같은 파라미터를 찾을 수도 있다.
Example
로그인한 페이지의 내 계정탭에서 정보를 변경할 수 있다.
해당 페이지의 리퀘스트를 다시 보내면 쿼리를 통해 id값을 요청하는 것을 볼 수 있는데, 리스폰스도 JSON 파일로 그대로 나와있다.
소스코드에서 getJSON 함수를 보면 /api/v1/customer?id={user_id}를 요청하는 것으로 보이므로 /api/v1/customer?id=1,3을 보내보자.
역시 get요청을 보냈고 JSON 파일을 획득했다.
