有两种方法可以在会话 cookie 上设置“安全”标志：
在应用程序本身中，例如：
<session-config> <cookie-config> <http-only>true</http-only> <secure>true</secure> </cookie-config> </session-config>在 httpd 等 TLS 代理的配置中。
我找不到任何文章来说明哪一个是最佳实践。
最安全的可能是 2，而最合乎逻辑的是 1，因为它仅适用于 HTTPS。
会话 cookie 安全标志：最佳实践
信息安全
饼干
会话管理
2021-08-19 22:52:52
2个回答
我建议最好同时使用它们，因为它不会造成任何伤害。此外，它确保了纵深防御的理念。
如今，人们在云上进行部署，并且更经常进行迁移。所以，我想我们不能确定你提到的 httpd 配置 2 是否一直都在。
您应该考虑<secure>true</secure> 在应用程序中启用是强制性的。下面给出解释。
解释：
场景 1（假设 TLS 代理/httpd 错过了安全标志设置）
我测试了一个场景，我只 <secure>true</secure>在应用程序本身中启用并且没有通过 TLS 代理（httpd）配置安全标志。
现在响应头有一个带有安全标志的 cookie，我观察到 Firefox 和 Chrome 处理并保存带有安全标志的 cookie。
Set-Cookie: acct=tafats; domain=localhost; Secure;expires=Thu, 16-Mar-2017 15:19:48 GMT; path=/; HttpOnly
从安全的角度来看，这是浏览器所期望的。
这可以保护您免受通过数据包嗅探的会话劫持尝试。
在这种情况下，如果攻击者让用户点击http://example.com，则不会发送 cookie，因为它具有安全标志。
这边，<secure>true</secure>来救了。
场景 2（假设应用程序中缺少安全标志设置但在 TLS 代理/httpd 中配置）
只要您通过 TLS 代理设置了这个安全标志，它就足够了。但这里要注意的是，您需要确保为您一直执行的所有部署配置了此 TLS 代理设置。
总而言之，我建议最好将它们一起使用并确保纵深防御的理念。
在应用程序中。
cookie 本身由应用程序设置，cookie 标志是其中的一部分。Cookie 可以有几个标志：“secure”、“httponly”、“samesite”。只有应用程序知道哪些 cookie 应该有哪些标志。如果您的代理插入了 httponly 标志并且应用程序想要使用 Javascript 访问 cookie，这将不再有效。Cookie 是应用程序的责任。
此外，无论您使用什么代理，您都希望应用程序的行为始终如一。开发人员在测试应用程序时可能没有使用任何代理，但他们仍应使用安全 cookie，以便环境与生产环境紧密匹配。
其它你可能感兴趣的问题