코더는 보안을 정복 : 공유 및 학습 시리즈 : 안전하지 않은 직접 개체 참조
URL은 우리가 알고 사랑하는 모든 웹 사이트와 웹 응용 프로그램을 탐색하는 데 필수적입니다. 그들의 기본 기능은 리소스가 있는 위치와 리소스를 검색하는 방법을 식별하는 것입니다. 월드 와이드 웹이 작동하려면 URL이 필요하지만 제대로 보호되지 않으면 보안 위험이 발생할 수도 있습니다.
이 게시물에서는 다음을 배우게 됩니다.
- IDOR가 무엇이며 공격자가 IDOR를 사용하는 방법
- IDOR가 위험한 이유
- 이 취약점을 해결할 수 있는 기술
IDOR 이해
직접 개체 참조는 응용 프로그램 내에서 특정 레코드("개체")가 참조되는 경우입니다. 일반적으로 고유 식별자의 형태를 취하고 URL에 나타날 수 있습니다.
예를 들어 URL 끝에 "?id=12345"와 같은 것을 알 수 있습니다. 숫자, 12345, 특정 레코드에 대 한 참조. 개별 레코드에 대한 액세스 제어가 없을 때 보안 취약점이 들어옵니다. 이를 통해 사용자는 볼 수 없는 레코드와 데이터에 액세스할 수 있습니다. 이것은 상대적으로 낮은 기술 수준을 필요로 하는 공격입니다.
이 경우 공격자가 URL의 ID를 12344로 변경한다고 가정해 보겠습니다. IDOR에 취약한 응용 프로그램에서 공격자는 해당 레코드와 관련된 데이터를 볼 수 있습니다.
이러한 유형의 취약점이 실제로 발생할 수 있는 피해는 얼마입니까?
IDOR가 위험한 이유 알기
개발자가 주의하지 않으면 다양한 장소에서 응용 프로그램 레코드를 표시하고 누수하는 시스템을 설계할 수 있습니다. 특히 중요한 데이터 또는 PII가 관련된 경우 이 크기의 위반이 심각할 수 있습니다.
호주 세무국은 기업이 새로운 세금을 징수할 수 있도록 웹 사이트를 설정했습니다. 불행히도 IDOR 취약점의 원치 않는 기능으로 포장되었습니다. 호기심 많은 사용자는 사이트 내의 URL에 호주 비즈니스 번호 또는 ABN이 포함되어 있음을 깨달았습니다. 등록된 비즈니스에서 쉽게 검색할 수 있는 수치입니다. 이 사용자는 다른 회사의 번호를 URL에 넣기로 결정했습니다. 그는 자신의 은행 계좌 정보와 개인 정보와 재능이 있었다!
애플은 최근 IDOR 취약점의 희생자가 되었다. iPad가 처음 출시되었을 때 114,000개의 고객 이메일 주소가 유출되었습니다. (공정하게, 그것은 AT&T의 부분에 더실수했다).
AT&T는 iPad에 대한 3G 연결을 지원하는 서비스를 구축했습니다. iPad는 SIM 카드에 저장된 식별자를 AT&T의 서비스에 보냈습니다. 그런 다음 서비스가 사용자의 이메일 주소를 반환했습니다.
불행히도 이러한 식별자는 단순히 순차적 정수이므로 쉽게 추측 할 수 있었습니다. 공격자는 식별자를 통해 반복하고 이메일 주소를 훔쳤습니다.
또 다른 실수는 AT&T의 서비스가 요청의 사용자 에이전트 헤더가 iPad에서 온 것으로 나타난 경우에만 이메일 주소를 반환하여 서비스를 "보안"하려고 했다는 것입니다. 사용자 에이전트는 쉽게 조작할 수 있는 문자열 값일 뿐입니다.
IDOR 취약점은 미묘하고 비열할 수 있습니다. 그들을 물리 칠 하는 방법을 논의 하자.
IDOR 패배
액세스 제어는 IDOR를 해결하는 열쇠입니다. 사용자가 특정 레코드를 요청하면 요청된 레코드를 볼 수 있는 권한이 있는지 확인합니다.
중앙 집중식 권한 부여 모듈을 사용하는 것이 이 작업을 수행하는 가장 좋은 방법입니다. 스프링 시큐리티와 같은 도구는 응용 프로그램에 대한 강력하고 사용자 정의 가능한 인증 및 권한을 제공합니다.
결론: 다른 모든 코드가 권한 부여 검사를 수행하는 데 의존하는 하나의 모듈이 있습니다.
또 다른 일반적인 완화는 대리 참조를 사용하는 것입니다. URL에서 실제 데이터베이스 레코드 식별자를 사용하는 대신 실제 레코드로 다시 매핑되는 난수를 만들 수 있습니다.
대리 참조를 사용하면 공격자가 다음 유효한 식별자를 추측하는 것만으로는 레코드에 도착할 수 없습니다.
마지막으로 사용자가 조작하여 권한을 제공할 수 있는 것은 아무것도 의존하지 마십시오. AT&T는 사용자 에이전트 헤더를 사용하여 서비스를 승인하려고 했습니다. HTTP 헤더, 쿠키 또는 GET 및 POST 매개 변수에 의존하지 마십시오.
이러한 완화를 통해 IDOR는 과거의 일이 될 것입니다.
참조 보안
안전하지 않은 직접 개체 참조는 악용하기 가장 쉬운 취약점 중 하나입니다. 당신이 적어도 그것을 기대할 때 그들이 당신에 몰래하지 마십시오. 항상 사용자가 권한이 있는지 확인합니다. 실제 데이터베이스 식별자를 사용하지 마십시오. 권한 부여를 위해 사용자 제어 데이터에 의존하지 마십시오.
학습 리소스를확인하여 숙달을 구축할 수 있습니다. 원하는 언어로 IDOR 취약점을 완화하는 방법을 연습하면 프로덕션 코드베이스에서 이 문제를 찾아 해결하는 데 아무런 문제가 없습니다. 또한 새로운 방어 지식을 테스트에 넣을 수 있습니다. Secure Code Warrior 사이버 보안 팀이 궁극적인 사이버 전사가 될 수 있도록 하는 플랫폼. 이 취약점을 물리치는 것에 대해 자세히 알아보려면 Secure Code Warrior 블로그.
지금 IDOR 공격을 방어할 준비가 되셨습니까? 플랫폼으로 가서 무료로 도전하십시오: [여기에서 시작]
야프 카란 싱
블로그에서 최신 보안 코딩 인사이트에 대해 자세히 알아보세요.
Atlassian의 광범위한 리소스 라이브러리는 안전한 코딩 숙련도를 확보하기 위한 인적 접근 방식을 강화하는 것을 목표로 합니다.
개발자 중심 보안에 대한 최신 연구 보기
광범위한 리소스 라이브러리에는 개발자 중심의 보안 코딩을 시작하는 데 도움이 되는 백서부터 웨비나까지 유용한 리소스가 가득합니다. 지금 살펴보세요.
코더는 보안을 정복 : 공유 및 학습 시리즈 : 안전하지 않은 직접 개체 참조
URL은 우리가 알고 사랑하는 모든 웹 사이트와 웹 응용 프로그램을 탐색하는 데 필수적입니다. 그들의 기본 기능은 리소스가 있는 위치와 리소스를 검색하는 방법을 식별하는 것입니다. 월드 와이드 웹이 작동하려면 URL이 필요하지만 제대로 보호되지 않으면 보안 위험이 발생할 수도 있습니다.
이 게시물에서는 다음을 배우게 됩니다.
- IDOR가 무엇이며 공격자가 IDOR를 사용하는 방법
- IDOR가 위험한 이유
- 이 취약점을 해결할 수 있는 기술
IDOR 이해
직접 개체 참조는 응용 프로그램 내에서 특정 레코드("개체")가 참조되는 경우입니다. 일반적으로 고유 식별자의 형태를 취하고 URL에 나타날 수 있습니다.
예를 들어 URL 끝에 "?id=12345"와 같은 것을 알 수 있습니다. 숫자, 12345, 특정 레코드에 대 한 참조. 개별 레코드에 대한 액세스 제어가 없을 때 보안 취약점이 들어옵니다. 이를 통해 사용자는 볼 수 없는 레코드와 데이터에 액세스할 수 있습니다. 이것은 상대적으로 낮은 기술 수준을 필요로 하는 공격입니다.
이 경우 공격자가 URL의 ID를 12344로 변경한다고 가정해 보겠습니다. IDOR에 취약한 응용 프로그램에서 공격자는 해당 레코드와 관련된 데이터를 볼 수 있습니다.
이러한 유형의 취약점이 실제로 발생할 수 있는 피해는 얼마입니까?
IDOR가 위험한 이유 알기
개발자가 주의하지 않으면 다양한 장소에서 응용 프로그램 레코드를 표시하고 누수하는 시스템을 설계할 수 있습니다. 특히 중요한 데이터 또는 PII가 관련된 경우 이 크기의 위반이 심각할 수 있습니다.
호주 세무국은 기업이 새로운 세금을 징수할 수 있도록 웹 사이트를 설정했습니다. 불행히도 IDOR 취약점의 원치 않는 기능으로 포장되었습니다. 호기심 많은 사용자는 사이트 내의 URL에 호주 비즈니스 번호 또는 ABN이 포함되어 있음을 깨달았습니다. 등록된 비즈니스에서 쉽게 검색할 수 있는 수치입니다. 이 사용자는 다른 회사의 번호를 URL에 넣기로 결정했습니다. 그는 자신의 은행 계좌 정보와 개인 정보와 재능이 있었다!
애플은 최근 IDOR 취약점의 희생자가 되었다. iPad가 처음 출시되었을 때 114,000개의 고객 이메일 주소가 유출되었습니다. (공정하게, 그것은 AT&T의 부분에 더실수했다).
AT&T는 iPad에 대한 3G 연결을 지원하는 서비스를 구축했습니다. iPad는 SIM 카드에 저장된 식별자를 AT&T의 서비스에 보냈습니다. 그런 다음 서비스가 사용자의 이메일 주소를 반환했습니다.
불행히도 이러한 식별자는 단순히 순차적 정수이므로 쉽게 추측 할 수 있었습니다. 공격자는 식별자를 통해 반복하고 이메일 주소를 훔쳤습니다.
또 다른 실수는 AT&T의 서비스가 요청의 사용자 에이전트 헤더가 iPad에서 온 것으로 나타난 경우에만 이메일 주소를 반환하여 서비스를 "보안"하려고 했다는 것입니다. 사용자 에이전트는 쉽게 조작할 수 있는 문자열 값일 뿐입니다.
IDOR 취약점은 미묘하고 비열할 수 있습니다. 그들을 물리 칠 하는 방법을 논의 하자.
IDOR 패배
액세스 제어는 IDOR를 해결하는 열쇠입니다. 사용자가 특정 레코드를 요청하면 요청된 레코드를 볼 수 있는 권한이 있는지 확인합니다.
중앙 집중식 권한 부여 모듈을 사용하는 것이 이 작업을 수행하는 가장 좋은 방법입니다. 스프링 시큐리티와 같은 도구는 응용 프로그램에 대한 강력하고 사용자 정의 가능한 인증 및 권한을 제공합니다.
결론: 다른 모든 코드가 권한 부여 검사를 수행하는 데 의존하는 하나의 모듈이 있습니다.
또 다른 일반적인 완화는 대리 참조를 사용하는 것입니다. URL에서 실제 데이터베이스 레코드 식별자를 사용하는 대신 실제 레코드로 다시 매핑되는 난수를 만들 수 있습니다.
대리 참조를 사용하면 공격자가 다음 유효한 식별자를 추측하는 것만으로는 레코드에 도착할 수 없습니다.
마지막으로 사용자가 조작하여 권한을 제공할 수 있는 것은 아무것도 의존하지 마십시오. AT&T는 사용자 에이전트 헤더를 사용하여 서비스를 승인하려고 했습니다. HTTP 헤더, 쿠키 또는 GET 및 POST 매개 변수에 의존하지 마십시오.
이러한 완화를 통해 IDOR는 과거의 일이 될 것입니다.
참조 보안
안전하지 않은 직접 개체 참조는 악용하기 가장 쉬운 취약점 중 하나입니다. 당신이 적어도 그것을 기대할 때 그들이 당신에 몰래하지 마십시오. 항상 사용자가 권한이 있는지 확인합니다. 실제 데이터베이스 식별자를 사용하지 마십시오. 권한 부여를 위해 사용자 제어 데이터에 의존하지 마십시오.
학습 리소스를확인하여 숙달을 구축할 수 있습니다. 원하는 언어로 IDOR 취약점을 완화하는 방법을 연습하면 프로덕션 코드베이스에서 이 문제를 찾아 해결하는 데 아무런 문제가 없습니다. 또한 새로운 방어 지식을 테스트에 넣을 수 있습니다. Secure Code Warrior 사이버 보안 팀이 궁극적인 사이버 전사가 될 수 있도록 하는 플랫폼. 이 취약점을 물리치는 것에 대해 자세히 알아보려면 Secure Code Warrior 블로그.
지금 IDOR 공격을 방어할 준비가 되셨습니까? 플랫폼으로 가서 무료로 도전하십시오: [여기에서 시작]
