第 6 章：应用安全 —— 代码里的"暗门"¶
场景： 你开了一家商店，门锁很坚固（系统安全），围墙也很高（网络安全）。但你的店员（Web 应用）可能被骗子忽悠——把商品白送给"顾客"、泄露客户信息、甚至把店门钥匙交给陌生人。应用安全就是防止应用程序被"忽悠"。
6.1 Web 安全概述¶
核心比喻：Web 应用就是商店的店员
防火墙是围墙，操作系统是门锁，Web 应用是直接和顾客打交道的店员。如果店员被骗子忽悠了，围墙和门锁都形同虚设。
OWASP Top 10 列出了 Web 应用最危险的 10 类安全风险——这就是"骗子常用的 10 种忽悠手法"。
OWASP Top 10（2021）¶
| 排名 | 风险 | 说明 |
|---|---|---|
| 1 | 访问控制失效 | 用户能访问不该访问的资源 |
| 2 | 加密失效 | 敏感数据未加密或使用弱加密 |
| 3 | 注入攻击 | SQL 注入、命令注入等 |
| 4 | 不安全的设计 | 架构设计阶段缺少安全考量 |
| 5 | 安全配置错误 | 默认配置、错误配置、不完整配置 |
| 6 | 使用有漏洞的组件 | 依赖的第三方库存在已知漏洞 |
| 7 | 认证失效 | 认证机制存在缺陷 |
| 8 | 软件和数据完整性失效 | 未验证更新来源、CI/CD 管道不安全 |
| 9 | 日志和监控失效 | 攻击发生后无法检测和响应 |
| 10 | SSRF | 服务端请求伪造 |
6.2 SQL 注入¶
核心比喻：SQL 注入就是骗子在表格里写"特殊指令"
你去银行填表取钱。表上写着"请输入取款金额：____"。你写"100 元"，柜员给你 100 元。
但骗子写："100 元；顺便把所有账户的余额都告诉我"——如果柜员不检查，就会执行骗子的"附加指令"。
SQL 注入就是攻击者在输入框中注入恶意的 SQL 代码，欺骗数据库执行非预期的操作。
SQL 注入示例¶
-- 正常的登录验证 SQL
SELECT * FROM users WHERE username = '$username' AND password = '$password';
-- 攻击者输入 username: admin' --
-- 实际执行的 SQL 变成：
SELECT * FROM users WHERE username = 'admin' --' AND password = '';
-- '--' 是 SQL 注释，后面的密码验证被注释掉了！
-- 攻击者不需要密码就能以 admin 身份登录
SQL 注入防御¶
| 防御方法 | 说明 | 有效性 |
|---|---|---|
| 参数化查询（预编译） | 将 SQL 结构与数据分离 | ✅ 最有效 |
| 输入验证 | 白名单验证输入格式 | ✅ 有效 |
| 转义特殊字符 | 对 '、"、-- 等字符转义 |
⚠️ 辅助手段 |
| 最小权限 | 数据库账户只授予必要权限 | ✅ 降低损失 |
| WAF | Web 应用防火墙检测拦截 | ⚠️ 辅助手段 |
6.3 XSS —— 跨站脚本攻击¶
核心比喻：XSS 就是骗子在留言板上贴"假通知"
小区公告栏上，物业贴了通知："明天停水"。骗子在旁边贴了另一张："请将物业费转到账号 6222xxxx"——看起来也像物业的通知。
XSS 攻击者在网页中注入恶意脚本，当其他用户访问时，脚本在用户浏览器中执行——窃取 Cookie、重定向到钓鱼网站、篡改页面内容。
XSS 三种类型¶
| 类型 | 攻击方式 | 持久性 |
|---|---|---|
| 反射型 XSS | 恶意脚本通过 URL 参数注入，服务器"反射"回页面 | 非持久（需要诱导点击） |
| 存储型 XSS | 恶意脚本存储在服务器（如评论、昵称），每次访问都触发 | 持久（危害最大） |
| DOM 型 XSS | 纯客户端攻击，恶意脚本通过 DOM 操作注入 | 非持久 |
XSS 防御¶
| 防御方法 | 说明 |
|---|---|
| 输出编码 | 将 < 编码为 <，> 编码为 > |
| CSP（内容安全策略） | 通过 HTTP 头限制可执行的脚本来源 |
| HttpOnly Cookie | 设置 Cookie 的 HttpOnly 标志，防止 JS 读取 |
| 输入验证 | 对用户输入进行白名单验证 |
6.4 CSRF —— 跨站请求伪造¶
核心比喻：CSRF 就是骗子冒充你给银行发指令
你登录了网上银行（Cookie 有效）。这时你收到一封邮件："点击查看可爱猫咪图片"。你点击了——但图片链接实际上是 bank.com/transfer?to=骗子&amount=10000。
因为你已经登录，浏览器自动带上你的 Cookie，银行以为是你本人发起的转账请求！
CSRF 防御¶
| 防御方法 | 说明 |
|---|---|
| CSRF Token | 在表单中加入随机 Token，服务器验证 |
| SameSite Cookie | 设置 Cookie 的 SameSite 属性（Strict/Lax） |
| Referer/Origin 验证 | 检查请求来源是否为可信域名 |
| 二次验证 | 敏感操作要求输入密码或验证码 |
6.5 文件上传漏洞¶
| 风险 | 说明 |
|---|---|
| 上传 WebShell | 攻击者上传可执行脚本（.php/.jsp），获取服务器控制权 |
| 覆盖关键文件 | 上传文件名与系统文件相同，覆盖关键配置 |
| 资源耗尽 | 上传超大文件耗尽磁盘空间 |
防御措施¶
- 文件类型白名单（只允许特定扩展名）
- 检查文件内容（MIME 类型 + 文件头魔数）
- 限制文件大小
- 上传目录禁止脚本执行
- 文件重命名（使用 UUID 等随机名称）
6.6 常见考试题型¶
例题 1： 以下攻击中，属于注入攻击的是（ ）。
A. XSS B. CSRF C. SQL 注入 D. DDoS
查看答案
答案：C
SQL 注入是典型的注入攻击，攻击者将恶意 SQL 代码注入到输入参数中。XSS 是跨站脚本攻击，CSRF 是跨站请求伪造，DDoS 是拒绝服务攻击。
例题 2： 防御 XSS 攻击最有效的方法是（ ）。
A. 使用防火墙 B. 对输出进行 HTML 编码 C. 使用 HTTPS D. 修改默认端口
查看答案
答案：B
对输出进行 HTML 实体编码（如将 < 转为 <）是防御 XSS 最有效的方法。防火墙和 HTTPS 不能防御 XSS，修改端口与 XSS 无关。
例题 3： CSRF 攻击利用的是（ ）。
A. 服务器漏洞 B. 浏览器自动携带 Cookie 的机制 C. 数据库漏洞 D. 加密算法缺陷
查看答案
答案：B
CSRF 攻击利用浏览器在发送请求时自动携带目标站点 Cookie 的机制。攻击者诱导用户在已登录状态下访问恶意链接，浏览器自动带上认证 Cookie，使恶意请求被服务器误认为是用户本人的合法请求。
要点总结¶
- OWASP Top 10 是 Web 应用最危险的 10 类安全风险
- SQL 注入：注入恶意 SQL 代码，防御用参数化查询
- XSS：注入恶意脚本，防御用输出编码 + CSP + HttpOnly
- CSRF：伪造用户请求，防御用 CSRF Token + SameSite Cookie
- 文件上传漏洞：防御用类型白名单 + 内容检查 + 目录隔离
课后练习¶
-
攻击辨析 ：从攻击目标、攻击方式、防御措施三个维度对比 SQL 注入、XSS 和 CSRF。
-
代码审计 ：以下代码存在什么安全问题？如何修复？
-
真题演练 ：设置 Cookie 的（ ）属性可以防止 JavaScript 读取 Cookie，从而减轻 XSS 攻击的危害。
下一章预告： 技术层面的安全措施都部署好了。但安全不只是技术问题——风险评估、安全策略、应急响应同样重要。第 7 章见。