1. 安全基础与威胁建模
各位同学，欢迎来到《漏洞排查与安全加固实战指南》的第一章。
做安全这么多年，我见过太多团队一上来就拿着扫描器到处扫，扫出一堆漏洞列表就开始修。结果呢？修了又犯，犯了再修，永远在救火。说白了，就是没打好地基。
这一章，我们就来聊聊这个“地基”——安全基础与威胁建模。你想想看，连敌人是谁、从哪来、想干什么都不知道，你怎么防？
1.1 漏洞生命周期：从出生到消亡
一个漏洞，不是凭空出现的。它有自己的生命周期。理解这个周期，你才能知道在哪个阶段该做什么事。
核心观点： 漏洞管理不是一次性工作，而是一个持续改进的闭环。
我个人习惯把漏洞生命周期分成六个阶段：
- 发现 —— 可能是白帽子提交的，可能是内部测试发现的，也可能是黑客已经在利用了你才知道。
- 确认与评估 —— 这个漏洞是真的吗？影响范围多大？危害等级多高？
- 修复 —— 打补丁、改配置、加WAF规则，选哪种方式？
- 验证 —— 修复完了，真的修好了吗？有没有引入新问题？
- 复盘 —— 为什么会出现这个漏洞？流程上怎么避免再犯？
- 关闭 —— 确认无误，归档记录。
我在项目中遇到过最典型的反面教材：某团队发现了一个SQL注入漏洞，开发同学直接在生产库上改了段代码，没测试就上线了。结果呢？修是修了，但把另一个正常功能搞崩了，线上故障两小时。这就是跳过了“验证”阶段的后果。
避坑指南： 我曾经见过一个公司，漏洞库里有三年前的“已修复”漏洞，结果一复查，根本没修。为什么？因为当初负责修复的人离职了，没人跟进。所以，漏洞生命周期必须有系统记录和定期审计，不能靠人肉记忆。
1.2 常见攻击类型：OWASP Top 10 实战解读
说到攻击类型，OWASP Top 10 是绕不开的。但我不建议你死记硬背那十个名字。你得知道它们在实际业务里长什么样。
下面这张表，是我根据实战经验整理的，把 Top 10 和常见业务场景对应起来：
| 排名 | 漏洞类型 | 实战场景举例 | 我踩过的坑 |
|---|---|---|---|
| A01 | 失效的访问控制 | 普通用户通过修改URL中的ID，访问了管理员的后台 | 曾经有个电商项目，用户A能看到用户B的订单详情，就是因为后端没校验用户身份 |
| A02 | 加密机制失效 | 密码用MD5存储，或者HTTPS证书过期了还在用 | 某金融APP，敏感数据传输用的还是HTTP，抓包直接看明文 |
| A03 | 注入 | 登录框输入 ' OR 1=1 -- 直接绕过认证 |
我见过最离谱的，是开发把SQL查询拼在存储过程里，参数化查询形同虚设 |
| A04 | 不安全的设计 | 密码重置逻辑：只验证密保问题，不验证用户身份 | 某社交平台，通过生日和宠物名字就能改密码，这设计本身就有问题 |
| A05 | 安全配置错误 | 默认密码没改、目录列表开启、错误信息暴露堆栈 | Tomcat 管理后台默认密码 admin/admin，我扫到过不下20次 |
| A06 | 易受攻击和过时的组件 | 用了 Log4j 2.14 版本，或者 jQuery 1.7 | Log4j 漏洞爆发那晚，我通宵给客户排查，发现有人还在用 2.0 版本 |
| A07 | 身份认证和会话管理失效 | Session 没过期、Token 硬编码在前端 | 某内部系统，退出后Session还在，别人直接用原链接就能进去 |
| A08 | 软件和数据完整性失效 | CI/CD 流水线被篡改，或者依赖包被投毒 | 有次客户系统被植入后门，查了半天，发现是第三方库被篡改了 |
| A09 | 安全日志和监控不足 | 攻击者扫了三天，日志里一条记录都没有 | 某公司被勒索，想溯源，结果日志只保留24小时，啥也没留下 |
| A10 | 服务端请求伪造（SSRF） | 攻击者让服务器去访问内网资源，比如 http://127.0.0.1:6379 |
云上环境特别常见，元数据服务（169.254.169.254）经常被利用 |
小提示： 别被这十个名字吓到。实际工作中，A01（失效的访问控制）和 A03（注入） 占了漏洞总量的60%以上。先把这两个搞定，你的安全水平就能提升一大截。
1.3 威胁建模方法论：STRIDE 与 DREAD
好了，知道了漏洞长什么样，接下来就是怎么系统性地找出它们。这就用到威胁建模了。
我常用的两个方法论：STRIDE 用来分类威胁，DREAD 用来评估风险。两者配合使用，效果最好。
1.3.1 STRIDE：给威胁贴标签
STRIDE 是微软提出的，每个字母代表一类威胁：
- Spoofing（假冒）—— 冒充他人身份。比如伪造登录请求。
- Tampering（篡改）—— 修改数据。比如中间人改包。
- Repudiation（抵赖）—— 否认做过的事。比如没有操作日志。
- Information Disclosure（信息泄露）—— 敏感数据被看到。比如数据库被拖库。
- Denial of Service（拒绝服务）—— 让服务不可用。比如DDoS攻击。
- Elevation of Privilege（权限提升）—— 普通用户获得管理员权限。比如越权操作。
我建议你在做系统设计评审时，拿着这六个维度逐个过一遍。嗯，你会发现很多平时注意不到的问题。
1.3.2 DREAD：给威胁打分
威胁找到了，哪个先修？DREAD 就是用来排优先级的。
| 维度 | 说明 | 评分标准（1-10） |
|---|---|---|
| Damage | 造成的损失有多大 | 1=轻微，10=系统瘫痪/数据全丢 |
| Reproducibility | 复现难度 | 1=极难，10=随便点一下就能触发 |
| Exploitability | 利用难度 | 1=需要专家级技能，10=脚本小子都能搞 |
| Affected Users | 影响用户数 | 1=个别人，10=所有用户 |
| Discoverability | 被发现的可能性 | 1=几乎不可能，10=公开的POC到处是 |
计算方式：总分 = (D + R + E + A + D) / 5。总分越高，优先级越高。
实战建议： 我个人习惯把 DREAD 评分和业务影响结合起来。比如一个漏洞 DREAD 评分只有 6，但它影响的是核心交易系统，那我会把它提到最高优先级。别死板地只看分数。
1.4 知识体系总览：一张图看懂本章
下面这张图，把本章的核心逻辑串起来了。从漏洞生命周期，到攻击类型，再到威胁建模，最后落到安全加固。你把它记在脑子里，后面的章节就好理解了。
1.5 本章小结：打好地基再盖楼
这一章的内容，说白了就是三件事：
- 漏洞生命周期 —— 让你知道漏洞从哪来、到哪去，别做“修了又犯”的蠢事。
- OWASP Top 10 —— 让你知道敌人长什么样，别连 SQL 注入和 XSS 都分不清。
- STRIDE + DREAD —— 让你知道怎么系统性地找漏洞、排优先级，别像个无头苍蝇。
我记得刚入行时，带我的师傅说过一句话：“安全不是靠堆工具堆出来的，是靠脑子想出来的。” 这一章，就是帮你把脑子里的“安全思维”建立起来。后面的章节，我们会深入到具体的漏洞排查和加固操作。到时候你会发现，地基打得牢，后面盖楼才快。