Question

最好不要设想一个糟糕的情况，即攻击者能够在中间设置一个人，显然是针对不安全的连接（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

安全或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=/

Answer 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真是太棒了！

避免在随后的conexiones中间删除安全的Cookie的人

1 个答案: