testing-for-broken-access-control

测试失效的访问控制

何时使用

• 在获得授权的渗透测试中，作为对 OWASP A01:2021 - 失效的访问控制的主要评估
• 在评估所有应用端点中基于角色的访问控制（RBAC）实现时
• 用于测试多租户应用，其中一个组织中的用户不应访问另一个组织的数据
• 在评估 API 端点是否存在缺失或不一致的授权检查时
• 在将权限提升和未授权访问作为主要关注点的安全审计中

前置条件

• 授权：针对目标的书面渗透测试协议
• Burp Suite Professional：带有 Authorize 扩展，用于自动化访问控制测试
• 多个测试账户：每个角色层级（admin、manager、user、guest）的账户
• 应用角色矩阵：记录每个角色应访问和不应访问的内容
• curl/httpie：用于在不同认证上下文中进行手动端点测试
• ffuf：用于发现可能缺少访问控制的隐藏端点

工作流

步骤 1：映射所有端点并创建访问控制矩阵

记录每个端点以及每个角色的预期访问级别。

# Extract all endpoints from Burp Site Map
# Target > Site Map > Right-click > Copy URLs in this host

# Build a matrix of endpoints vs roles:
# | Endpoint              | Admin | Manager | User | Guest |
# |-----------------------|-------|---------|------|-------|
# | GET /admin/dashboard  | Allow | Deny    | Deny | Deny  |
# | GET /api/users        | Allow | Allow   | Deny | Deny  |
# | PUT /api/users/{id}   | Allow | Deny    | Own  | Deny  |
# | DELETE /api/posts/{id} | Allow | Allow   | Own  | Deny  |

# Discover hidden endpoints
ffuf -u "https://target.example.com/FUZZ" \
  -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt \
  -mc 200,301,302,403 -fc 404 \
  -H "Authorization: Bearer $USER_TOKEN" \
  -o endpoints.json -of json

# API endpoint discovery
ffuf -u "https://target.example.com/api/v1/FUZZ" \
  -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt \
  -mc 200,201,204,301,302,401,403,405 -fc 404 \
  -H "Authorization: Bearer $USER_TOKEN"

步骤 2：配置自动化访问控制测试

设置 Burp Authorize 扩展，用于并行的基于角色的测试。

# Install Authorize extension:
# Burp > Extender > BApp Store > Search "Authorize" > Install

# Configuration for three-tier testing:
# 1. Browse the application as Admin (capture all requests)
# 2. In Authorize tab:
#    a. Add Regular User's session token in "Replace cookies/headers"
#    b. Optionally add a second row for Unauthenticated (no auth header)

# Example header replacement setup:
# Row 1 (Low-privilege user):
#   Cookie: session=low_priv_user_session
#   Authorization: Bearer low_priv_token
#
# Row 2 (Unauthenticated):
#   [Empty - removes all auth headers]

# Enable interception in Authorize:
# - Check "Intercept requests from Proxy"
# - Check "Intercept requests from Repeater"

# Authorize shows results as:
# Green  = Properly restricted (different response for different user)
# Red    = POTENTIALLY VULNERABLE (same response regardless of role)
# Orange = Uncertain (needs manual verification)

步骤 3：测试垂直权限提升

尝试使用较低权限账户访问较高权限功能。

# Collect tokens for each role
ADMIN_TOKEN="Bearer admin_jwt_here"
MANAGER_TOKEN="Bearer manager_jwt_here"
USER_TOKEN="Bearer user_jwt_here"

# Test admin endpoints with user token
ADMIN_ENDPOINTS=(
  "GET /admin/dashboard"
  "GET /admin/users"
  "POST /admin/users/create"
  "PUT /admin/settings"
  "DELETE /admin/users/5"
  "GET /admin/logs"
  "GET /admin/reports/export"
  "POST /admin/backup"
)

for entry in "${ADMIN_ENDPOINTS[@]}"; do
  method=$(echo "$entry" | cut -d' ' -f1)
  endpoint=$(echo "$entry" | cut -d' ' -f2)
  echo -n "$method $endpoint (as user): "
  status=$(curl -s -o /dev/null -w "%{http_code}" \
    -X "$method" \
    -H "Authorization: $USER_TOKEN" \
    -H "Content-Type: application/json" \
    "https://target.example.com$endpoint")
  if [ "$status" == "200" ] || [ "$status" == "201" ]; then
    echo "VULNERABLE ($status)"
  else
    echo "OK ($status)"
  fi
done

# Test with method override headers
curl -s -o /dev/null -w "%{http_code}" \
  -X POST \
  -H "Authorization: $USER_TOKEN" \
  -H "X-HTTP-Method-Override: DELETE" \
  "https://target.example.com/admin/users/5"

# Test with different HTTP methods
for method in GET POST PUT PATCH DELETE OPTIONS HEAD; do
  echo -n "$method /admin/users: "
  curl -s -o /dev/null -w "%{http_code}" \
    -X "$method" \
    -H "Authorization: $USER_TOKEN" \
    "https://target.example.com/admin/users"
  echo
done

步骤 4：测试水平权限提升

验证用户无法访问同一权限级别下属于其他用户的资源。

# User A (ID: 101) testing access to User B's (ID: 102) resources
USER_A_TOKEN="Bearer user_a_jwt"

RESOURCES=(
  "/api/users/102/profile"
  "/api/users/102/orders"
  "/api/users/102/messages"
  "/api/users/102/documents"
  "/api/users/102/settings"
  "/api/users/102/payment-methods"
)

for resource in "${RESOURCES[@]}"; do
  echo -n "GET $resource: "
  response=$(curl -s -w "\n%{http_code}" \
    -H "Authorization: $USER_A_TOKEN" \
    "https://target.example.com$resource")
  status=$(echo "$response" | tail -1)
  body_len=$(echo "$response" | head -n -1 | wc -c)
  if [ "$status" == "200" ] && [ "$body_len" -gt 50 ]; then
    echo "VULNERABLE ($status, $body_len bytes)"
  else
    echo "OK ($status)"
  fi
done

# Test write operations across users
curl -s -X PUT \
  -H "Authorization: $USER_A_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"Hacked","email":"[email protected]"}' \
  "https://target.example.com/api/users/102/profile" -w "%{http_code}"

# Test delete operations
curl -s -X DELETE \
  -H "Authorization: $USER_A_TOKEN" \
  "https://target.example.com/api/users/102/documents/1" -w "%{http_code}"

步骤 5：测试功能级访问控制

验证特定功能是否正确强制执行授权。

# Test unauthenticated access to protected endpoints
PROTECTED_ENDPOINTS=(
  "/api/user/profile"
  "/api/transactions"
  "/api/settings"
  "/admin/dashboard"
  "/api/export/users"
)

for endpoint in "${PROTECTED_ENDPOINTS[@]}"; do
  echo -n "No auth: GET $endpoint: "
  curl -s -o /dev/null -w "%{http_code}" \
    "https://target.example.com$endpoint"
  echo
done

# Test with expired/invalid tokens
curl -s -o /dev/null -w "%{http_code}" \
  -H "Authorization: Bearer invalid_token_here" \
  "https://target.example.com/api/user/profile"

# Test role manipulation in JWT claims
# If JWT contains role claim, try modifying it
# (requires JWT vulnerability - see JWT testing skill)

# Test parameter-based role escalation
curl -s -X PUT \
  -H "Authorization: $USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"role":"admin","is_admin":true,"permissions":["admin","superuser"]}' \
  "https://target.example.com/api/users/101/profile"

# Test registration with elevated role
curl -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"email":"[email protected]","password":"Test123!","role":"admin"}' \
  "https://target.example.com/api/auth/register"

步骤 6：测试多租户隔离

验证多租户应用中是否强制执行租户边界。

# User in Tenant A testing access to Tenant B's resources
TENANT_A_TOKEN="Bearer tenant_a_user_jwt"

# Direct tenant resource access
curl -s -H "Authorization: $TENANT_A_TOKEN" \
  "https://target.example.com/api/organizations/tenant-b-id/users" | jq .

curl -s -H "Authorization: $TENANT_A_TOKEN" \
  "https://target.example.com/api/organizations/tenant-b-id/settings" | jq .

# Test tenant switching via header
curl -s -H "Authorization: $TENANT_A_TOKEN" \
  -H "X-Tenant-ID: tenant-b-id" \
  "https://target.example.com/api/users" | jq .

# Test tenant ID in request body
curl -s -X POST \
  -H "Authorization: $TENANT_A_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"tenant_id":"tenant-b-id","query":"SELECT * FROM users"}' \
  "https://target.example.com/api/reports/custom"

# Enumerate tenant IDs
ffuf -u "https://target.example.com/api/organizations/FUZZ" \
  -w <(seq 1 100) \
  -H "Authorization: $TENANT_A_TOKEN" \
  -mc 200 -t 10 -rate 20

关键概念

概念	描述
垂直权限提升	较低权限用户访问较高权限功能（user -> admin）
水平权限提升	用户在同一权限级别下访问另一个用户的资源
功能级访问控制	对特定功能/特性进行授权检查，无论 URL 如何
RBAC	基于角色的访问控制 - 将权限分配给角色，将角色分配给用户
ABAC	基于属性的访问控制 - 基于用户/资源/环境属性的权限
多租户隔离	确保不同组织/租户之间的数据和功能分离
不安全的直接对象引用	通过操纵标识符访问对象而无需授权检查
缺失功能级检查	端点存在但未验证调用者是否有权限调用它

工具与系统

工具	用途
Burp Suite Professional	请求拦截和基于角色的测试
Authorize（Burp 扩展）	跨会话的自动化访问控制测试
AutoRepeater（Burp 扩展）	自动使用不同认证上下文重放请求
Postman	在角色之间切换环境的 API 测试
ffuf	发现可能缺少访问控制的隐藏端点
OWASP ZAP	具有上下文感知扫描的访问控制测试

常见场景

场景 1：无认证检查的管理面板

当使用普通用户的会话令牌访问 /admin/dashboard 端点时，它返回管理面板。前端隐藏了管理菜单，但后端未强制执行角色检查。

场景 2：缺少授权的 API 端点

DELETE /api/users/{id} 端点检查了认证（有效令牌）但未检查授权（admin 角色）。任何已认证用户都可以删除任何其他用户的账户。

场景 3：租户数据泄露

某 SaaS 应用在 API 请求头中使用 tenant_id。将 X-Tenant-ID 请求头改为其他租户的 ID 后，即可返回该租户的数据，从而绕过租户隔离。

场景 4：批量赋值导致角色提升

位于 PUT /api/users/{id} 的用户资料更新端点会在 JSON 请求体中接受 role 字段。在更新资料的同时提交 "role":"admin"，即可将用户提升为管理员。

输出格式

## Broken Access Control Assessment Report

**Target**: target.example.com
**Assessment Date**: 2024-01-15
**OWASP Category**: A01:2021 - Broken Access Control

### Access Control Matrix Results
| Endpoint | Admin | Manager | User | Guest | Expected | Actual |
|----------|-------|---------|------|-------|----------|--------|
| GET /admin/dashboard | 200 | 200 | 200 | 302 | Admin only | FAIL |
| DELETE /api/users/{id} | 200 | 200 | 200 | 401 | Admin only | FAIL |
| GET /api/users/other/profile | 200 | 200 | 200 | 401 | Own only | FAIL |
| PUT /api/users/other/settings | 200 | 200 | 200 | 401 | Own only | FAIL |
| GET /api/org/other-tenant | 200 | 200 | 200 | 401 | Same tenant | FAIL |

### Critical Findings
1. **Vertical Escalation**: Regular users can access /admin/* endpoints
2. **Horizontal IDOR**: Users can read/modify other users' profiles
3. **Tenant Isolation**: Cross-tenant data access via header manipulation
4. **Mass Assignment**: Role escalation via profile update endpoint

### Impact
- Complete administrative access for any authenticated user
- Full user data access across all accounts (15,000+ users)
- Cross-tenant data breach affecting 200+ organizations
- Account takeover via profile modification

### Recommendation
1. Implement server-side authorization checks on every endpoint
2. Use a centralized authorization middleware/framework
3. Enforce object-level authorization (verify ownership before access)
4. Validate tenant context server-side, never from client headers
5. Use allowlists for mass assignment (only permit expected fields)
6. Implement audit logging for all access control decisions