예제가 포함 된 손상된 개체 수준 권한 부여

이 게시물에서는 Broken Object Level Authorization 실패를 탐색하고 논의합니다.

깨진 개체 수준 인증이 무엇을 의미하는지 설명하는 것으로 시작하겠습니다. 그런 다음 관련 위험 요소를 설명하는 공격을 진행합니다.

그런 다음 최종적으로 공통 방어를 살펴보기 전에 취약점의 가능한 영향 중 일부를 살펴 보겠습니다.




손상된 개체 수준 인증이란?

간단히 말해, 이러한 유형의 공격은 데이터에 적용된 권한이 제대로 수행되지 않고 있음을 의미합니다. 이로 인해 허용되지 않아야 할 때 리소스와 데이터에 대한 액세스 권한이 부여됩니다.

깨진 개체 수준 권한은 과거에 안전하지 않은 직접 개체 참조 (IDOR)로 알려졌습니다.


우리가 단어를 말할 때 목적 Broken Object Level Authorization에서 의미하는 것은 값 또는 값 그룹입니다. 개체는 작성자, 콘텐츠 및 게시 날짜를 포함하는 소셜 미디어 게시물 일 수 있습니다.

권한 부여 사용자가 액세스 할 수있는 모든 것입니다. 따라서 우리는 이미 로그인 한 사용자에 대해 이야기하고 있습니다.

사용자가 API에 요청하면 해당 요청이 객체에 액세스하는 데 사용됩니다. 이것이 승인에 대한 결정을 내려야하는 지점입니다. 사용자는 액세스 권한이 부여 된 개체에만 액세스 할 수 있어야합니다. 이것은 올바르게 작동하는 권한입니다.


승인이 해제되면 사용자는 허용되지 않아야하는 데이터와 리소스에 액세스 할 수 있습니다.

API는 객체에 대한 다양한 작업을 용이하게합니다. 개체를 가져오고, 만들고, 업데이트하거나 삭제할 수도 있습니다.

객체와의 상호 작용은 API의 전체 지점이므로 해당 객체에 대한 권한 제어가 손상되면 Broken Object Level Access 취약점이 있습니다.



손상된 개체 수준 액세스 취약점 악용

일반적으로이 취약점이 발견되면 쉽게 악용 할 수 있습니다. 공격자가해야 할 일은 요청에서 식별자를 변경하는 것이며, 잠재적으로 허용해서는 안되는 개체에 액세스 할 수 있습니다.


예를 들어 보겠습니다.

여기에 API를 호출하는 데 사용되는 URL이 있습니다.

https://myemail.com/messages/12345

이 API 호출은 사용자의 비공개 메시지를 검색하는 데 사용됩니다. 사용중인 리소스는 다음과 같습니다. 메시지 .

메시지는 Broken Object Level Authorization에서 언급하는 객체입니다. 개인 메시지는 의도 된 수신자 만 읽을 수 있다고 가정합니다.


다음으로, 우리는 12345 메시지의 ID를 가지고 있습니다. 이것은 공격자에게 중요한 부분입니다.

ID는 반환 할 레코드를 서비스에 알려줍니다. API는 데이터 저장소에서 해당 레코드를 검색하여 응답에 반환합니다.

이제 ID를 12345에서 변경하면 어떻게됩니까? 12346? 예 :

https://myemail.com/messages/12346

ID가 12346 인 메시지 사용자를위한 것이므로 검색 할 수 있어야합니다.


그러나 메시지가 다른 사용자에게 속한 경우 API는 메시지를 반환해서는 안됩니다. 메시지를 검색했다면 Broken Level Object Authorization 오류가 발생합니다.

또 다른 예는 리소스를 업데이트하기 위해 POST 요청을 보내는 것입니다. JSON 페이로드에서 ID를 가지고 놀 수 있습니다.

{
'userId': '12345678',
'oldPassword': 'My_0ld_Pa$$',
'newPassword': '$uperS3CurE' }

우리가 어떤 잠재력을두면 userId 다른 사용자의 세부 정보를 업데이트 할 수 있었는데 큰 문제가 있습니다.

기술적 영향

취약성이 존재한다는 것을 알게되면 모든 종류의 방식으로이를 악용 할 수 있습니다. 앞서 언급했듯이 API에서 다양한 HTTP 메서드를 사용할 수 있습니다. Id를 사용하여 메시지를 업데이트하거나 삭제할 수도 있습니다!

모든 ID를 반복 할 수 있다면 어떻게됩니까? 저장된 모든 메시지를 삭제할 수 있습니다. 그것은 큰 영향입니다.



일반적인 취약점

이것은 매우 일반적인 취약점입니다. 앞서 언급했듯이 API는 객체에 액세스하는 데 사용되며 대부분의 경우 요청에서 ID를 사용하여 리소스를 식별합니다. 문제는 해당 액세스에 대한 권한 확인이 마련되어 있습니까?

코드에 Broken Object Level Authorization 취약점이 생기는 데는 주로 두 가지 이유가 있습니다.

첫 번째는 보안 제어가 구현되지 않은 것입니다. 요청에 대한 승인 확인을 수행하기위한 코드가 작성되지 않았습니다.

두 번째 이유는 인적 오류입니다. 사람들은 실수를합니다. 좋은 예는 민감하지 않은 데이터에 대한 민감한 데이터를 모두 처리하는 API입니다. 일부 요청에는 승인 확인이 있어야하고 다른 요청에는 없어야합니다. 따라서 코드를 작성할 때 수표를 놓치기 쉽습니다.



감지 방법

자동화 된 도구는 최소한 약간의 두뇌 능력을 사용하는 경향이 있기 때문에 일반적으로 이러한 유형의 취약성을 찾지 못합니다.

사람이이 취약점을 탐지하는 것은 비교적 쉽습니다. 우리가해야 할 일은 개체를 검색하는 데 사용되는 식별자를 찾는 것입니다.

식별자는 URL, 요청 본문 또는 헤더에있을 수 있습니다.

또한 취약성이 있는지 여부를 확인하기 위해 돌아 오는 응답을 분석하고 해석해야합니다.

도구

HTTP 요청 및 응답을 검사하는 모든 도구를 사용할 수 있습니다. 이들 중 일부는 다음과 같습니다.

  • Google 개발자 도구
  • Burp 스위트
  • 우편 집배원

Burp Suite를 사용하여 일부 요청을 자동화 할 수도 있습니다.



손상된 개체 수준 인증에 대한 방어

여기에 두 가지 방어 수단이 있습니다.

첫 번째 방어는 GUID와 같은 예측할 수없는 ID . 코드에서 연속적인 숫자를 사용하는 경우 (예 : 12345, 이는 ID가 매우 예측 가능하다는 것을 의미합니다. 공격자는 개체를 찾기 위해 숫자를 검색하는 데 많은 노력을 기울일 필요가 없습니다.

GUID의 예 :

d3b773e6-3b44-4f5f-9813-c39844719fc4

GUID는 복잡하고 추측하기 매우 어렵고 순차적이지 않습니다.

다음 방어는 실제로 몇 가지 코드를 승인 확인 . 이 검사는 종종 발생하지 않습니다.

사용자가 사용될 ID 내에서 API를 제시 할 때마다 승인 확인이 이루어져야합니다. 여기서 핵심 원칙은 사용자가 API에 제공하는 데이터를 신뢰해서는 안된다는 것입니다.

사용자가 개체에 액세스 할 수있는 권한이 있는지 확인하려면 요청 된 ID를 확인해야합니다.

이러한 검사는 소프트웨어 개발 중 단순한 코드 검토 및 / 또는 개발 전반에 걸쳐 인증 실패를 확인하는 자동화 된 검사일 수 있습니다.



결론

지금까지 살펴본 것처럼 Broken Object Level Authorization은 일반적인 취약점이며 발견 및 공격이 쉽습니다. 잠재적 인 영향은 엄청납니다.

이 취약점의 실제 원인은 클라이언트가 API로 전달하는 데이터를 신뢰하는 것입니다.

방어의 큰 부분은 해당 데이터를 신뢰하지 않도록하는 것입니다. 따라서 승인 확인이 제대로되어 있는지 확인해야합니다.