系统管理员对于减轻他们管理的服务器的“firesheep”攻击有何想法？
Firesheep 是一款新的 Firefox 扩展，允许任何安装它的人访问它可以发现的 Sidejack 会话。它通过嗅探网络上的数据包并查找来自已知站点的会话 cookie 来进行发现。编写插件让扩展监听来自其他站点的 cookie 相对容易。
从系统/网络角度，我们讨论了加密整个站点的可能性，但这会给服务器带来额外的负载，并影响站点索引、资产和总体性能。
我们研究的一个选项是使用我们的防火墙来执行 SSL 卸载，但正如我之前提到的，这需要对整个站点进行加密。
对于防范这种攻击媒介的一般想法是什么？
我曾经在 StackOverflow 上问过类似的问题，不过，看看系统工程师的想法还是很有趣的。
答案1
只要会话数据在服务器和客户端之间以明文形式传递，您就很容易在不安全的网络上遭受某种劫持。HTTP 的无状态特性几乎保证了任何拥有您的会话数据的人都可以在服务器上冒充您。
那么该怎么办呢？您需要安全地将会话信息从服务器传递到客户端，而不能让窃听者截取它。最可靠、最简单的方法是让您的网站全部使用 HTTPS，即没有未加密的流量。这很容易实现，因为您不必更改应用程序，只需更改服务器即可。缺点是它会增加服务器的负载。
如果那不是一个选项，那么您需要以某种方式混淆服务器传递给客户端的会话数据。而客户端需要一些脚本来“去混淆”会话数据，以便在下一个请求时将其传回服务器。是的，这就是“通过模糊性实现安全”，每个人都知道它不起作用。除非它起作用。只要您的网站不是高价值目标，模糊会话数据就会阻止这个“firesheep”东西的临时用户劫持您的用户。只有当/如果您的网站被愿意对您的混淆进行逆向工程的人发现时，这种缓解技术才会失败。
答案2
为什么你必须加密整个网站？
只需设置一个子域名 login.yourcompany.com，加密该位，在 cookie 上设置安全标志（阻止它通过安全通道以外的任何方式传递），然后设置具有内部信任的登录服务器（无论如何，你想这样做取决于你）到应用程序的其余部分。
答案3
请参阅 Ben Adida 的“SessionLock Lite”提案/代码。诚然，它无法提供针对主动攻击或窃听的保护，并且容易受到短期攻击。但在您设计真正的 SSL 解决方案时，它可能会在短期内有所帮助：http://benlog.com/articles/2010/10/25/keep-your-hands-off-my-session-cookies/
答案4
从本地管理员的角度来看：
为了让 firesheep 在有线网络上工作，攻击者必须对你的交换机基础设施执行 ARP 投毒。除非攻击者首先利用网络，否则往返于其他计算机的流量永远不会到达攻击者的 PC。
从服务提供商的角度来看：
我希望我的网站或者至少任何身份验证或 cookie 流量都经过 SSL 加密。
从最终用户的角度来看：
我希望提供商能保证我的会话安全，这样我就不用考虑输入“https://”了。它应该能保证我的安全。