Video summary

How I Found IDORs That Shouldn’t Exist

Main summary

Key takeaways

Technology

Overview

The video discusses how to find IDORs (Insecure Direct Object References) in real web apps by exploiting edge cases in URL/path parsing, API versioning, and request handling.

The core idea: IDORs are extremely dangerous because access-control weaknesses behind endpoints can expose other users’ data once you identify and manipulate the right parameters/routes.

Key Concepts and Hunting Approach

  • IDORs are described as a “single endpoint” failing access control and revealing other customers’ data behind a wall.
  • The speaker emphasizes a mindset shift:
    • Don’t only try changing an ID (e.g., 10 → 9).
    • Instead, probe the assumptions the application makes about inputs and routing.
  • Effective hunting depends on finding where to look, not just whether an IDOR exists:
    • E-commerce: user-related pages may be public and HTML-rendered; better targets are orders / order state endpoints.
    • CRMs: focus on user management type endpoints.
  • Technique selection is tied to what the response reveals:
    • If input changes lead to different responses (403 / 404 / server error / “invalid ID”), those differences guide the next test.

Practical Techniques Demonstrated (API Endpoint Manipulation)

  1. Trailing slash / path normalization

    • Example: if /users/9 returns 403/404, try adding a slash variant after the object ID or path segment.

  2. Double slashes / obfuscated path

    • Try // and other path oddities (route normalization bugs can cause auth middleware to miss the request).
    • Also: insert double slashes between segments in alternative ways.

  3. Version downgrading

    • Call the same functionality on older API versions (e.g., v5 → v4/v3/v2/v1).
    • Legacy versions may skip or mishandle modern auth checks.

  4. Endpoint variant / sub-resource switching

    • If one endpoint (/users/{id}) blocks access, try related endpoints for the same object:
      • e.g., /users/{id}/details (personal data) or /users/{id}/orders (orders)
    • Goal: find a variant that returns data even when the “main” endpoint blocks.

  5. Multi-ID / filter parameter abuse

    • Combine multiple IDs (e.g., “9,8” / “10,9”) to alter parsing logic.
    • If comma/formatting fails, try other separators such as dot or alternative expected formats.
    • Use error messages like “invalid user ID” as signals for how parsing works.

  6. Type confusion (string vs integer)

    • Provide values that are not the expected numeric type to force alternate parsing paths.
    • Mentioned cases: use non-integer string forms and observe whether protections are bypassed.

  7. Leading zeros / alternate numeric formatting

    • Try representations like 09 or other zero-prefixed variants if normal integer formatting blocks access.

  8. Null termination / control character encoding

    • Add a null byte (or similar control-character payload) in the identifier/path to trigger inconsistent parsing between layers.

  9. Header/proxy-based bypass attempts

    • Attempts using headers such as:
      • X-Original-URL
      • X-Forwarded-For
    • The idea is to exploit routing/auth differences when the backend or proxy interprets these headers differently.

  10. “%20 bypass” (URL encoding space)

    • A “last resort” technique: encode a space as %20 to trigger inconsistent normalization between layers.
    • The speaker reports it worked in a real target case to retrieve other users’ details, described as a high-impact bug (around 7.7 CVSS).

Strategy / Checklist Emphasized

  • Start with JSON endpoints (not rendered HTML).
  • Make requests and watch:
    • status codes
    • error bodies
  • Aim for low-noise, iterative testing.
  • If one technique fails, combine multiple, such as:
    • version downgrading + encoding + trailing/path tweaks
  • Convert “boring” 403/404 into a real exploit chain by understanding:
    • what the server expects (integer/string),
    • how it parses/normalizes URLs,
    • and where mismatches occur between layers (proxy, router, auth middleware, backend).

Product / Review / Tutorial Context

  • The tutorial is tactical and focused on repeatable IDOR hunting techniques, not product comparisons.
  • The speaker mentions using a bug bounty platform:
    • They’ve been running on YesWeHack, citing fast triage and fast replies (sometimes same day / within hours).

Main Speakers or Sources

  • Speaker: “AmrSec” (host/author of the tutorial)
  • Platform mentioned: YesWeHack (background context, not presented as the tutorial source)

Original video