【问题标题】:Why can't the Yesod session cookie be hijacked?为什么 Yesod 会话 cookie 不能被劫持?
【发布时间】:2023-03-16 00:24:01
【问题描述】:

Yesod book

加密防止用户检查数据,并且 签名确保会话既不会被劫持,也不会被劫持 被篡改了。

我不清楚为什么会这样。如果窃听者在从服务器发送的 cookie 中获取并在合法用户发出另一个请求之前使用它,那么会话最终不会被劫持吗?

在我看来,真正防止会话劫持的唯一方法是始终使用 SSL。但是,如果我这样做,那么 Yesod 完成的签名和加密最终会成为不必要的开销(编辑:就防止劫持而言的开销。正如 @sr_ 在 cmets 中指出的那样,否则它仍然有用)。

【问题讨论】:

  • 此处缓解的威胁是用户更改了 cookie(服务器没有注意到),这是一个在客户端被过度信任时发生的一般问题(通过保存饼干里的东西)。来自hackage:“除了检测 cookie 存储或传输中的潜在错误(完整性)外,MAC 还通过向您保证 cookie 数据确实由该服务器生成(真实性)来避免恶意修改 cookie 数据。”
  • @sr_ 同意。我要解决的问题是这本书声称 cookie 不能被劫持。例如,如果我在我的网站上使用身份验证,但没有在我的所有页面上使用 SSL,在我看来,在适当的情况下,攻击者可以冒充我进入该网站。

标签: security yesod


【解决方案1】:

这是一个很好的收获。当我们将客户端的 IP 地址包含在 cookie 中以防止劫持时,这曾经更准确。结合防篡改保护,这使得 MITM 攻击基本上不可能起作用,除非您在同一路由器后面或使用同一代理进行 NAT。

很遗憾,由于担心代理问题,我们不得不禁用该保护。由于中间代理服务器,单个用户的请求可能来自多个 IP 地址。我没有数据可以说明这种情况发生的频率,但我们非常担心此安全功能会导致损坏,因此我们禁用了它。

感谢您提出这个问题,I've corrected the book

【讨论】:

  • 感谢您的更正和出色的软件。
  • 很高兴,像这个问题的反馈让整个系统变得更好!
  • 对于使用 AOL 的人来说,过去的情况是每个用户轮流通过 4 个 IP 地址进行请求。我记得很多年前就因为这个原因禁用了我的 IP 保护功能。
  • 请注意 - 即使对于仅 SSL 的站点,您的 yesod 会话仍然容易受到劫持,除非您 a) 使用 customizeSessionCookies 设置会话 cookie 上的安全位或 b) 设置 Strict-Transport - 您的回复中的安全标头。最好两者兼而有之。如果没有这些措施中的至少一项,我相信攻击者可以冒充您的网站并拦截任何尝试通过 http(而不是 https)访问该网站的用户发送的会话 cookie
猜你喜欢
  • 1970-01-01
  • 2011-09-22
  • 1970-01-01
  • 1970-01-01
  • 2012-08-27
  • 2012-04-17
  • 1970-01-01
  • 2010-12-19
相关资源
最近更新 更多