Skip to content

lab9.md

Latest commit

 

History

History
125 lines (85 loc) · 5.6 KB

lab9.md

File metadata and controls

125 lines (85 loc) · 5.6 KB
Raw

Lab 9 - Insecure Direct Object Reference (IDOR) Vulnerabilities

Objective: In this lab, students will investigate Insecure Direct Object Reference (IDOR) vulnerabilities, which occur when an application exposes internal object references (such as database keys, file names, or user IDs) to the user without proper access control. Students will learn how to identify and exploit IDOR vulnerabilities and explore mitigation strategies.

Background / Scenario:

IDOR vulnerabilities allow attackers to manipulate references to access data they shouldn't be authorized to view or modify. By tampering with parameters like user IDs or file paths, attackers can bypass authorization mechanisms and gain access to restricted resources.

Required Resources:

  • Internet access
  • A web browser
  • A vulnerable web application or lab environment such as DVWA, OWASP Juice Shop, or Mutillidae

Instructions:

Part 1: Identifying Potential IDOR Vulnerabilities

  1. Understanding IDOR:
    IDOR occurs when internal object references (like user IDs, file names, etc.) are exposed to users without sufficient access control checks.
    • Example: https://store.h4cker.org/orders/1234 may display order information for Order ID 1234.
      An attacker could change the URL to https://store.h4cker.org/orders/1235 to view another user's order, exploiting an IDOR vulnerability.

  1. Question 1:
    You want to determine if a web application has authorization-based vulnerabilities. Which two exploits would you attempt to identify such vulnerabilities?
    (Choose all that apply.)

    • A) HTTP parameter pollution
    • B) Insecure Direct Object Reference
    • C) Default credentials
    • D) Session hijacking
    • E) Kerberos weakness

Part 2: Simulating an IDOR Attack

  1. Testing for IDOR in User Accounts:

    • Navigate to your web application and log in as a regular user.
    • Locate a URL with an ID parameter that references a user profile, such as:
      https://app.example.com/user/profile?user_id=1234
    • Change the user_id parameter to another user’s ID (e.g., user_id=1235) and see if you can access or modify that user’s information.

    Question 2: What happens when you change the user ID?

    • Are you able to access another user's data?
    • Does the application properly restrict access?

Part 3: Exploiting IDOR in File Downloads

  1. Testing File Access via IDOR:

    • Some applications store sensitive documents with predictable URLs, such as:
      https://app.example.com/download/file?file_id=5678
    • Change the file_id parameter to see if you can download files that do not belong to your account (e.g., file_id=5679).

    Question 3: Were you able to download unauthorized files by modifying the file_id?

    • Explain the potential risks of such an attack if sensitive documents (e.g., invoices, contracts) are exposed via IDOR.

Part 4: Testing for IDOR in E-commerce Applications

  1. Order History Manipulation:

    • Log in as a regular user and navigate to the order history section of an e-commerce site, such as:
      https://shop.example.com/order/details?order_id=789
    • Change the order_id to another value to see if you can access details about other users' orders (e.g., order_id=790).

    Question 4:

    • Were you able to view or modify the details of another user's order?
    • If so, what sensitive information was exposed (e.g., customer name, address, payment information)?

Part 5: Mitigation Strategies for IDOR

  1. Research Mitigation Techniques:
    Conduct online research on how web applications can prevent IDOR vulnerabilities.
    • What are some common best practices for preventing unauthorized access to internal object references?
    • How can developers ensure proper authorization checks are in place before processing object references?

  1. Question 5: What are three methods to mitigate IDOR vulnerabilities?
    (Choose all that apply.)

    • A) Use randomized and unpredictable identifiers for objects
    • B) Implement role-based access controls
    • C) Use parameterized queries to prevent SQL injection
    • D) Avoid exposing object references in URLs
    • E) Log out users automatically after 5 minutes of inactivity

Part 6: Bonus Challenge - Exploiting IDOR in Web Applications

  1. Find an IDOR in a Real or Test Environment:
    • Set up DVWA or OWASP Juice Shop and attempt to exploit an IDOR vulnerability in the web application.
    • Submit a report documenting the following:
      • The URL you manipulated to exploit the IDOR
      • The data or resource you gained unauthorized access to
      • Potential impact if this vulnerability were exploited in a real-world scenario
      • How you would fix the vulnerability to prevent future exploitation

Reflection Questions

  • Question 6: Why are IDOR vulnerabilities so dangerous in applications that handle sensitive data (e.g., financial, medical, personal information)?

  • Question 7: How can an attacker discover which internal object references (like user IDs or file paths) to manipulate when testing for IDOR vulnerabilities?

  • Question 8: Explain how an IDOR vulnerability could lead to privilege escalation in an application.

Lab Conclusion:

By completing this lab, students should have a solid understanding of Insecure Direct Object References (IDOR) and their risks. Students will also be equipped with practical knowledge on how to test for these vulnerabilities and implement proper mitigations.