Zakaria
218 lines
10 KiB
Markdown
218 lines
10 KiB
Markdown
---
|
||
name: idor
|
||
description: IDOR/BOLA testing for object-level authorization failures and cross-account data access
|
||
---
|
||
|
||
# IDOR
|
||
|
||
Object-level authorization failures (BOLA/IDOR) lead to cross-account data exposure and unauthorized state changes across APIs, web, mobile, and microservices. Treat every object reference as untrusted until proven bound to the caller.
|
||
|
||
## Attack Surface
|
||
|
||
**Scope**
|
||
- Horizontal access: access another subject's objects of the same type
|
||
- Vertical access: access privileged objects/actions (admin-only, staff-only)
|
||
- Cross-tenant access: break isolation boundaries in multi-tenant systems
|
||
- Cross-service access: token or context accepted by the wrong service
|
||
|
||
**Reference Locations**
|
||
- Paths, query params, JSON bodies, form-data, headers, cookies
|
||
- JWT claims, GraphQL arguments, WebSocket messages, gRPC messages
|
||
|
||
**Identifier Forms**
|
||
- Integers, UUID/ULID/CUID, Snowflake, slugs
|
||
- Composite keys (e.g., `{orgId}:{userId}`)
|
||
- Opaque tokens, base64/hex-encoded blobs
|
||
|
||
**Relationship References**
|
||
- parentId, ownerId, accountId, tenantId, organization, teamId, projectId, subscriptionId
|
||
|
||
**Expansion/Projection Knobs**
|
||
- `fields`, `include`, `expand`, `projection`, `with`, `select`, `populate`
|
||
- Often bypass authorization in resolvers or serializers
|
||
|
||
## High-Value Targets
|
||
|
||
- Exports/backups/reporting endpoints (CSV/PDF/ZIP)
|
||
- Messaging/mailbox/notifications, audit logs, activity feeds
|
||
- Billing: invoices, payment methods, transactions, credits
|
||
- Healthcare/education records, HR documents, PII/PHI/PCI
|
||
- Admin/staff tools, impersonation/session management
|
||
- File/object storage keys (S3/GCS signed URLs, share links)
|
||
- Background jobs: import/export job IDs, task results
|
||
- Multi-tenant resources: organizations, workspaces, projects
|
||
|
||
## Reconnaissance
|
||
|
||
**Parameter Analysis**
|
||
- Pagination/cursors: `page[offset]`, `page[limit]`, `cursor`, `nextPageToken` (often reveal or accept cross-tenant/state)
|
||
- Directory/list endpoints as seeders: search/list/suggest/export often leak object IDs for secondary exploitation
|
||
- Find undocumented params with `arjun -u <url>` (GET) or `arjun -u <url> -m POST` —
|
||
surfaces hidden filters like `?include_deleted=1`, `?as_user=…`, `?owner_id=…`
|
||
that frequently widen the IDOR surface.
|
||
|
||
**Enumeration Techniques**
|
||
- Alternate types: `{"id":123}` vs `{"id":"123"}`, arrays vs scalars, objects vs scalars
|
||
- Edge values: null/empty/0/-1/MAX_INT, scientific notation, overflows
|
||
- Duplicate keys/parameter pollution: `id=1&id=2`, JSON duplicate keys `{"id":1,"id":2}` (parser precedence)
|
||
- Case/aliasing: userId vs userid vs USER_ID; alt names like resourceId, targetId, account
|
||
- Path traversal-like in virtual file systems: `/files/user_123/../../user_456/report.csv`
|
||
|
||
**UUID/Opaque ID Sources**
|
||
- Logs, exports, JS bundles, analytics endpoints, emails, public activity
|
||
- Time-based IDs (UUIDv1, ULID) may be guessable within a window
|
||
|
||
## Key Vulnerabilities
|
||
|
||
### Horizontal & Vertical Access
|
||
|
||
- Swap object IDs between principals using the same token to probe horizontal access
|
||
- Repeat with lower-privilege tokens to probe vertical access
|
||
- Target partial updates (PATCH, JSON Patch/JSON Merge Patch) for silent unauthorized modifications
|
||
|
||
### Bulk & Batch Operations
|
||
|
||
- Batch endpoints (bulk update/delete) often validate only the first element; include cross-tenant IDs mid-array
|
||
- CSV/JSON imports referencing foreign object IDs (ownerId, orgId) may bypass create-time checks
|
||
|
||
### Secondary IDOR
|
||
|
||
- Use list/search endpoints, notifications, emails, webhooks, and client logs to collect valid IDs
|
||
- Fetch or mutate those objects directly
|
||
- Pagination/cursor manipulation to skip filters and pull other users' pages
|
||
|
||
### Job/Task Objects
|
||
|
||
- Access job/task IDs from one user to retrieve results for another (`export/{jobId}/download`, `reports/{taskId}`)
|
||
- Cancel/approve someone else's jobs by referencing their task IDs
|
||
|
||
### File/Object Storage
|
||
|
||
- Direct object paths or weakly scoped signed URLs
|
||
- Attempt key prefix changes, content-disposition tricks, or stale signatures reused across tenants
|
||
- Replace share tokens with tokens from other tenants; try case/URL-encoding variations
|
||
|
||
### GraphQL
|
||
|
||
- Enforce resolver-level checks: do not rely on a top-level gate
|
||
- Verify field and edge resolvers bind the resource to the caller on every hop
|
||
- Abuse batching/aliases to retrieve multiple users' nodes in one request
|
||
- Global node patterns (Relay): decode base64 IDs and swap raw IDs
|
||
- Overfetching via fragments on privileged types
|
||
|
||
```graphql
|
||
query IDOR {
|
||
me { id }
|
||
u1: user(id: "VXNlcjo0NTY=") { email billing { last4 } }
|
||
u2: node(id: "VXNlcjo0NTc=") { ... on User { email } }
|
||
}
|
||
```
|
||
|
||
### Microservices & Gateways
|
||
|
||
- Token confusion: token scoped for Service A accepted by Service B due to shared JWT verification but missing audience/claims checks
|
||
- Trust on headers: reverse proxies or API gateways injecting/trusting headers like `X-User-Id`, `X-Organization-Id`; try overriding or removing them
|
||
- Context loss: async consumers (queues, workers) re-process requests without re-checking authorization
|
||
|
||
### Multi-Tenant
|
||
|
||
- Probe tenant scoping through headers, subdomains, and path params (`X-Tenant-ID`, org slug)
|
||
- Try mixing org of token with resource from another org
|
||
- Test cross-tenant reports/analytics rollups and admin views which aggregate multiple tenants
|
||
|
||
### WebSocket
|
||
|
||
- Authorization per-subscription: ensure channel/topic names cannot be guessed (`user_{id}`, `org_{id}`)
|
||
- Subscribe/publish checks must run server-side, not only at handshake
|
||
- Try sending messages with target user IDs after subscribing to own channels
|
||
|
||
### gRPC
|
||
|
||
- Direct protobuf fields (`owner_id`, `tenant_id`) often bypass HTTP-layer middleware
|
||
- Validate references via grpcurl with tokens from different principals
|
||
|
||
### Integrations
|
||
|
||
- Webhooks/callbacks referencing foreign objects (e.g., `invoice_id`) processed without verifying ownership
|
||
- Third-party importers syncing data into wrong tenant due to missing tenant binding
|
||
|
||
## Bypass Techniques
|
||
|
||
**Parser & Transport**
|
||
- Content-type switching: `application/json` ↔ `application/x-www-form-urlencoded` ↔ `multipart/form-data`
|
||
- Method tunneling: `X-HTTP-Method-Override`, `_method=PATCH`; or using GET on endpoints incorrectly accepting state changes
|
||
- JSON duplicate keys/array injection to bypass naive validators
|
||
|
||
**Parameter Pollution**
|
||
- Duplicate parameters in query/body to influence server-side precedence (`id=123&id=456`); try both orderings
|
||
- Mix case/alias param names so gateway and backend disagree (userId vs userid)
|
||
|
||
**Cache & Gateway**
|
||
- CDN/proxy key confusion: responses keyed without Authorization or tenant headers expose cached objects to other users
|
||
- Manipulate Vary and Accept headers
|
||
- Redirect chains and 304/206 behaviors can leak content across tenants
|
||
|
||
**Race Windows**
|
||
- Time-of-check vs time-of-use: change the referenced ID between validation and execution using parallel requests
|
||
|
||
**Blind Channels**
|
||
- Use differential responses (status, size, ETag, timing) to detect existence
|
||
- Error shape often differs for owned vs foreign objects
|
||
- HEAD/OPTIONS, conditional requests (`If-None-Match`/`If-Modified-Since`) can confirm existence without full content
|
||
|
||
## Chaining Attacks
|
||
|
||
- IDOR + CSRF: force victims to trigger unauthorized changes on objects you discovered
|
||
- IDOR + Stored XSS: pivot into other users' sessions through data you gained access to
|
||
- IDOR + SSRF: exfiltrate internal IDs, then access their corresponding resources
|
||
- IDOR + Race: bypass spot checks with simultaneous requests
|
||
|
||
## Testing Methodology
|
||
|
||
1. **Build matrix** - Subject × Object × Action matrix (who can do what to which resource)
|
||
2. **Obtain principals** - At least two: owner and non-owner (plus admin/staff if applicable)
|
||
3. **Collect IDs** - Capture at least one valid object ID per principal from list/search/export endpoints
|
||
4. **Cross-channel testing** - Exercise every action (R/W/D/Export) while swapping IDs, tokens, tenants
|
||
5. **Transport variation** - Test across web, mobile, API, GraphQL, WebSocket, gRPC
|
||
6. **Consistency check** - Same rule must hold regardless of transport, content-type, serialization, or gateway
|
||
|
||
## Validation
|
||
|
||
1. Demonstrate access to an object not owned by the caller (content or metadata)
|
||
2. Show the same request fails with appropriately enforced authorization when corrected
|
||
3. Prove cross-channel consistency: same unauthorized access via at least two transports (e.g., REST and GraphQL)
|
||
4. Document tenant boundary violations (if applicable)
|
||
5. Provide reproducible steps and evidence (requests/responses for owner vs non-owner)
|
||
|
||
## False Positives
|
||
|
||
- Public/anonymous resources by design
|
||
- Soft-privatized data where content is already public
|
||
- Idempotent metadata lookups that do not reveal sensitive content
|
||
- Correct row-level checks enforced across all channels
|
||
- Empty array / null returned for another user's resource — silent enforcement, not exposure; compare against the owner's view to confirm the data is actually missing rather than just hidden from the response shape
|
||
|
||
## Impact
|
||
|
||
- Cross-account data exposure (PII/PHI/PCI)
|
||
- Unauthorized state changes (transfers, role changes, cancellations)
|
||
- Cross-tenant data leaks violating contractual and regulatory boundaries
|
||
- Regulatory risk (GDPR/HIPAA/PCI), fraud, reputational damage
|
||
|
||
## Pro Tips
|
||
|
||
1. Always test list/search/export endpoints first; they are rich ID seeders
|
||
2. Build a reusable ID corpus from logs, notifications, emails, and client bundles
|
||
3. Toggle content-types and transports; authorization middleware often differs per stack
|
||
4. In GraphQL, validate at resolver boundaries; never trust parent auth to cover children
|
||
5. In multi-tenant apps, vary org headers, subdomains, and path params independently
|
||
6. Check batch/bulk operations and background job endpoints; they frequently skip per-item checks
|
||
7. Inspect gateways for header trust and cache key configuration
|
||
8. Treat UUIDs as untrusted; obtain them via OSINT/leaks and test binding
|
||
9. Use timing/size/ETag differentials for blind confirmation when content is masked
|
||
10. Prove impact with precise before/after diffs and role-separated evidence
|
||
|
||
## Summary
|
||
|
||
Authorization must bind subject, action, and specific object on every request, regardless of identifier opacity or transport. If the binding is missing anywhere, the system is vulnerable.
|