IDOR

Description: Insecure Direct Object References (IDOR) occur when an application exposes a reference to an internal object, such as a file, database record, or URL, without proper access control. This allows attackers to manipulate the reference to gain unauthorized access to data or functions.

Example with Scenario: Imagine an e-commerce website where users can view their order details by accessing a URL like http://example.com/order?id=1234. If the application does not verify whether the authenticated user is authorized to view order 1234, an attacker could change the id parameter to access other users' orders.

Payloads and Test Cases:

  1. Basic IDOR to Access Unauthorized Data:

    • URL: http://example.com/order?id=1234

    • Payload: Change id to another order number, e.g., http://example.com/order?id=1235

    • Test Case: Verify if the application allows access to the order details for id=1235 without proper authorization checks.

  2. IDOR in API Endpoints:

    • API Request: GET /api/user/1234/profile

    • Payload: Change user ID to another user's ID, e.g., GET /api/user/1235/profile

    • Test Case: Check if the API returns the profile details for user 1235 without authorization.

  3. IDOR in File Download:

    • URL: http://example.com/download?file=report1234.pdf

    • Payload: Change file parameter to another file name, e.g., http://example.com/download?file=report1235.pdf

    • Test Case: Ensure that the application prevents unauthorized file downloads by checking proper permissions.

  4. IDOR in User Management:

    • URL: http://example.com/admin/user/edit?id=1234

    • Payload: Change id to another user's ID, e.g., http://example.com/admin/user/edit?id=1235

    • Test Case: Verify if non-admin users can edit or view details of other users without proper authorization.

  5. IDOR in Account Settings:

    • URL: http://example.com/account/settings?id=1234

    • Payload: Change id to another account ID, e.g., http://example.com/account/settings?id=1235

    • Test Case: Check if users can access or modify other users' account settings.

  6. IDOR in Deletion Functionality:

    • URL: http://example.com/delete?file=1234

    • Payload: Change file parameter to another file ID, e.g., http://example.com/delete?file=1235

    • Test Case: Ensure that the application checks for proper authorization before allowing deletion of any resource.

Mitigation:

  1. Implement Proper Access Controls:

    • Ensure that every access to sensitive data or functionality checks if the user has the appropriate permissions.

    // Example in Java
User user = getCurrentUser();
Order order = orderService.getOrderById(orderId);
if (!order.getUser().equals(user)) {
    throw new UnauthorizedAccessException();
}

  2. Use Indirect References:

    • Instead of using direct references like database IDs, use indirect references that are mapped to internal objects securely.

    // Map indirect reference to internal ID
String orderRef = "ORD-1234-ABC";
Order order = orderService.getOrderByRef(orderRef);

  3. Input Validation and Sanitization:

    • Validate and sanitize user inputs to ensure they do not contain unauthorized references.

    if (!isValidId(orderId)) {
    throw new InvalidInputException();
}

  4. Log and Monitor Access:

    • Implement logging and monitoring to detect and respond to unauthorized access attempts.

    // Log access attempts
logger.info("User {} accessed order {}", user.getId(), orderId);

  5. Use Frameworks with Built-in Security:

    • Use security frameworks that provide built-in mechanisms for access control and authorization checks.

  6. Perform Regular Security Audits:

    • Regularly review and audit your codebase for potential IDOR vulnerabilities and fix them promptly.

PreviousXXENextSSTI

Last updated