在应用层减轻“firesheep”攻击的影响？

Question

人们推荐哪些方法来缓解“Firesheep”网站应用程序的攻击？除了加密所有流向网站的流量，从可用性角度考虑，减轻这种攻击可能对Web开发人员而言是一个问题。

我们想到的一个建议是使用基于路径的cookie，并为账户操作或个性化交互发生的特定路径加密流量。然而，这会使可用性变得更加复杂，因为其余部分的网站（未加密 - 未经身份验证）不知道用户是谁。

是否有其他建议可以缓解这种攻击方式，同时保持可用性水平？

- pobk

---

顺便说一句，如果其中一位管理员想要添加一个“firesheep”标签，因为它非常相关。 - pobk

一个Firesheep的交叉引用。 - Jonathan Leffler

可能是在开放网络中，HTTPS是防止会话劫持的唯一防御措施吗？的重复问题。 - rook

Answer 1

Firesheep并不新鲜。会话劫持已经存在了20多年。您不需要“加密”cookie，这由您的传输层处理。Cookie必须始终是加密随机数。通常黑客只需在地址栏中输入以下内容即可设置自己的cookie：javascript:document.cookie='SOME_COOKIE'，FireSheep是面向脚本小子的，他们害怕1行JavaScript。但这并不意味着此攻击更容易执行。

如果您未在整个会话期间使用HTTPS，则可以劫持Cookie，这是OWASP A9-传输层保护不足的一部分。但是您也可以通过XSS劫持会话。

1）使用httponly cookie。(使JavaScript无法访问document.cookie，但您仍然可以使用xss进行会话骑乘)

2) 使用 "安全的cookies"（虽然名称很糟糕，但它是一个标志，强制浏览器将cookie设置为仅限HTTPS。）

3) 使用Sitewatch（免费）或wapiti（开源）扫描您的Web应用程序以查找xss。

还要注意CSRF！（Firesheep无法解决此问题）

- rook

---

@pobk 在使用Firesheep之前，您应该启用这些安全功能。这个工具并不会改变任何东西。 - rook

我们的应用程序尽可能安全（符合PCI DSS标准）...我们只是在考虑更进一步保护我们的用户。 - pobk

@pobk PCI-DSS确实需要定期扫描，但您的Web应用程序是否启用了我提到的2个Cookie标志？ - rook

由于会话用于个性化，因此未启用安全Cookie。我们不希望从HTTPS运行整个站点...这对可用性来说将是一场噩梦。可用性和站点个性化变得无限困难。 - pobk

使用这种应用程序设计，您将始终容易受到firesheep攻击，并且总是违反OWASP。 HTTPS是保护自己的唯一方法。 SSL是一种非常轻量级的协议，握手被缓存，密文不会增加额外的带宽。 - rook

Answer 2

我在GitHub上发现了一篇有趣的文章，介绍了一种缓解firesheep攻击的方法。

https://github.com/blog/737-sidejack-prevention

- pobk

Answer 3

有人尝试过利用HTML 5中的“Web Storage”来存储共享密钥（在身份验证期间通过SSL加密响应传递），然后由JavaScript使用该密钥随时间更改会话cookie吗？

这样，被盗的（未加密的）会话cookie只能在短时间内有效。

我猜Web Storage是按端口分段的（除了主机），所以这可能不可能。只是提出这个想法，以防有人想要尝试。

- arscan

---

攻击者只需要将一些 JavaScript 注入到 HTTP 响应中，以揭示共享密钥。 - caf

Answer 4

当用户登录时，在会话中存储IP地址。

在每个后续请求中，检查IP地址是否与存储在会话中的IP地址匹配。

- EA.

---

我恐怕那样做不行。在出现firesheep的情况下，远程IP地址将被共享。 - pobk

即使你也将X-Forwarded-For HTTP头的值与IP地址一起存储，仍然如此吗？ - EA.