配置Secure属性的Cookie在HTTPS下为何仍易受MIM攻击

核心认知误区先理清 #

你默认的「HTTPS连接下MIM攻击者无法解密内容，所以动不了Cookie」这个判断，漏了两个关键前提，同时也高估了Secure属性的防御边界。

为什么不解密流量也能破坏Cookie完整性 #

很多人把「加密」和「不可篡改」划了等号，这是完全错误的：

• 早期TLS版本大量使用CBC模式的块加密套件，这类套件只做通信内容加密，没有绑定强完整性校验。攻击者不需要解密流量，只要能捕获传输中的密文块，就可以通过比特翻转攻击修改密文的特定比特位，让服务端解密后得到的对应Cookie字段值变成攻击者预期的内容，全程不需要破解加密算法。
• 就算是用了带完整性校验的新TLS套件，攻击者依然可以通过注入伪造TCP包、提前断开合法连接、重放旧的合法请求片段等方式，干扰服务端收到的Cookie内容，破坏完整性。

为什么带Secure属性的Cookie依然防不住MIM攻击 #

首先要明确：Secure属性的设计目标从一开始就不是防HTTPS链路上的篡改，它的唯一作用是限制浏览器只能在HTTPS请求中携带该Cookie，禁止通过HTTP明文连接发送，本质是防「攻击者把HTTPS连接降级到HTTP后直接窃取明文Cookie」的场景。它本身不提供任何内容校验、链路防篡改能力：

• 如果攻击者已经通过植入恶意根证书、利用TLS校验漏洞等方式绕过了证书验证，相当于在用户和服务器之间建立了两层合法TLS连接（用户<->攻击者、攻击者<->服务器），这时候所有流量对攻击者都是明文，别说改Cookie，整个请求响应内容都可以随意篡改，Secure属性的限制完全不生效。
• 如果攻击者通过比特翻转等方式在密文层面篡改Cookie内容，Secure属性根本感知不到——毕竟Cookie确实是通过HTTPS链路传输的，完全符合它的校验规则。

补充：HttpOnly、SameSite等Cookie属性同样防不住这类MIM攻击，要从链路层防中间人篡改，必须靠强制开启HSTS、禁用老旧不安全的TLS套件、严格校验服务器证书这几个手段组合实现。

内容的提问来源于stack exchange，提问作者variable