加密、签名、证书等密码学原语是构建安全系统的基石，但仅拥有基石并不等于建筑安全——如何将密码学原语正确地组合为防御体系，如何识别和应对现实中的攻击模式，才是安全工程的核心命题。
安全领域有一个基本认知：安全不是状态，而是过程。 不存在绝对安全的系统，只存在攻击成本高于攻击收益的平衡点。架构师的任务不是追求零漏洞，而是建立纵深防御体系，使攻击者面对的是多层防线而非单点突破。
本章将从攻击者视角出发，系统梳理 Web 与网络层的主流攻击手段，并给出对应的防御架构。
安全攻击可以从多个维度分类。从攻击目标来看：
从攻击发生的网络层次来看：
| 层次 | 典型攻击 | 防御手段 |
|---|---|---|
| 网络层 | IP 欺骗、SYN Flood、Smurf | 入口过滤、SYN Cookie、流量清洗 |
| 传输层 | 会话劫持、TCP RST 攻击 | TLS、序列号随机化 |
| 应用层 | XSS、SQL 注入、CSRF、SSRF | 输入校验、CSP、CSRF Token |
| 业务层 | 越权访问、逻辑漏洞 | 权限模型、审计日志 |
攻击原理：攻击者发送大量伪造源 IP 的 SYN 报文，服务器为每个 SYN 分配资源进入 SYN_RCVD 状态。由于源 IP 伪造，ACK 永远不会到来，服务器资源被耗尽，无法服务合法请求。
防御方案：
攻击原理：攻击者伪造 IP 报文的源地址，冒充可信主机发起请求。在基于 IP 地址做访问控制的系统中，这可能导致未授权访问。
防御方案：
攻击原理：利用大量受控主机（僵尸网络）同时向目标发送海量请求，耗尽带宽、连接数或计算资源。
DDoS 的类型：
| 类型 | 目标 | 手段 |
|---|---|---|
| 带宽耗尽型 | 网络带宽 | UDP Flood、ICMP Flood、DNS 放大攻击 |
| 协议耗尽型 | 协议栈资源 | SYN Flood、Ping of Death |
| 应用层耗尽型 | 应用计算资源 | HTTP Flood（低速请求）、Slowloris |
防御架构：
攻击原理：攻击者将恶意脚本注入网页，当其他用户浏览该网页时，脚本在用户浏览器中执行，可窃取 Cookie、劫持会话、篡改页面内容。
XSS 的三种类型：
存储型 XSS 危害最大——恶意脚本持久化存储，所有访问该页面的用户都会受害。
防御方案：
Content-Security-Policy 限制页面可加载的资源来源，禁止内联脚本执行。例如：Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com。Set-Cookie: ...; HttpOnly，禁止 JavaScript 通过 document.cookie 访问会话 Cookie，降低 XSS 窃取会话的风险。攻击原理：攻击者将恶意 SQL 片段注入用户输入，改变后端 SQL 语句的语义，实现未授权的数据读取、修改或删除。
示例：
-- 原始 SQL
SELECT * FROM users WHERE username = '$username' AND password = '$password'
-- 攻击者输入: username = "admin'--", password = "anything"
-- 生成的 SQL
SELECT * FROM users WHERE username = 'admin'--' AND password = 'anything'
-- 注释掉密码验证，直接以 admin 身份登录防御方案：
攻击原理：攻击者诱导已登录用户访问恶意页面，该页面自动向目标网站发送请求（利用浏览器自动携带 Cookie 的特性），以用户身份执行非预期操作。
防御方案：
Set-Cookie: ...; SameSite=Strict 或 SameSite=Lax，限制 Cookie 仅在同站请求中发送。Strict 模式最安全但影响用户体验（从外部链接进入不携带 Cookie），Lax 是推荐默认值。攻击原理：攻击者利用服务端发起请求的功能，使服务端向内网资源发起请求，绕过防火墙访问内部服务。
典型场景：应用提供 URL 预览功能（如 "输入 URL 获取网页摘要"），攻击者输入 http://169.254.169.254/latest/meta-data/（云环境元数据接口）或 http://127.0.0.1:6379/（内网 Redis）。
防御方案：
攻击原理：攻击者在通信双方之间插入自己，可以窃听、篡改双方通信内容。
防御方案：
Strict-Transport-Security 响应头告知浏览器仅使用 HTTPS 连接本站，防止 SSL 剥离攻击。单一的防御手段不足以应对复杂的攻击场景。纵深防御（Defense in Depth）要求在多个层面部署安全控制，形成多层防线：
每个实体（用户、进程、服务）仅被授予完成其任务所需的最小权限集合。
Trade-off：权限粒度越细，管理复杂度越高。过度细分导致权限配置爆炸，反而增加配置错误的风险。架构师需在安全性与可管理性之间寻找平衡——关键资源（如数据库、管理后台）使用细粒度权限，普通资源使用角色级别的粗粒度权限。
纵深防御通过多层弱防线替代单层强防线，降低了单点失效的风险。
Trade-off：多层防线意味着更高的运维复杂度和性能开销（如 TLS 加解密、WAF 规则匹配）。每一层都需要正确配置和维护，任何一层的配置错误都可能成为突破口。
许多安全措施会降低用户体验：CAPTCHA 防机器人但烦人，强制密码复杂度但难以记忆，MFA 增加登录步骤但降低便捷性。
Trade-off：安全措施的强度应与资产价值匹配。银行转账需要 MFA + 短信验证，而浏览公开内容无需登录。过度安全与安全不足同样有害——前者导致用户绕过安全措施，后者导致数据泄露。
输入验证是"不允许坏数据进入"，输出编码是"确保坏数据不会被解释执行"。二者互补而非替代。
Trade-off：仅做输入验证无法防御所有场景——数据可能通过其他渠道（数据库迁移、API 集成）进入系统。仅做输出编码虽更安全，但会增加所有输出点的处理负担。最佳实践是两者结合：输入验证做白名单过滤，输出编码根据上下文转义。
系统默认配置应是安全的，而非要求用户主动配置安全选项。
Trade-off：默认安全可能限制功能或降低性能。例如，CSP 默认禁止内联脚本，但许多遗留应用依赖内联脚本，需要逐步迁移。架构师应确保新系统默认安全，为遗留系统提供渐进式加固路径。
OWASP（Open Web Application Security Project）定期发布 Top 10 安全风险清单，是安全审计的事实标准。2021 版 Top 10：
实践建议：将 OWASP Top 10 纳入代码审查清单和安全测试基线，而非仅作为知识参考。
"只要攻击者不知道我的接口地址和参数格式，就是安全的。"——这是危险的错觉。隐蔽不是安全，因为信息总可能泄露（反编译、日志、内部人员）。
正确做法：假设攻击者了解系统的全部实现细节（Kerckhoffs 原则），安全性仅依赖于密钥和凭据的保密性。
防御不仅是阻止攻击，还包括检测和响应。完整的安全日志应记录：
反模式：日志中记录密码、Token、信用卡号等敏感信息。日志本身也需要脱敏保护。
SolarWinds 事件表明，攻击者可以绕过应用层防御，通过污染上游组件实现入侵。
防御措施：
延伸阅读：