OWASP Top 10 实战通关指南：总览篇

文章目录

- 先把"通关"定义清楚
- 十条分别在说什么（用人话）
- - [A01 失效的访问控制（Broken Access Control）](#A01 失效的访问控制（Broken Access Control）)
  - [A02 加密机制失败（Cryptographic Failures）](#A02 加密机制失败（Cryptographic Failures）)
  - [A03 注入（Injection）](#A03 注入（Injection）)
  - [A04 不安全设计（Insecure Design）](#A04 不安全设计（Insecure Design）)
  - [A05 安全配置错误（Security Misconfiguration）](#A05 安全配置错误（Security Misconfiguration）)
  - [A06 易受攻击和过时的组件（Vulnerable and Outdated Components）](#A06 易受攻击和过时的组件（Vulnerable and Outdated Components）)
  - [A07 标识和认证失败（Identification and Authentication Failures）](#A07 标识和认证失败（Identification and Authentication Failures）)
  - [A08 软件和数据完整性失败（Software and Data Integrity Failures）](#A08 软件和数据完整性失败（Software and Data Integrity Failures）)
  - [A09 安全日志和监控失败（Security Logging and Monitoring Failures）](#A09 安全日志和监控失败（Security Logging and Monitoring Failures）)
  - [A10 服务端请求伪造 SSRF（Server-Side Request Forgery）](#A10 服务端请求伪造 SSRF（Server-Side Request Forgery）)
- 一张图串起来（方便记）
- 实战通关：我建议的打法（总览级）
- - 第一步：先画资产和数据，不先开扫
  - [第二步：两周突击"权限 + 认证 + 注入"](#第二步：两周突击“权限 + 认证 + 注入”)
  - 第三步：配置与组件并行
  - [第四步：补设计和 SSRF](#第四步：补设计和 SSRF)
  - 第五步：日志与完整性托底
- 每条风险的"通关验收"长什么样
- 测试方法：不必上玄学，但要上对抗思维
- - [1. 手工探权限（非常值钱）](#1. 手工探权限（非常值钱）)
  - [2. 自动化扫描当辅助](#2. 自动化扫描当辅助)
  - [3. 代码评审看"边界"](#3. 代码评审看“边界”)
  - [4. 预发做一次"坏用户"演练](#4. 预发做一次“坏用户”演练)
- [工程上真正防住 Top 10 的，往往是这些"无聊物"](#工程上真正防住 Top 10 的，往往是这些“无聊物”)
- 组织怎么推，才不像安全部门自嗨

说起来有点尴尬。很多团队一提安全，第一反应就是"我们对照过 OWASP Top 10"。再追问一句：对照完呢？改了哪些接口？回归测了没？日志里能不能看见越权？现场常常就沉默了。

Top 10 不是考纲，更不是贴在墙上就灵的护身符。它更像一张事故高频地图：过去这些年，真实业务里反复砸钱、反复丢人、反复被通报的那几类问题，被社区收成了十条。你按图排查，效率会高很多；但如果你只背定义、不碰系统，通关永远停在口嗨。

先把"通关"定义清楚

我见过三种"假通关"：

第一种，安全问卷全打勾，生产上 Swagger 还裸着。

第二种，扫出八百个低危，Critical 挂着没人认领。

第三种，开发说"框架已经防了 SQL 注入"，然后拼接语句写在报表接口里。

在本指南里，通关更实际的意思是：

对每一类风险，你能指出它在你们系统里长什么样 ，有可重复的测试方法 ，有默认防住它的工程手段 ，出了事能在日志里追到人、追到请求。

分数不重要。能不能睡个安稳觉，才重要。

十条分别在说什么（用人话）

A01 失效的访问控制（Broken Access Control）

连续两版蝉联榜首，不是因为它高深，恰恰因为它土：用户只能看自己的订单，却改个 id=10086 就看见别人的；普通账号调用了管理端接口；本该服务端裁决的权限，前端藏了个按钮就当"禁了"。

实战里这类问题杀伤力极大，因为往往不需要什么花活，有登录态就行。越权、水平权限、垂直权限、未失效的 IDOR，都归这类。

通关感言：权限必须是服务端强制的；每个对象访问都要问"这个主体凭什么动这份数据"。

A02 加密机制失败（Cryptographic Failures）

以前叫敏感数据暴露，现在更强调你怎么用密码学------或更糟，你怎么以为自己在用。明文存密码、硬编码密钥、TLS 配成摆设、用自制"加密算法"、银行卡和身份证随便落日志，都属于这一家。

很多事故不是密码学论文级突破，是钥匙挂在门框上。

A03 注入（Injection）

SQL、LDAP、OS 命令、模板注入......本质都是：不可信输入进了解释器，还被当成指令的一部分。SQL 注入名气最大，但命令注入在运维接口、导出功能、图片处理里一点都不稀罕。

框架和预编译能挡住一大片，挡不住工程师图省事又把字符串拼回去。

A04 不安全设计（Insecure Design）

2021 新进榜，也是最容易被误解的一条。它不是说"代码写丑了"，而是说威胁建模根本没做：业务流程天然可被滥用------比如无限试券、短信轰炸、邀请奖励刷爆、工作流可绕过审批。

你把代码写得再干净，设计上允许羊毛党，安全后期只能贴膏药。

A05 安全配置错误（Security Misconfiguration）

默认口令、目录列表、多余端口、错误的云存储桶权限、生产开 Debug、管理端对公网、HTTP 头乱套......这类问题像办公室未锁的抽屉：单个看不高级，组合起来能要命。

云上尤其严重：一键创建很爽，默认策略很宽。

A06 易受攻击和过时的组件（Vulnerable and Outdated Components）

Log4Shell 让这条彻底破圈。你不写漏洞，依赖会替你写。更麻烦的是，很多团队说不清线上到底跑了哪些包、哪些传递依赖。

通关不靠"我们打算升级"，靠 SBOM、扫描进流水线、以及前面写过的修复 SLA。

A07 标识和认证失败（Identification and Authentication Failures）

弱口令、凭证塞进 URL、会话固定、验证码可绕、密码重置逻辑脑残、"记住我"变成永久通行证。认证是大门；门虚掩着，后面权限设计再漂亮也是摆设。

多因素认证很有用，但若重置流程只靠短信验证码且可被轰炸枚举，照样崩。

A08 软件和数据完整性失败（Software and Data Integrity Failures）

供应链那篇文章里的味道：不安全的 CI、不可信的插件、自动更新未校验、反序列化不可信数据、发布物没有签名验证。SolarWinds 是极端案例；日常更多是"构建机谁都能推"、"前端CDN资源没做完整性校验"。

A09 安全日志和监控失败（Security Logging and Monitoring Failures）

这条最冷，也最贵。出事了才发现：登录失败没记、管理操作没记、告警没人看、时钟不同步、日志可被攻击者顺便清空。

没有日志的安全，像没有行车记录仪的车险------理赔故事靠编。

A10 服务端请求伪造 SSRF（Server-Side Request Forgery）

应用替攻击者去请求内网地址：打云元数据、打企业Redis、打管理端口。功能上看只是"帮用户拉个远程图片/文档预览"，设计上却把服务器变成了内网代理。

云环境里，SSRF 经常是大案的第一脚。

一张图串起来（方便记）

你可以把十条想成进门到善后的链：

text 复制代码

设计是否防滥用？ ─────────────── A04
门禁（认证）是否靠谱？ ───────── A07
进门后能不能乱翻别人柜子？ ─── A01
输入会不会变成命令？ ───────── A03
出站会不会变内网代理？ ─────── A10
数据与密钥是否乱放？ ───────── A02
机器与框架是否裸奔？ ───────── A05
依赖是否在裸奔？ ───────────── A06
更新与构建是否被掉包？ ─────── A08
出事能不能看见、能不能响？ ─── A09

真实入侵往往连着打好几环：认证弱 → 越权 → 翻配置 → 吃漏洞组件 → 没人从日志里发现。

实战通关：我建议的打法（总览级）

别妄想两周"做完 Top 10"。按杠杆排序，反而快。

第一步：先画资产和数据，不先开扫

问清楚：

对外有哪些域名与 API；
哪几类数据最值钱（账号体系、支付、身份证、密钥）；
管理端在哪、谁能访问；
关键依赖谁维护。

没有这张图，扫描报告只是噪音工厂。

第二步：两周突击"权限 + 认证 + 注入"

这三样出大事的概率最高，修复路径也相对清楚：

所有对象接口做服务端鉴权测试（换用户、换角色、换资源 ID）；
登录、重置、验证码、会话生命周期走查；
有 SQL/命令/模板的地方查有没有拼接，补集成测试。

很多中小型团队只做完这三步，风险曲线就会明显下降。

第三步：配置与组件并行

配置问题适合清单化：云存储桶、安全组、默认账户、错误页、HTTP 头、管理端口。

组件问题适合工程化：仓库扫描、镜像扫描、升级 SLA（参见补丁管理那篇）。

第四步：补设计和 SSRF

对"发券、邀请、短信、文件预览、Webhook、导入 URL"做威胁建模。

凡是服务器帮用户发起请求的地方，默认按 SSRF 高危看：协议限制、域名白名单、禁内网网段、禁云元数据地址。

第五步：日志与完整性托底

没有前几步，日志是空转；有了前几步没日志，被打了还不知道。

最低标准：认证失败/成功、权限拒绝、管理操作、关键配置变更------要进集中日志，且有人看高危告警。

每条风险的"通关验收"长什么样

下面这张表不求学术完美，求评审时能问出口。

类别	你可以问团队的验收问题
A01	换一个普通用户 token，改资源 ID，是否 403？自动化测了几条？
A02	密码怎么存？密钥从哪来？日志里是否出现过完整证件号？
A03	新报表接口是否还有字符串拼 SQL？有无安全测试用例？
A04	刷接口、刷奖励的限速与风控在哪一层？
A05	生产是否还能看到调试栈？对象存储是否公共读？
A06	生产 SBOM 有没有？Log4j 那类库升级 SLA 是多少天？
A07	重置密码是否可枚举用户？会话是否可在注销后继续用？
A08	CI 产物是否签名/哈希校验？构建机谁能登录？
A09	昨天有没有失败登录峰值告警？谁收的？
A10	文件预览是否能打到 `169.254.169.254`？

问得出来、答得出来、还能演示------才叫通关，不叫背诵。

测试方法：不必上玄学，但要上对抗思维

1. 手工探权限（非常值钱）

准备两个账号：A、B，必要时再加一个管理员。

管理接口用普通 token 砸一次。

这套动作能挖出一半以上"其实很好修"的高危。

2. 自动化扫描当辅助

DAST/SAST/依赖扫描都要，但别迷信。扫描器擅长已知模式，不擅长你们奇葩业务流。

扫完必须分派、必须有结案标准，否则就是 PDF 垃圾场。

3. 代码评审看"边界"

评审时别只盯风格。盯：新接口有没有鉴权注解/中间件、有没有拼 SQL、有没有吃 URL 去服务端请求、有没有新序列化入口。

4. 预发做一次"坏用户"演练

找个懂业务的测试，专门扮演羊毛党/恶意商户。比安全部自己瞎点更接近真实。

工程上真正防住 Top 10 的，往往是这些"无聊物"

说句扫兴的：通关靠的多半不是酷炫 WAF 规则，而是------

统一的鉴权中间件 / 策略点（ABAC/RBAC 落地）；
参数化查询与命令参数数组，禁止拼接；
密钥托管与强制 HTTPS；
安全基线镜像与云配置策略即代码；
依赖升级流水线与例外封顶；
登录与权限拒绝日志 + 告警；
SSRF 防护库或统一出站网关。

WAF、RASP、商业扫描器有价值，但它们是补丁层。Top 10 的根治在设计和框架默认值。

组织怎么推，才不像安全部门自嗨

我踩过的坑：安全自己建了个 Jira 看板，开发从来不看。

比较行得通的做法是：

把 Top 10 映射到现有质量门禁，而不是另起一套黑话。例如：PR 模板增加"是否涉及鉴权/对外请求/新依赖"。
每个核心系统认领一个安全联络人，不一定全职，但要能扛修复优先级。
只强制门禁 Critical/High，先把伤口止住；低危别淹没信任。
用事故复盘反推条目：每出一次越权，就补一条自动化回归，让 A01 的墙变厚。

管理层爱听 Top 10，开发爱听"少返工"。把二者翻译成门禁和模板，比再开一次宣讲有用。