코더의 보안 정복: 공유 및 학습 시리즈: 안전하지 않은 직접 객체 참조(IDOR)

URL은 우리가 사용하는 모든 웹사이트와 웹 애플리케이션을 탐색하는 데 필수적입니다. URL의 기본적인 기능은 리소스의 위치를 식별하고 이를 가져오는 방법을 지정하는 것입니다. 월드 와이드 웹이 작동하는 데 URL은 꼭 필요하지만, 제대로 보호되지 않으면 보안 위험을 초래할 수도 있습니다.

이 게시물에서는 다음 내용을 다룹니다:

• IDOR의 정의와 공격자의 IDOR 활용 방식
• IDOR가 위험한 이유
• 이 취약점을 해결하는 기술

IDOR 이해하기

직접 객체 참조란 애플리케이션 내에서 특정 레코드("객체")를 참조하는 것을 의미합니다. 이는 일반적으로 고유 식별자 형태를 띠며 URL에 나타날 수 있습니다.

예를 들어, URL 끝에 "?id=12345"와 같은 문구가 있는 것을 본 적이 있을 것입니다. 여기서 숫자 12345는 특정 레코드를 가리키는 참조값입니다. 개별 레코드에 대한 접근 제어가 제대로 이루어지지 않으면 보안 취약점이 발생합니다. 이로 인해 사용자는 자신이 보아서는 안 될 레코드와 데이터에 접근할 수 있게 됩니다. 이는 비교적 낮은 수준의 기술로도 가능한 공격입니다.

이 경우, 공격자가 URL의 ID를 12344로 변경한다고 가정해 보겠습니다. IDOR 취약점이 있는 애플리케이션이라면 공격자는 해당 레코드와 관련된 데이터를 볼 수 있게 됩니다.

이러한 유형의 취약점은 실제로 어느 정도의 피해를 줄 수 있을까요?

IDOR가 위험한 이유 파악하기

개발자가 주의를 기울이지 않으면 애플리케이션 레코드가 여러 곳에서 노출되거나 유출되는 시스템을 설계할 수 있습니다. 특히 민감한 데이터나 개인식별정보(PII)가 포함된 경우, 이러한 규모의 침해 사고는 매우 심각할 수 있습니다.

호주 국세청(ATO)은 새로운 세금 징수를 돕기 위해 웹사이트를 개설했습니다. 안타깝게도 이 사이트에는 IDOR 취약점이라는 원치 않는 기능이 포함되어 있었습니다. 한 호기심 많은 사용자가 사이트 내 URL에 자신의 호주 사업자 번호(ABN)가 포함되어 있다는 사실을 알아차렸습니다. 공교롭게도 이 번호는 등록된 기업이라면 누구나 쉽게 찾을 수 있는 정보였습니다. 이 사용자는 다른 기업의 번호를 URL에 입력해 보기로 했고, 그 결과 해당 기업들의 은행 계좌 정보와 개인 정보를 손에 넣게 되었습니다!

애플 역시 최근 IDOR 취약점의 피해를 입었습니다. 아이패드가 처음 출시되었을 때 114,000명의 고객 이메일 주소가 유출되었습니다. (공정하게 말하자면, 이는 AT&T 측의 실수에 더 가까웠습니다).

당시 AT&T는 아이패드의 3G 연결을 지원하는 서비스를 구축했습니다. 아이패드가 SIM 카드에 저장된 식별자를 AT&T 서비스로 보내면, 해당 서비스가 사용자의 이메일 주소를 반환하는 방식이었습니다.

안타깝게도 이 식별자들은 단순히 순차적인 정수였기 때문에 쉽게 추측할 수 있었습니다. 공격자들은 식별자를 반복적으로 대입하여 이메일 주소를 탈취했습니다.

또 다른 실수는 AT&T 서비스가 요청의 사용자 에이전트(user-agent) 헤더가 아이패드에서 온 것임을 나타낼 때만 이메일 주소를 반환하도록 하여 서비스를 "보호"하려 했다는 점입니다. 사용자 에이전트는 쉽게 조작할 수 있는 문자열 값에 불과합니다.

IDOR 취약점은 미묘하고 교묘하게 발생할 수 있습니다. 이제 이를 방어하는 방법을 논의해 보겠습니다.

IDOR 방어하기

IDOR 문제를 해결하는 핵심은 접근 제어입니다. 사용자가 특정 레코드를 요청할 때, 해당 사용자가 그 레코드를 볼 권한이 있는지 반드시 확인해야 합니다.

이를 위한 가장 좋은 방법은 중앙 집중식 권한 부여 모듈을 사용하는 것입니다. Spring Security와 같은 도구는 애플리케이션을 위한 강력하고 유연한 인증 및 권한 부여 기능을 제공합니다.

결론적으로, 모든 코드에서 권한 확인을 수행할 때 의존할 수 있는 단일 모듈을 구축하십시오.

또 다른 일반적인 완화 방법은 대리 참조(surrogate reference)를 사용하는 것입니다. URL에 실제 데이터베이스 레코드 식별자를 사용하는 대신, 실제 레코드와 매핑되는 임의의 숫자를 생성할 수 있습니다.

대리 참조를 사용하면 공격자가 다음 유효 식별자를 추측하는 것만으로는 레코드에 접근할 수 없습니다.

마지막으로, 사용자가 조작할 수 있는 그 어떤 것도 권한 부여의 근거로 삼지 마십시오. AT&T는 사용자 에이전트 헤더를 사용하여 서비스를 인증하려 했습니다. HTTP 헤더, 쿠키, 또는 GET 및 POST 매개변수에 의존하지 마십시오.

이러한 완화 조치를 적용하면 IDOR는 과거의 일이 될 것입니다.

참조를 안전하게 보호하기

안전하지 않은 직접 객체 참조(IDOR)는 가장 악용하기 쉬운 취약점 중 하나입니다. 방심하는 사이에 공격당하지 않도록 주의하십시오. 항상 사용자의 권한을 확인하고, 실제 데이터베이스 식별자를 사용하지 마십시오. 권한 부여를 위해 사용자가 제어할 수 있는 데이터에 의존하지 마십시오.

저희의 학습 리소스를 확인하여 숙련도를 높여보세요. 원하는 언어로 IDOR 취약점을 완화하는 방법을 연습하면 프로덕션 코드베이스에서 이 문제를 쉽게 찾아 해결할 수 있습니다. 또한 사이버 보안 팀을 최고의 사이버 전사로 훈련시키는 Secure Code Warrior 플랫폼의 무료 데모를 통해 새로 습득한 방어 지식을 테스트해 볼 수 있습니다. 이 취약점과 다양한 위협에 대해 더 자세히 알아보려면 를 방문하세요.

지금 바로 IDOR 공격을 방어할 준비가 되셨나요? 플랫폼으로 이동하여 무료로 도전해 보세요: [여기서 시작하기]