我是否需要使用 Google 帐户身份验证而不是 Spring 身份验证来避免 Firesheep cookie 嗅探攻击？答案

【问题标题】：Do I need to use Google Account Authentication instead of Spring authentication to avoid a Firesheep cookie-sniffing attack?我是否需要使用 Google 帐户身份验证而不是 Spring 身份验证来避免 Firesheep cookie 嗅探攻击？
【发布时间】：2011-04-30 04:07:41
【问题描述】：

我正在阅读有关 Firesheep 的信息，想知道如何保护我的 Spring MVC 3.0 站点免受此类攻击：

网站非常普遍通过加密保护您的密码最初的登录，但令人惊讶的是网站加密不常见其他一切。这留下了 cookie（和用户）易受攻击。 HTTP 会话劫持（有时称为 “sidejacking”）是当攻击者获取用户的 cookie，允许他们为用户做任何事情可以在特定网站上进行。在一个开放的无线网络，cookies 基本上是隔空喊叫，让这些攻击变得非常容易。

Spring MVC 中是否有特定的配置设置可以帮助防止此类攻击？

根据文章：

唯一有效的解决方法问题是完整的端到端加密，在网络上称为 HTTPS 或 SSL。

我有一个在 Google App Engine 上运行的 Spring 站点。这是否意味着如果我想避免这种攻击，我需要使用 Google Account Authentication 而不是 Spring 提供的内置身份验证？

【问题讨论】：

答案是 HTTPS（您如何通过网络传输数据），而不是哪些代码（Spring 或 Google 的）在服务器端读取数据

标签： java security google-app-engine spring-mvc spring-security

【解决方案1】：

firesheep 的全部意义在于身份验证机制不是唯一的问题。大多数系统使用 HTTPS 保护身份验证步骤，但不保护与用户的后续交互。无论您使用哪种身份验证机制，您都应确保所有涉及登录用户的交互都通过 HTTPS 进行。这在 App Engine 中是可能的，但前提是您在应用的 appspot 域 (myapp.appspot.com) 上提供服务。

【讨论】：

例如，Facebook（易受攻击的网站之一）通过 HTTPS 提供其登录页面，但在用户登录后，Facebook 切换到未加密的 HTTP。 Firesheep 无法从使用 HTTPS 的连接中嗅探 cookie；通过未加密的连接发送 cookie 使攻击成为可能。不幸的是，许多其他网站受到影响。为了保护您的用户，您根本不应该使用未加密的 HTTP。
@idealmachine 我认为：您不应该在您的用户可能向其发送登录 cookie 的任何域/路径上使用未加密的 HTTP。对于不需要登录的内容/页面，使用 HTTP 就可以了——这也是许多网站都有单独的域来提供静态内容的一个很好的理由。

【解决方案2】：

您需要设置与网络服务器的 HTTPS 握手，不确定如何在 Google App Engine 上完成，but it's apparently possible.Here is some more information.

【讨论】：