文章总结： 本文深度解读OWASPAPISecurityTop10中排名前两位的风险：BOLA（对象级别授权失效）和认证失效。BOLA指API只验证登录未校验资源访问权限，典型场景包括用户资料访问和资源ID可预测，防护需实施对象所有权校验。认证失效指身份验证机制缺陷，如弱密码和JWT签名未校验。文章提供测试方法和防护方案，强调两者区别：BOLA是授权问题，认证失效是身份问题。 综合评分： 87 文章分类： 漏洞分析,渗透测试,红队,WEB安全,安全工具
S02 | OWASP API Security Top 10 深度解读（上）：BOLA 与认证失效
原创
simeon的文章 simeon的文章
小兵搞安全
2026年6月7日 16:40 北京
在小说阅读器读本章
去阅读
引言：从一起数据泄露事件说起
2024年，某金融科技公司接到用户投诉——明明没有授权，却发现自己可以查看其他用户的交易记录。技术团队排查后发现，问题出在一个看似”正常”的 API 接口上：
GET /api/v1/accounts/{account_id}/transactions
这个接口需要登录才能访问，但没有校验account_id是否属于当前登录用户。攻击者只需遍历 account_id，就能批量拉取任意用户的交易数据。
这就是 API01: Broken Object Level Authorization（BOLA）——API 安全领域排名第一的漏洞类型，也是本文要拆解的核心内容。
本文是「纵深解析：API 安全攻防实战手册」系列第二篇（S02），聚焦 OWASP API Security Top 10 中排名前两位的风险：BOLA（对象级别授权失效） 和 API02: Broken Authentication（认证失效）。
两者的关系很清晰：
- BOLA 是”我知道你是谁，但我不检查你是否有权访问这个对象”
- 认证失效 是”我根本不知道你是谁”
一个是权限问题，一个是身份问题。下面逐一拆解。
📌系列导航说明
本系列共 6 篇，系统覆盖 API 安全攻防知识体系：
- S01：API 安全方法论——为什么 API 是企业最重要的攻击面
- S02（本文）：OWASP API Top 10 上篇——BOLA 与认证失效
- S03：OWASP API Top 10 下篇——BFLA 与注入攻击
- S04：API 渗透测试实战全流程
- S05：RESTful API 安全攻防专题
- S06：GraphQL 安全攻防专题
一、API01: Broken Object Level Authorization（BOLA）
1.1 什么是 BOLA
BOLA（Broken Object Level Authorization） 是指 API 在访问某个特定资源（如用户数据、订单、文件）时，只验证了用户是否已登录，却没有校验用户是否有权访问这个具体的资源。
关键区分：BOLA 与 BFLA
OWASP 将对象级和功能级授权失效分别列为 API1 和 API5：
- API1: BOLA（Object）——对象级授权失效，攻击目标为数据。”你能访问这个对象吗？”通常表现为水平越权，即访问同级用户的资源（如查看别人的订单）。
- API5: BFLA（Function）——功能级授权失效，攻击目标为操作。”你有权调用这个功能吗？”通常表现为垂直越权，即低权限用户调用高权限功能（如普通用户删除管理员账户）。
两者核心区别：BOLA 针对”数据对象”，BFLA 针对”功能方法”。实际渗透测试中，两者经常组合使用——先 BFLA 获取管理员权限，再 BOLA 横向访问数据。
1.2 BOLA 的典型场景
BOLA 漏洞广泛存在于以下场景：
表2-1 BOLA 漏洞典型场景
| | | |
| — | — | — |
| 场景类型 | 描述 | 风险等级 |
| 用户资料访问 | GET /users/{user_id} 未校验当前用户是否有权查看 | 高 |
| 资源 ID 可预测 | 订单号、文件 ID 采用顺序递增或简单哈希 | 高 |
| 嵌套资源未鉴权 | GET /orgs/{org_id}/projects/{project_id} 只校验了 org 权限 | 中 |
| 间接对象引用 | 使用内部 ID（如数据库主键）而非随机化引用 | 高 |
| 批量操作未校验 | POST /batch-delete 传入多个资源 ID，未逐个校验所有权 | 极高 |
1.3 真实案例：据安全情报平台引述的行业案例
据 CVE Details 收录的漏洞统计，2023年多起 API 数据泄露事件与对象级授权缺失直接相关，其中社交平台和电商平台是重灾区：
- 漏洞类型： 攻击者通过遍历用户 ID 或订单 ID，在无需额外认证的情况下访问其他用户的私密数据
- 常见问题： 接口要求登录但未校验资源归属，或使用顺序递增的数字 ID 使遍历成为可能
- 典型影响： 用户私信、订单详情、收货地址、支付信息等敏感数据批量泄露
据 IBM X-Force 威胁情报报告，电商平台因订单 ID 可预测导致的 BOLA 漏洞是高频数据泄露类型。攻击者通过分析订单编号规律（如 ORD-20230601-XXXXXX，后六位为递增数字），在无需认证的情况下批量访问其他用户的订单详情，包括收货地址、联系方式、支付金额等敏感信息。
注： 上述案例均为据公开漏洞数据库和威胁情报报告引述的行业典型场景，非针对特定厂商的独家披露。如需核实，建议读者检索对应漏洞库（CVE Details：https://www.cvedetails.com）或 IBM X-Force 报告原文。
1.4 BOLA 漏洞测试方法
步骤一：识别可预测的资源标识符
资源标识符（Object Identifier）是 BOLA 攻击的入口。常见的类型包括：
| | | |
| — | — | — |
| 标识符类型 | 示例 | 可预测性 |
| 数字 ID | user_id=12345 | 高（顺序递增） |
| UUID | uuid=550e8400-e29b-41d4-a716-446655440000 | 低 |
| 哈希值 | id=sha256(fb83...ab12) | 中 |
| 字母数字混编 | file=doc_7x9k2m.pdf | 中 |
测试命令（Burp Suite 实战）：
# 使用 Burp Suite Intruder 进行 ID 遍历测试
# 配置 Payload 类型为 Numbers，范围 10000-99999，步长 1
# 同时配合正则匹配，识别敏感响应：
# 匹配模式："(user_id|phone|email|address)" : "[^"]+"
步骤二：验证水平越权
测试场景： 以用户 A 身份登录，获取自己的资源列表，记录资源 ID 格式。
测试命令（cURL）：
# 用户 A 登录，获取 Token
curl -X POST https://api.target.com/auth/login \
-H "Content-Type: application/json" \
-d '{"username":"[email protected]","password":"password123"}'
# 假设返回：{"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...", "user_id": 1001}
# 用户 A 尝试访问自己的资源（预期：成功）
curl -X GET https://api.target.com/accounts/1001 \
-H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
# 用户 A 尝试访问用户 B 的资源（预期：403 Forbidden）
# 如果返回 200 且包含数据，则存在 BOLA 漏洞
curl -X GET https://api.target.com/accounts/1002 \
-H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
步骤三：验证功能级越权（管理员接口）
测试场景： 普通用户尝试访问管理员专属接口（属于 BFLA，即 API05 范畴）。
测试命令（cURL）：
# 普通用户 Token
USER_TOKEN="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
# 尝试访问管理员接口（预期：403 Forbidden）
# 如果返回 200 或包含管理面板数据，则存在功能级越权（BFLA）
curl -X GET https://api.target.com/api/admin/users \
-H "Authorization: Bearer $USER_TOKEN"
步骤四：自动化测试工具
推荐使用以下工具进行 BOLA 漏洞扫描：
| | | | | — | — | — | | 工具 | 类型 | 说明 | | Burp Suite + Autorize | [安全专用] | 检测水平/垂直越权的权威工具 | | OWASP Zap | [安全专用] | 免费，支持 BOLA 检测脚本 | | API Test Armory | [安全专用] | 专注 API 安全测试 | | Postman | [通用] | 配合环境变量实现参数化测试 |
1.5 BOLA 漏洞防护方案
表2-2 BOLA 防护措施对照表
| | | | | — | — | — | | 防护层次 | 具体措施 | 实现难度 | | 身份校验 | 每次请求验证 JWT/Token 有效性 | 低 | | 对象授权 | 对每个资源访问请求，校验用户是否有权操作该对象 | 中 | | 随机化 ID | 使用 UUID 替代可预测的顺序数字 ID | 低 | | 间接引用映射 | 使用服务器端映射表，将外部 ID 转换为内部 ID | 中 | | 审计日志 | 记录所有资源访问操作，便于异常行为分析 | 低 | | 速率限制 | 限制单用户/单 IP 的资源请求频率 | 低 |
防护代码示例（Python/Flask）：
# ❌ 错误写法：只校验登录，未校验对象所有权
@app.route('/users/<int:user_id>')
def get_user(user_id):
if not current_user.is_authenticated:
return jsonify({"error": "Unauthorized"}), 401
return jsonify(db.get_user(user_id)) # 未检查所有权
# ✅ 正确写法：校验对象所有权
@app.route('/users/<int:user_id>')
def get_user(user_id):
if not current_user.is_authenticated:
return jsonify({"error": "Unauthorized"}), 401
# 核心防护：确保当前用户拥有该账户
if current_user.id != user_id and not current_user.is_admin:
return jsonify({"error": "Forbidden"}), 403
return jsonify(db.get_user(user_id))
二、API02: Broken Authentication（认证失效）
2.1 什么是认证失效
认证失效（Broken Authentication） 是指 API 无法正确验证用户身份，或验证机制存在可被绕过的缺陷。与 BOLA 不同，认证失效的核心问题是：API 不知道”你是谁”。
关键区分：认证 vs 授权
- 认证（Authentication）：验证”你是谁”——用户名/密码、Token、JWT
- 授权（Authorization）：验证”你能做什么”——权限、角色、访问控制
API02 关注认证层面，BOLA 关注授权层面。两者经常被混淆，但漏洞成因和防护方案完全不同。
2.2 认证失效的典型场景
表2-3 认证失效漏洞典型场景
| | | |
| — | — | — |
| 场景类型 | 描述 | 风险等级 |
| 弱密码策略 | 允许弱密码（123456、”password”） | 高 |
| 敏感信息明文传输 | Token、Session ID 在 URL 中暴露 | 高 |
| Token 未设置过期 | JWT 没有 exp 声明或永不过期 | 高 |
| 认证逻辑可绕过 | 错误响应信息泄露账号是否存在 | 中 |
| MFA 未强制 | 多因素认证为可选 | 中 |
| 密码重置漏洞 | Token 可预测或可重复使用 | 极高 |
2.3 JWT 认证的常见缺陷
JWT（JSON Web Token）是现代 API 认证的主流方案，但错误实现会带来严重风险。
缺陷一：使用弱签名算法
问题： 使用 HS256 而非 RS256，且密钥可预测。
攻击演示：
# 捕获 JWT Token
TOKEN="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
# 使用 jwt_tool 解密分析
python3 jwt_tool.py $TOKEN -T
# 如果发现使用 HS256，尝试暴力破解密钥
python3 jwt_tool.py $TOKEN -C -d /usr/share/wordlists/jwt_secrets.txt
缺陷二：未校验签名有效性
问题： 服务端接受”alg: none”或”alg: HS256″且使用弱密钥。
攻击演示（Python）：
import jwt
import base64
# 构造恶意 Token：使用 none 算法 + 修改用户身份
header = base64.b64encode(b'{"alg":"none","typ":"JWT"}').decode().rstrip("=")
payload = base64.b64encode(b'{"sub":"12345","role":"admin","exp":9999999999}').decode().rstrip("=")
malicious_token = f"{header}.{payload}."
# 发送到 API
import requests
response = requests.get("https://api.target.com/admin",
headers={"Authorization": f"Bearer {malicious_token}"})
print(response.status_code, response.text)
缺陷三：敏感信息未加密
问题： JWT payload 使用 Base64 编码，可被直接解码读取。
# 解码 JWT（无需密钥）
echo "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." | cut -d. -f2 | base64 -d
# 输出：{"sub":"12345","email":"[email protected]","role":"admin"}
2.4 OAuth 2.0 的认证失效风险
OAuth 2.0 是第三方登录的行业标准，但配置不当会导致严重漏洞。
风险一：Redirect URI 校验不严格
问题： 允许 http://localhost 或通配符域。
# 利用本地主机跳转窃取授权码
# 1. 构造恶意回调链接
malicious_redirect = "http://localhost:8080/callback?code=STOLEN_CODE"
# 2. 诱导用户点击授权链接
auth_url = f"https://auth.provider.com/oauth/authorize?client_id=APP_ID&redirect_uri={malicious_redirect}&response_type=code"
# 3. 由于 redirect_uri 允许 localhost，攻击者可在本地监听端口获取 code
风险二：Authorization Code 可被拦截
问题： 未使用 PKCE，且传输层未加密。
风险三：Token 存储不安全
问题： Access Token 存储在 LocalStorage（可被 XSS 窃取）。
2.5 真实案例：据安全媒体引述的行业事件
据 The Hacker News 公开报道，2022年某知名云服务商被发现存在 OAuth 认证漏洞，攻击者通过构造钓鱼页面，利用 Redirect URI 配置缺陷窃取 Authorization Code，进而劫持用户会话。据公开报道，该漏洞影响规模达数十万用户。
据 Salt Security 公开的 API 安全威胁研究报告，2024年某金融平台被发现存在 JWT 认证绕过漏洞：服务端接受任意伪造的 JWT Token，仅校验格式而非签名正确性，导致攻击者可构造任意用户身份的 Token 执行未授权操作。
注： 上述案例均为据 The Hacker News（https://thehackernews.com）和 Salt Security（https://salt.security）公开报道/研究报告引述的行业典型事件，非针对特定厂商的独家披露。
2.6 认证失效测试方法
步骤一：分析认证流程
# 抓取登录请求，分析认证机制
curl -v -X POST https://api.target.com/auth/login \
-H "Content-Type: application/json" \
-d '{"username":"[email protected]","password":"wrongpass"}'
# 分析响应头：是否包含 Session Token、JWT、Set-Cookie
# 分析响应体：是否泄露敏感信息（如用户 ID、权限列表）
步骤二：测试 JWT 安全
# 使用 jwt_tool 进行全面检测
python3 jwt_tool.py -t https://api.target.com/api/user -rh "Authorization: Bearer YOUR_TOKEN" -M pb
# 检测项：
# 1. alg 头部是否可被修改为 none
# 2. kid（Key ID）是否可预测
# 3. jku/x5u 是否指向可控地址
# 4. exp 是否缺失或设置为未来时间
步骤三：测试密码重置流程
# 1. 请求密码重置链接
curl -X POST https://api.target.com/auth/forgot-password \
-d "[email protected]"
# 2. 分析重置 Token 是否可预测（时间戳、用户 ID 哈希）
# 3. 测试 Token 是否可重复使用
# 4. 测试 Token 是否绑定 IP 或 User-Agent
2.7 认证失效防护方案
表2-4 认证机制防护措施对照表
| | | | | — | — | — | | 防护措施 | 描述 | 优先级 | | 强制密码复杂度 | 至少 8 位，含大小写字母、数字、特殊字符 | 高 | | 账户锁定策略 | 连续 5 次失败后锁定 15 分钟 | 高 | | MFA 强制 | 所有用户强制启用多因素认证 | 高 | | JWT 安全配置 | 使用 RS256，禁止 alg: none，添加 exp/iat/iss 校验 | 高 | | OAuth PKCE | 所有 OAuth 流程启用 PKCE 扩展 | 中 | | Redirect URI 严格校验 | 白名单模式，不允许通配符 | 高 | | Token 安全存储 | 使用 HttpOnly Cookie，而非 LocalStorage | 高 | | 敏感操作二次验证 | 转账、修改密码等操作需额外验证 | 中 |
JWT 安全配置示例（Python/PyJWT）：
import jwt
from datetime import datetime, timedelta
# 签名时添加完整声明
payload = {
"sub": user_id,
"iat": datetime.utcnow(),
"exp": datetime.utcnow() + timedelta(hours=1),
"iss": "api.target.com",
"role": "user"
}
# 使用 RS256（非对称加密）
private_key = open("private.pem").read()
token = jwt.encode(payload, private_key, algorithm="RS256")
# 验证时严格校验所有声明
public_key = open("public.pem").read()
try:
decoded = jwt.decode(
token,
public_key,
algorithms=["RS256"],
issuer="api.target.com",
options={"require": ["exp", "iat", "sub"]}
)
except jwt.ExpiredSignatureError:
return jsonify({"error": "Token expired"}), 401
except jwt.InvalidIssuerError:
return jsonify({"error": "Invalid issuer"}), 401
三、BOLA 与认证失效的关联
在真实攻击场景中，BOLA 和认证失效往往不是孤立存在的。
表2-5 攻击路径：BOLA + 认证失效的组合利用
| | | | | — | — | — | | 攻击阶段 | 利用的漏洞 | 攻击结果 | | 第一步 | 认证失效：获取任意用户身份 | 获得合法 Token | | 第二步 | BOLA：未校验资源所有权 | 访问其他用户数据 | | 第三步 | 业务逻辑漏洞：批量导出 | 数据批量窃取 |
这种”认证绕过 + 越权访问”的组合拳，是近年来大规模数据泄露的主要攻击模式。
四、实战工具清单
表2-6 BOLA 与认证失效测试工具对照表
| | | | | — | — | — | | 工具名称 | 适用漏洞 | 下载地址 | | Burp Suite Professional | BOLA、认证绕过、JWT 攻击 | https://portswigger.net/burp | | OWASP Zap | 被动扫描 BOLA、认证检测 | https://www.zaproxy.org | | jwt_tool | JWT 安全分析、签名伪造 | https://github.com/ticarpi/jwt_tool | | OAuth Security Cheat Sheet | OAuth 配置检测 | https://cheatsheetseries.owasp.org | | SQLMap | API SQL 注入（配合认证绕过） | https://sqlmap.org |
本章小结
本文拆解了 OWASP API Security Top 10 中排名前两位的风险类型：
BOLA（对象级别授权失效）：
核心问题：知道你是谁，但不知道你有没有权访问这个对象。
防护关键：每次资源访问都要校验所有权，不依赖隐式信任。
认证失效：
核心问题：不知道你是谁。
防护关键：强密码策略 + JWT 安全配置 + MFA 强制 + OAuth 严格校验。
两者组合使用是数据泄露的主流攻击路径。在真实渗透测试中，建议先找认证绕过入口，再利用 BOLA 横向移动。
以上是 S02 上篇的全部内容。下篇（S03）我们将深入 BFLA 与注入攻击的实战细节，并给出 BOLA vs BFLA 的完整对比。
互动话题
💬思考题：
你在测试或开发中遇到过哪些 BOLA 或认证失效的案例？是测试工具发现的，还是业务反馈的？
欢迎在评论区分享你的经历，也欢迎提出你关心的问题，我会选典型问题做深度解答。
下期预告
S03 | OWASP API Security Top 10 深度解读（下）：BFLA 与注入攻击
下期将聚焦 API05: Broken Function Level Authorization (BFLA) 和 API07: Injection。
很多人分不清 BOLA 和 BFLA——名字太像了。下期我会用一张表说清楚两者的本质区别：BOLA 是”访问控制”问题（针对数据），BFLA 是”功能滥用”问题（针对操作）。同时，API 注入攻击的实战手法（SQL 注入、NoSQL 注入、命令注入）也会在 S03 详细拆解。
预告：BOLA 排第一，但 90% 的人其实分不清 BOLA 和 BFLA——下期拆解这两者的本质区别和绕过手法。
参考资料
[1] OWASP, “OWASP API Security Top 10 2023”, https://owasp.org/API-Security/
[2] CVE Details, “API Security Vulnerabilities”, https://www.cvedetails.com
[3] IBM X-Force, “Threat Intelligence Index Report”, https://www.ibm.com/security/xforce
[4] The Hacker News, “OAuth Vulnerability Disclosed in Cloud Service”, https://thehackernews.com
[5] Salt Security, “API Security Threat Landscape Report 2024”, https://salt.security
[6] NIST, “JSON Web Token (JWT) Best Practices”, https://pages.nist.gov/800-63-3/
[7] PortSwigger, “JWT Authentication Vulnerabilities”, https://portswigger.net/web-security/jwt
[8] OWASP, “OAuth 2.0 Security Cheat Sheet”, https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Security_Cheat_Sheet.html
[9] jwt.io, “JSON Web Tokens Debugger”, https://jwt.io
[10] GitHub ticarpi, “jwt_tool – JWT Security Testing Tool”, https://github.com/ticarpi/jwt_tool
作者：小兵搞安全
专注信息网络安全技术研究，提供专业研究报告、最新原创技术研究成果、安全咨询服务。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：小兵搞安全 simeon的文章 simeon的文章《S02 | OWASP API Security Top 10 深度解读（上）：BOLA 与认证失效》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
![[译苑雅集vol.13]Cloudflare：AI爬虫吃掉流量之后，内容该怎么收费？](/images/random/titlepic/2.jpg)
评论