避免中间人在后续连接中安全地删除 Cookie

Posted 2023-02-19

【中文标题】避免中间人在后续连接中安全地删除 Cookie

【英文标题】：Avoid man in the middle secured Cookie deletion on subsequent conexiones

【发布时间】：2019-02-25 19:58:38

【问题描述】：

让我们想象一个糟糕的场景，攻击者能够在中间设置一个人，显然是为了非安全连接 (HTTP:80)

第一次连接时：

1- cliente request example.com
2- server respond 301 to httpS::/example.com
3- client request https://example.com
4- server send document and a secured cookie (GOOD-COOKIE)
5- client send next request with GOOD-COOKIE
6- server respond based on GOOD-COOKIE

（几天后客户端再次从同一浏览器连接）

1- client request example.com
X- Attacker intercepts and send document with FAKE-COOKIE (same-name *) and 301 to https
X- client overwrite the GOOD-COOKIE with the FAKE-COOKIE
3- client request https://example.com with FAKE-COOKIE
4- server respond based on FAKE-COOKIE

.* 注意：同名 Cookie，甚至不安全（不同的标志），从攻击者通过 http 传输

虽然安全 Cookie 不会通过 http 传输，但确实可以被来自非 https 连接的同名 cookie 覆盖：sad-very-sad-emoticon

secure 或 httpOnly 标志都不能解决这个问题， 既不是 HSTS 也没有……

有什么策略可以解决这个问题？

（我们在 node.js 中开发，所以没有 apache/iis/etc.. 限制适用）

本案例的 Cookie 示例

GOOD-COOKIE (header response)
Set-Cookie: myCookie=myValueCookie; Secure; Path=/

FAKE-COOKIE (header attacker response) Changed from original that server sends
Set-Cookie: myCookie=myValueCookie; Path=/

【参考方案1】：

您最好的选择可能是 HSTS。不知道为什么你会说它在这里不能保护你？它会跳过不安全协议上的连接并直接转到 HTTPS，而不会暴露任何 cookie。

https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

只要您在max-age 部分中指定，它就像发送一个标头告诉浏览器仅通过 SSL 访问您的网站一样简单。

response.setHeader('Strict-Transport-Security', 'max-age=31536000');

（31536000 秒 = 一年）

它不需要任何特殊的服务器或配置。

此外，您可以将create a ruleset 换成HTTPS Everywhere。这只会节省一些用户，但为什么不呢？

最后，确保您的 SSL 安装稳固。 SSLLabs 太棒了！