减轻应用层的“firesheep”攻击？答案

【问题标题】：Mitigating the 'firesheep' attack in the application layer?减轻应用层的“firesheep”攻击？
【发布时间】：2011-04-30 08:23:11
【问题描述】：

人们推荐哪些方法来缓解网站应用程序的“Firesheep”方法？

我们已经考虑到这一点，并且从可用性的角度来看，除了加密网站的所有流量之外，减轻攻击对于 Web 开发人员来说可能是个问题。

我们提出的一个建议是使用基于路径的 cookie，并对发生帐户操作或个性化交互的特定路径的流量进行加密。然而，这使可用性变得复杂，因为站点的其余部分（未加密 - 未验证）位不知道用户是谁。

对于减轻这种攻击向量，同时保持可用的可用性水平，是否有人有任何其他建议？

【问题讨论】：

【解决方案1】：

Firesheep 不是什么新鲜事。会话劫持已经持续了二十多年。您不需要“加密”您的 cookie，这由您的传输层处理。 Cookie 必须始终为 cryptographic nonce。

通常黑客只是通过在地址栏javascript:document.cookie='SOME_COOKIE' 中输入来设置自己的 cookie，FireSheep 是为害怕 1 行 JavaScript 的脚本小子准备的。但这并没有使这种攻击更容易执行。

如果您在会话的整个生命周期内不使用 HTTPS，那么 Cookie 可能会被劫持，而这是 OWASP A9 - Insufficient Transport Layer Protection 的一部分。但是您也可以使用 XSS 劫持会话。

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

2) 使用“secure cookies”（可怕的名字，但它是一个强制浏览器仅使用 HTTPS 的标志。）

3) 使用Sitewatch(free) 或wapiti (open source) 扫描您的Web 应用程序以查找xss

也不要忘记 CSRF！（哪个firesheep没有解决）

【讨论】：

【解决方案2】：

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

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

我的猜测是网络存储是按端口（除了主机）分段的，所以这是不可能的。只是把这个想法扔出去，以防有人想使用它。

【讨论】：

【解决方案3】：

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

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

【讨论】：

【解决方案4】：

我在 GitHub 上发现了一篇有趣的文章，其中描述了一种减轻 firesheep 攻击的方法。

【讨论】：