人们建议采用哪些方法来减轻网站应用的“Firesheep”方法？
我们已经考虑过这一点，从可用性的角度来看，除了加密网站的所有流量之外，减轻攻击对于Web开发人员来说可能是一个问题。
我们提出的一个建议是使用基于路径的Cookie，并为发生帐户操作或个性化互动的特定路径加密流量。然而，这会使可用性变得复杂，因为该站点的其余部分（未加密 - 未经过身份验证）位不知道用户是谁。
在保持可用的可用性水平的同时，是否有人有任何其他建议来减轻这种攻击？
答案 0 :(得分：7)
Firesheep 没什么新的。会话劫持已经持续了二十多年。您不需要“加密”您的cookie，由传输层处理。 Cookie必须始终为cryptographic nonce。
通常黑客只需在地址栏javascript:document.cookie='SOME_COOKIE'中输入自己的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成为HTTPS的标志。）
3）使用Sitewatch(free)或wapiti (open source)
扫描您的网络应用程序以获取xss另外不要忘记CSRF！ （哪个firesheep没有解决）
答案 1 :(得分：0)
有人试图利用HTML 5中的“Web存储”来存储共享密钥（在身份验证期间通过SSL加密响应传递），javascript使用它来随时间改变会话cookie吗？
这样，被盗（未加密）的会话cookie只会在很短的时间内有效。
我的猜测是Web Storage按端口（除了主机）进行分段，因此无法实现。只要把那个想法扔出去，万一有人想和它一起运行。
答案 2 :(得分：0)
我在GitHub上发现了一篇有趣的文章，描述了一种减轻火灾袭击的方法。
答案 3 :(得分：-1)
当用户登录时，将IP地址存储在会话中。
在此会话的每个后续请求中，检查IP地址是否与会话中存储的IP地址匹配。