블로그

코더는 보안을 정복 : 공유 및 학습 시리즈 : 안전하지 않은 직접 개체 참조

야프 카란 싱
게시일: 2019년 3월 14일

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 공격을 방어할 준비가 되셨습니까? 플랫폼으로 가서 무료로 도전하십시오: [여기에서 시작]

리소스 보기
리소스 보기

직접 개체 참조는 응용 프로그램 내에서 특정 레코드('개체')를 참조하는 경우입니다. 일반적으로 고유 식별자의 형태를 취하고 URL에 나타날 수 있습니다.

더 알고 싶으신가요?

야프 카란 싱은 보안 코딩 전도자, 수석 싱 및 공동 설립자입니다 Secure Code Warrior .

Secure Code Warrior 는 전체 소프트웨어 개발 수명 주기에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 도와드립니다. 앱 보안 관리자, 개발자, CISO 등 보안과 관련된 모든 사람이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.

데모 예약
공유하세요:
저자
야프 카란 싱
게시일: 2019년 3월 14일

야프 카란 싱은 보안 코딩 전도자, 수석 싱 및 공동 설립자입니다 Secure Code Warrior .

공유하세요:

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 공격을 방어할 준비가 되셨습니까? 플랫폼으로 가서 무료로 도전하십시오: [여기에서 시작]

리소스 보기
리소스 보기

아래 양식을 작성하여 보고서를 다운로드하세요.

우리는 당신에게 우리의 제품 및 / 또는 관련 보안 코딩 주제에 대한 정보를 보낼 수있는 귀하의 허가를 바랍니다. 우리는 항상 최대한의주의를 기울여 귀하의 개인 정보를 취급 할 것이며 마케팅 목적으로 다른 회사에 판매하지 않을 것입니다.

전송
양식을 제출하려면 '분석' 쿠키를 활성화하세요. 완료되면 언제든지 다시 비활성화할 수 있습니다.

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 공격을 방어할 준비가 되셨습니까? 플랫폼으로 가서 무료로 도전하십시오: [여기에서 시작]

리소스에 접근

아래 링크를 클릭하여 이 자료의 PDF를 다운로드하세요.

Secure Code Warrior 는 전체 소프트웨어 개발 수명 주기에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 도와드립니다. 앱 보안 관리자, 개발자, CISO 등 보안과 관련된 모든 사람이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.

보고서 보기데모 예약
PDF 다운로드
리소스 보기
공유하세요:
더 알고 싶으신가요?

공유하세요:
저자
야프 카란 싱
게시일: 2019년 3월 14일

야프 카란 싱은 보안 코딩 전도자, 수석 싱 및 공동 설립자입니다 Secure Code Warrior .

공유하세요:

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 공격을 방어할 준비가 되셨습니까? 플랫폼으로 가서 무료로 도전하십시오: [여기에서 시작]

목차

PDF 다운로드
리소스 보기
더 알고 싶으신가요?

야프 카란 싱은 보안 코딩 전도자, 수석 싱 및 공동 설립자입니다 Secure Code Warrior .

Secure Code Warrior 는 전체 소프트웨어 개발 수명 주기에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 도와드립니다. 앱 보안 관리자, 개발자, CISO 등 보안과 관련된 모든 사람이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.

데모 예약다운로드
공유하세요:
리소스 허브

시작할 수 있는 리소스

더 많은 게시물
리소스 허브

시작할 수 있는 리소스

더 많은 게시물