1. Web安全概述：什么是Web安全、常见攻击类型、安全威胁模型、安全开发周期
大家好，我是你们这堂课的老朋友。咱们今天聊聊Web安全。说实话，我干这行十几年了，见过太多“上线前觉得没问题，上线后被打成筛子”的项目。Web安全，说白了就是保护你的网站、API、用户数据不被坏人搞破坏。它不只是防火墙和WAF的事，更是一种思维方式。
一句话总结：Web安全 = 识别风险 + 防御攻击 + 持续改进。它不是一次性工作，而是贯穿整个软件生命周期的习惯。
1.1 什么是Web安全？
Web安全，简单讲就是保护Web应用免受恶意攻击。攻击者可能想偷数据、篡改页面、让服务瘫痪，或者拿你的服务器当跳板。我个人的理解是：Web安全就是一场攻防博弈。你防守的点越多，攻击者就越难下手。
举个例子。你写了个登录页面，用户输入账号密码。如果没做任何防护，攻击者可以直接用SQL注入把数据库拖走。我在项目中遇到过一家创业公司，上线第一天就被拖库了——原因就是登录接口没做参数校验。嗯，这种坑我踩过，所以特别想提醒你。
我的经验：Web安全不是“加个验证码就完事”。它涉及前端、后端、网络、数据库、运维等多个层面。你想想看，一个XSS漏洞可能出在前端，但影响的是所有用户。
1.2 常见攻击类型
攻击类型很多，但咱们先掌握最常见的几种。我按出现频率排了个序，你看看是不是跟你想的一样。
| 攻击类型 | 一句话描述 | 我见过的真实案例 |
|---|---|---|
| SQL注入 | 攻击者通过输入框注入恶意SQL语句 | 某电商后台搜索框未过滤，导致全库用户信息泄露 |
| XSS（跨站脚本） | 攻击者在页面中注入恶意脚本 | 论坛评论区未转义，攻击者盗取了管理员Cookie |
| CSRF（跨站请求伪造） | 诱导用户点击链接，执行非本意操作 | 某银行转账接口无Token校验，用户点了钓鱼链接后钱被转走 |
| 文件上传漏洞 | 上传恶意文件（如WebShell）到服务器 | 某CMS后台未限制上传类型，攻击者上传了PHP一句话木马 |
| SSRF（服务端请求伪造） | 利用服务器发起内网请求 | 某图片处理接口未限制URL，攻击者扫描了内网端口 |
为什么会这样？说白了，很多开发者只关注功能实现，忽略了输入输出校验。我曾经帮一个客户做渗透测试，发现他们所有接口都没做权限校验——任何用户都能调用管理员接口。你说这多吓人？
避坑指南：我曾经接手过一个项目，开发说“我们用了框架，应该安全了吧？”结果一测，框架自带的CSRF保护被他们关掉了，因为“影响开发效率”。记住：框架不是万能药，配置不当等于裸奔。
1.3 安全威胁模型
做安全不能靠猜，得有模型指导。我个人习惯用STRIDE模型来梳理威胁。它把威胁分成六类，你对照着检查，基本不会漏。
- S - Spoofing（伪装）：攻击者冒充他人身份。比如伪造Cookie、盗用Token。
- T - Tampering（篡改）：数据被非法修改。比如中间人攻击篡改请求参数。
- R - Repudiation（抵赖）：用户否认做过某操作。比如没有日志记录，用户说“我没下单”。
- I - Information Disclosure（信息泄露）：敏感数据被暴露。比如错误信息里带出了数据库密码。
- D - Denial of Service（拒绝服务）：服务不可用。比如DDoS打垮你的服务器。
- E - Elevation of Privilege（权限提升）：普通用户获得管理员权限。比如越权访问后台。
你想想看，你的系统里有没有这些风险点？我建议每个模块都过一遍STRIDE。比如登录模块：有没有伪装风险？有没有信息泄露风险？嗯，这么一梳理，漏洞就藏不住了。
我的习惯：做威胁建模时，我会画一张数据流图，标出每个节点可能对应的STRIDE威胁。然后按风险等级排序，优先修复高危项。这比漫无目的地扫漏洞高效得多。
1.4 安全开发周期（SDL）
安全不是上线前才做的事。我见过太多团队，开发时不管安全，上线前找安全团队扫一遍，然后疯狂修漏洞——这叫“亡羊补牢”。真正靠谱的做法是把安全嵌入到开发流程里，也就是安全开发周期（SDL）。
SDL的核心思想是：安全左移。越早发现漏洞，修复成本越低。我给大家画个流程图（用文字描述）：
需求阶段 → 设计阶段 → 开发阶段 → 测试阶段 → 上线阶段 → 运维阶段
↓ ↓ ↓ ↓ ↓ ↓
安全需求 威胁建模 代码审计 安全测试 配置检查 持续监控
每个阶段做什么？我简单说说：
- 需求阶段：明确安全需求。比如“用户密码必须加密存储”、“接口需要限流”。
- 设计阶段：做威胁建模。用STRIDE分析潜在风险，提前设计防御方案。
- 开发阶段：写代码时注意安全规范。比如使用参数化查询防SQL注入，输出时做HTML转义防XSS。
- 测试阶段：做安全测试。包括自动化扫描和人工渗透测试。
- 上线阶段：检查配置。比如关闭调试模式、修改默认密码、配置HTTPS。
- 运维阶段：持续监控。比如日志审计、入侵检测、定期漏洞扫描。
我个人的建议：别想着一步到位。SDL是个持续改进的过程。你可以先从“代码审计”和“安全测试”做起，慢慢扩展到其他阶段。我见过一个团队，刚开始只做上线前的安全扫描，半年后逐步引入了威胁建模和代码审计，效果非常好。
最后说一句：Web安全不是一个人的事。它需要产品、开发、测试、运维一起参与。你想想看，如果开发写代码时不考虑安全，测试也不测安全，光靠安全团队一个人，能防住吗？肯定不能。
避坑指南：我曾经参与过一个项目，SDL流程很完善，但执行时流于形式——威胁建模文档写得很漂亮，但没人真正对照着改代码。结果上线后还是被挖出了漏洞。记住：SDL的关键是执行，不是文档。
好了，这一章的内容就到这里。下一章咱们会深入讲SQL注入的原理与防御，我会带大家手写一个注入案例，再一步步修复它。到时候见！