"Secure"标记的Cookie是如何工作的？

Question

我知道标记有secure的Cookie不会通过未加密连接发送。我想知道它是如何深入工作的。

谁负责确定是否发送Cookie？

- ted

---

注意：这个“Secure”标志只是深度防御中的一个层面——如果攻击者能够进行中间人攻击，他们仍然可以对“Secure” cookie进行写入操作，这有可能导致会话固定攻击。这个相关的讨论询问了如何进行此类攻击，我提供了详细的答案，解释了如何进行此类攻击以及如何缓解（HSTS可以起作用，但也可以使用特定名称前缀来完全缓解此问题）。 - metatoaster

Answer 1

客户端仅为加密连接设置此项，并在RFC 6265中定义：

安全属性限制cookie的范围为“安全”通道（其中“安全”由用户代理定义）。当cookie具有安全属性时，用户代理仅在通过安全通道传输的HTTP请求中包含cookie（通常是通过传输层安全性（TLS）[RFC2818]的HTTP）。尽管看似有用以保护cookie免受主动网络攻击者的攻击，但安全属性仅保护cookie的机密性。主动网络攻击者可以从不安全的通道覆盖安全cookie，破坏其完整性（有关更多详细信息，请参见第8.6节）。

- Cratylus

---

如果客户端尚未拥有cookie，且需要从服务器端发送cookie（例如登录），那么是否在响应中包含cookie将由服务器端决定。 - ted

服务器最初通过“Set-Cookie头”设置Cookie。 - Ivan

Answer 2

关于这个话题还有一点需要注意:

因为您的网站 example.com 完全使用 https，所以省略 secure 不足以保障安全。

如果您的用户明确地访问了 http://example.com，他们将会被重定向到 https://example.com，但已经太晚了；第一个请求已经包含了 cookie。

- Alain Tiemblo

---

我知道这已经很旧了，但是HSTS预加载可以帮助避免这个问题经常发生。虽然它仍然不能100%解决问题，但如果你确实想避免安全cookie，那么这只是另一件需要考虑的事情。 - Mr. MonoChrome

@Mr.MonoChrome 为什么你想要避免使用安全 cookie？ - MEMark

好的观点。对于.NET应用程序，最好在IIS（或web.config）中进行重定向，而不是通过编程方式（例如globals.asax）。 - piris

@braks 当然可以，但是通过80端口访问您的网站会显示连接被拒绝，而浏览器/用户不希望看到这种情况。 - Alain Tiemblo

@DavidB 是的，就是我之前提到的原因。 - Alain Tiemblo