一、HTTP中间人攻击（MITM）—— 我踩过最深的坑
说起HTTP中间人攻击，我到现在都记得第一次在客户现场抓到攻击包的那个下午。说实话，当时后背都凉了。你想想看，你发的每一条消息、每一个密码，都被人看得一清二楚，这感觉可不好受。
1.1 什么是中间人攻击？
说白了，就是攻击者悄悄站在你和服务器之间。你以为你在跟服务器直接对话，其实每句话都要经过攻击者转述。他不仅能听，还能改。
核心问题：HTTP是明文传输的。没有加密，没有身份验证。谁都能看，谁都能改。
我在一次渗透测试中遇到过这样的案例：某公司内部网络，员工登录OA系统时，攻击者用ARP欺骗把流量引到自己机器上。用户名密码全被截获。嗯，这就是典型的MITM。
1.2 攻击流程拆解
攻击者要完成MITM，通常走这三步：
- 拦截 — 用ARP欺骗、DNS劫持、伪造WiFi热点等方式，让流量经过自己
- 解密 — HTTP是明文，直接读。如果是HTTPS，需要额外手段（后面讲）
- 转发或篡改 — 看完内容，可以原样转发，也可以改掉再发
我的建议：做安全测试时，先用Wireshark抓包看看。如果能看到明文HTTP请求，那基本就是靶子了。
1.3 真实案例：公共WiFi下的陷阱
我记得有个朋友在咖啡厅连了免费WiFi，登录了某论坛。结果第二天账号被盗，发了一堆垃圾广告。为什么？因为那个WiFi是攻击者搭的，所有HTTP流量都被记录了。
你想想看，如果那个论坛用的是HTTPS，攻击者最多知道你访问了哪个网站，但看不到具体内容。这就是加密的价值。
注意：即使网站用了HTTPS，如果用户手动输入http://开头的地址，或者网站没有强制跳转，攻击者仍然有机会做SSL剥离攻击。这个我们后面细说。
二、HTTPS证书验证机制——别被假证书骗了
HTTPS的核心是证书。我见过太多人以为「挂了锁就是安全的」，其实不然。证书验证机制如果没搞明白，HTTPS就是个摆设。
2.1 证书链验证
浏览器怎么知道一个证书是真的？它不看证书本身，而是看谁签了它。就像身份证，派出所签发的才有效。
证书验证的流程是这样的：
- 服务器把证书发给浏览器
- 浏览器看证书是谁签的（CA机构）
- 浏览器检查这个CA是否在受信任列表里
- 如果CA可信，再验证证书有没有被篡改
- 最后检查域名是否匹配、是否过期
关键点：根证书是自签名的。浏览器内置了约100个受信任的根证书。只要你的证书链能追溯到这些根证书之一，浏览器就认。
2.2 自签名证书的问题
我在开发环境经常用自签名证书。但有一次，测试同事直接点了「继续访问」，结果把自签名证书导入了信任列表。后来生产环境也用了同一套流程，差点出事。
自签名证书的问题在于：它没有经过CA验证。浏览器不认识它，就会弹出警告。很多用户会忽略警告直接点「继续」，这就给了攻击者可乘之机。
避坑指南：我曾经见过一个内部系统，用了自签名证书，管理员让所有用户都把警告忽略掉。结果有人做了个钓鱼页面，也用了自签名证书，用户习惯性点了「继续」……嗯，后果可想而知。
2.3 证书验证的常见漏洞
| 漏洞类型 | 说明 | 我的经历 |
|---|---|---|
| 证书过期 | 证书过期后仍被使用 | 遇到过某银行网银证书过期3天，用户无法登录 |
| 域名不匹配 | 证书的CN或SAN与访问域名不一致 | 某CDN配置错误，导致证书域名不匹配 |
| 弱签名算法 | 使用SHA-1等已被破解的算法 | 2017年还有公司在用SHA-1证书，我直接建议换掉 |
| 证书吊销 | 证书已被吊销但浏览器未检查 | OCSP检查经常被忽略，这是个隐患 |
三、SSL剥离攻击——HTTPS的致命弱点
SSL剥离攻击，说白了就是让HTTPS降级成HTTP。攻击者不破解加密，而是让你根本不用加密。
3.1 攻击原理
用户访问网站时，如果输入的是http://example.com，服务器可能会重定向到https://example.com。但问题在于：第一次请求是明文的。
攻击者就在这一步动手脚：
- 用户输入http://example.com
- 攻击者拦截这个请求，不转发给服务器
- 攻击者自己跟服务器建立HTTPS连接
- 攻击者跟用户保持HTTP连接
- 用户看到的是HTTP页面，但以为自己在用HTTPS
注意：这种攻击对普通用户几乎不可见。浏览器地址栏没有锁，但用户可能根本没注意。我见过太多人根本不看地址栏的协议标识。
3.2 为什么SSL剥离能成功？
原因很简单：用户第一次访问时，浏览器不知道这个网站应该用HTTPS。除非……
嗯，这里就要说到HSTS了。
四、HSTS与安全头配置——给浏览器装上「记忆」
HSTS（HTTP Strict Transport Security）解决的就是SSL剥离的问题。它告诉浏览器：这个网站只能用HTTPS访问，以后也别用HTTP。
4.1 HSTS工作原理
服务器在HTTPS响应头里加一行：
Strict-Transport-Security: max-age=31536000; includeSubDomains浏览器收到这个头后，会记住：
- 这个域名在接下来31536000秒（1年）内只能用HTTPS
- 所有子域名也必须用HTTPS
- 如果用户输入http://，浏览器自动转成https://
核心价值：HSTS把「要不要用HTTPS」的决定权从用户手里拿走了。用户不需要思考，浏览器自动处理。
4.2 其他关键安全头
除了HSTS，还有几个安全头我建议一定要配：
| 安全头 | 作用 | 配置示例 |
|---|---|---|
| X-Content-Type-Options | 防止浏览器嗅探MIME类型 | nosniff |
| X-Frame-Options | 防止点击劫持 | DENY 或 SAMEORIGIN |
| Content-Security-Policy | 防止XSS和数据注入 | default-src 'self' |
| Referrer-Policy | 控制Referer信息的发送 | no-referrer-when-downgrade |
我的经验：配置安全头时，别一次性全上。先加一个，测试没问题再加下一个。我曾经一次性加了CSP，结果把公司自己的CDN给封了，页面样式全丢了……
4.3 HSTS的坑
HSTS有个问题：第一次访问时，浏览器还没有HSTS记录。这次访问仍然是HTTP的，仍然可能被攻击。
解决办法是HSTS Preload。把域名提交到浏览器厂商的预加载列表里，浏览器出厂时就内置了HSTS规则。这样即使第一次访问，也是HTTPS。
注意：提交到HSTS Preload列表后，你的域名就永远不能降级回HTTP了。我见过有人提交后才发现自己的CDN不支持HTTPS，结果网站直接挂了。嗯，这个坑我踩过。
五、知识体系总览
下面这张图是我自己整理的HTTP/HTTPS安全知识体系。每次做安全评估时，我都会对照这张图检查一遍。
这张图把整个知识体系串起来了。从上到下看：协议层决定了通信方式，攻击面利用了协议的弱点，防御措施则堵住这些漏洞。我每次做安全培训都会用这张图，学员反馈说思路清晰很多。
总结一下：HTTP/HTTPS安全的核心就三件事——加密（HTTPS）、验证（证书）、强制策略（HSTS）。少一个都不行。我在实际项目中见过太多「只做了加密没做验证」或者「做了验证没做强制策略」的情况，结果还是被攻破了。
嗯，这一章的内容就到这里。记住我说的：安全不是单个点的防护，而是一整套体系的构建。下一章我们会深入分析具体的攻击工具和防御方案，到时候再聊。