如果网站的 Cookie 特别多特别大，会发生什么（二）

协议

仔细回顾一遍 Cookie 属性，除了 secure，再没和 URL Scheme 相关的属性了。

HTTPS是在HTTP上建立SSL加密层，并对传输数据进行加密，是HTTP协议的安全版。现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。

HTTPS主要作用是：

（1）对数据进行加密，并建立一个信息安全通道，来保证传输过程中的数据安全;

（2）对网站服务器进行真实身份认证。

我们经常会在Web的登录页面和购物结算界面等使用HTTPS通信。使用HTTPS通信时，不再用http://，而是改用https://。另外，当浏览器访问HTTPS通信有效的Web网站时，浏览器的地址栏内会出现一个带锁的标记。对HTTPS的显示方式会因浏览器的不同而有所改变。

这意味着，HTTP 和 HTTPS 的 Cookie 默认都是共享的。因此，我们可以在 HTTP 下屏蔽 HTTPS 站点了！

不过 XSS 也不是也想有就能有的，但在特殊的条件下，任何站点都可以有 XSS —— 那就是流量被劫持的时候。

当用户流量被劫持时，中间人可以模拟出任何 HTTP 站点，因此就能对任意站点设置 Cookie：

当用户打开任意 HTTP 页面时，往其中注入脚本。接着悄悄创建目标站点的隐藏框架页，中间人返回特定的页面内容，其中的脚本即可修改目标站点 Cookie 了。

下面就来尝试一下吧。

通过代理，我们模拟流量被劫持的场景。当打开任意页面时，开始对目标站点释放 DeBuff：

主页面的实现：

目标框架页实现：

通过一堆框架页，即可批量对目标站点的 Cookie 进行修改。

最后，切换回正常网络 —— 发现邪恶光环仍在生效：

更杯具的是，连加密传输的 HTTPS 站点也未能幸免：

中间人缓存攻击，又多了一种新玩法！

# 用途

或许你要说了，这除了恶作剧恶搞之外，有实际意义吗。

不过，只要充分发挥想象，还是能玩出一些有趣的效果。例如配合 XSS：

• 屏蔽资料修改页面，阻止用户改密码

• 屏蔽注销接口，保持用户会话不过期

• 屏蔽管理后台，让管理员暂时无法操作（XSS 盲打时，对管理员造成眩晕效果，持续时间视管理员 IQ 而定）

或者流量劫持的场合：

• 屏蔽前端检测脚本，降低用户安全性

• 屏蔽程序、补丁的更新站点，等等

# 小结

当然，这种所谓的『拒绝服务』，只是本地自欺欺人而已，对真实服务器并没什么影响。

虽然效果不及传统攻击，但这种方式显得更文明一些。只对部分人、甚至部分功能实施攻击，而完全不妨碍其他用户。