您可以在不使用 SSL 的情况下从 FireSheep 保护 Web 应用程序吗？

信息安全 Web应用程序 攻击预防 会话管理
2021-09-01 18:32:20

假设您想授予某些 Web 用户访问您网站的特权，但您不能（或不愿意）为所有用户提供 SSL - 至少在初始登录页面之后。

在这种情况下，是否有某种方法可以管理用户会话，它会否定 FireSheep，但不会造成痛苦的用户体验？

4个回答

您可以通过一些“通过默默无闻的安全”方案避免当前的 Firesheep，这些方案涉及通过此处讨论的动态会话管理进行身份验证。您可以使用“摘要式身份验证”（RFC 2617），但这仍然容易受到 MITM 攻击，降低用户体验并要求服务器以明文形式存储您的密码（或等效密码）。

但是避免 SSL/TLS 无法解决没有加密的两个基本问题：（1）所有私有内容都是公开共享的，（2）一个坚定的攻击者可以找出你的方案并击败它。

查看一些关于主动攻击的可爱示例、关于性能损失的神话，以及从 EFF 部署 SSL 的具体建议：如何正确部署 HTTPS。还要注意Stack Overflow 元讨论为什么它还没有在 Stack Overflow 上得到修复。

请注意，常见网站的曝光比我最初想象的要糟糕。例如，请注意 Firesheep 作者在一篇很棒的帖子中解释的这种皱纹

您不能简单地避免访问这里受到攻击的站点。当今网络上有大量混合内容，例如 Facebook 的“Like”按钮、Digg 的“Digg It”按钮、twitter 小部件，甚至是托管在 Flickr 或其他照片共享网站上的嵌入式图像。每次您访问包含任何此类内容的任何网页时，您的浏览器也会发送您拥有的任何身份验证 cookie，并请求下拉小部件。

您至少可以修复他在那里讨论的错误（例如当用户注销时实际上使会话 cookie 无效！！）。

您还可以建议您的用户如何在一定程度上保护自己免受这些“sidejacking”攻击，例如使用 VPN 或找到 WPA2 wifi 网络（但请参阅此处的 WPA2 问题）。

感谢@DW 提供了我见过的经过深思熟虑的临时方法的链接：Ben Adida 的 SessionLock Lite。它至少可以防止被动攻击者的持续劫持：Benlog » 让你的手远离我的会话 cookie。只是不要停在那里 - 设计一个 SSL 部署....

毫无疑问，答案是 否定的。您必须有一个完全安全的传输层来传达您的会话 ID。在任何时候都不能通过不安全的连接转换此会话 ID，这将违反OWASP A9 - 传输层保护不足

原则上，您可以防御被动攻击。但在实践中，这并不简单，也不是一个很好的解决方案。

原则上，您可以在 Javascript 中编写自己的加密代码来加密客户端（在 Javascript 中）的所有内容。您遇到的第一件事是它的性能很差，因为 Javascript 中的加密比浏览器的本机加密要慢得多。自然的反应是建议只加密最敏感的数据，例如，只加密用户的密码。然而，这很难做到正确并且有许多微妙的陷阱：

  1. 如果您不加密 cookie，那么您很容易受到会话劫持，并且您一无所获。而且从 Javascript 加密 cookie 或其他 HTTP 标头并不容易。因此，您最终可能会被迫发明自己的用户身份验证方法，并使用 cookie（自制软件）以外的其他东西进行会话管理，这是一项繁重的工作，而且很容易出错。

  2. 如果您只加密密码，那么您可能容易受到 CSRF 攻击。窃听者仍然可以看到所有页面内容，特别是如果链接中包含 CSRF 令牌，则窃听者可以看到所有 CSRF 令牌并发起 CSRF 攻击。可以通过足够的努力来防御这种情况，但它还需要在客户端和服务器上进行更多的工作，并且很难做到正确。

  3. 如果用户可以使用他们的 Facebook 帐户登录您的网站，由于您无法控制 Facebook，因此您无法阻止窃听者窃取他们的 Facebook 帐户然后登录您的网站。

  4. 您仍然容易受到修改页面内容的中间人攻击（主动攻击）的攻击。修改 Firesheep 以使用 ARP 劫持、竞争攻击或其他方法将自己作为中间人插入并修改所有页面内容在技术上并不难。然后失去安全性，因为攻击者可以插入充当键盘记录器或以其他方式窃取身份验证凭据的恶意 Javascript。

  5. 您必须小心不要失去缓存的好处。

现在我并不是说这是不可能的。几乎可以肯定不是。几乎可以肯定的是，可以构建一个网站和一个可以防止大多数被动攻击的解决方案。但这将是复杂而重要的。这意味着您将需要相当多的安全专业知识来构建它，而且您仍然有很大的机会搞砸一些事情。这也意味着结果将是昂贵的。而且安全性本质上是有限的——任何方案都只是部分解决方案/缓解措施——因此价值是有限的。我不认为这是一个很好的权衡。

如果您想阅读有关在不使用 SSL 的情况下防御窃听的最新尝试，这里有一个很好的资源：

我还想与您分享一些使 SSL 性能良好的资源：

SSL 不是免费的——但也要记住，人们有时会认为 SSL 对性能的影响会比实际情况更糟。

我同意 Rook 的回答。但是，我有一个想法，您可以减轻对 firesheep 的使用以及通常所有的会话劫持。

我的建议是将浏览器指纹链接到每个用户。如果指纹发生变化，用户必须重新验证这个指纹到他的帐户。

基本上，我的意思是存储panopticlick.eff.org只需查看浏览器即可创建的类似指纹。

  • 每次指纹更改时，请确保用户已验证此指纹
  • 如果指纹未在此用户帐户上验证，请重新验证用户。

可以在此处找到有关 Web 用户分析的更多信息：

其它你可能感兴趣的问题
上一篇加密和先前加密数据的“安全时间衰减” 下一篇什么类型的内容最好不要通过电子邮件传输？