8

在 Web 2.0 应用程序中，许多用户通常希望保持登录状态（“记住我”标志），另一方面，他们的 cookie 可以访问非常私密的数据。有没有办法防止直接从计算机或通过嗅探窃取 cookie 的人使用 cookie 访问用户数据？始终 HTTPS 不是一个选项。

谢谢，伯恩德

[编辑] 将 IP 地址连接到 cookie 也不是一个选项。

4

7 回答 7

8

KISS - 只需使用会话，以便您使用已由您选择的服务器端脚本语言自动创建的 ID。这已经够难猜了。然后，如果它被盗，将访问者的 IP 地址和用户代理存储在会话中（确保永远不会输出），并且仅当已存储的IP 地址和用户代理与找到的匹配时才认为会话有效远程客户端。

在这种情况下，攻击者必须做以下三件事：

  1. 窃取受害者的cookies
  2. 欺骗正确的IP地址
  3. 欺骗正确的用户代理

它还有助于确保攻击者不知道他/她为了正确接管受害者的会话而必须做的所有事情。IE：他们可能假设只需要 cookie，然后失败了......并且必须通过非常长时间的反复试验来弄清楚其他所有事情。通过这种方式，您可以通过默默无闻和困难获得安全性，具体取决于攻击者的技能和他/她对系统的现有知识。

于 2009-02-04T22:26:30.407 回答
6

Bernd——通过标准 HTTP 完成的任何事情的问题在于它是纯文本的；任何人都可以伪造任何东西。IP 欺骗比单纯的 cookie 窃取更具挑战性，因此与 IP 绑定往往是人们所做的事情。就像您说的那样，这在高度动态的环境中效果不佳。

我能想到的唯一最安全的方法是使用 HTTPS 放置和验证“永久”cookie，然后放置（在同一个 HTTPS 会话中）一个短期会话 cookie。其余的通信可以通过常规 HTTP 完成，使用会话 cookie 进行身份验证。

这样，在支持加密（仅握手）中使用的资源更少，永久 cookie 不会暴露——它仅在加密下传输——并且窃取会话 cookie 的风险有限，因为该 cookie 将很快过期。

话虽如此——不要让用户在包含真正敏感数据的网站上点击“记住我”！这就是为什么银行不这样做的原因。

希望这可以帮助。

于 2008-11-21T01:50:58.910 回答
3

关于在数据库中存储复杂的 cookie id 和关联的 IP——您实际上不必这样做。如果你有一个密钥 K，用你的 K 加密用户的 ip 就足够了，并将结果 {IP}K 作为 cookie。只要您的密钥是安全的（并且密码没有被破坏——但如果发生这种情况，我们就会遇到更大的问题），这是安全的。

于 2008-11-21T01:56:58.647 回答
2

也许使用会话 ID 和令牌（基于 IP、盐和会话 ID 的哈希），每个请求都重新生成（使用快速哈希算法）会是一个好方法吗？我将会话数据存储在数据库中（当前），这意味着每个请求都有两个查询开销。它是这样工作的：

  1. 选择 SID 和 TOK 匹配的位置。
  2. 验证基于当前客户端生成的令牌与数据库中的令牌是否匹配。
  3. 将数据反序列化为属性。
  4. 脚本等发生。
  5. 序列化更新的数据，重新生成 SID/TOK，并更新数据库，其中 SID/TOK = 旧的 sid 和 tok，更新的数据和新的 sid 和 tok。将 cookie 设置为新的 SID 和 TOK。

通过这种方式，首先 cookie 绑定到我基于令牌的任何内容（在本例中为远程地址），如果它被盗并且客户端数据被欺骗，那么 cookie 无论如何只对一个请求有用 - 到 cookie 是拦截了，没用。

我能看到的唯一可察觉的弱点是，如果攻击者在真人可以发出另一个请求之前设法获取 cookie、欺骗并使用它。有几种方法可以解决这个问题，我需要考虑。开销是两次查询并生成两次令牌哈希（一次用于验证，一次用于替换）。

于 2010-11-15T04:13:51.317 回答
1

将一个不起眼的 ID cookie 存储到本地服务器数据库中。根据 cookie 中提供的 ID 进行服务器端数据库查找。一定要使 ID 足够复杂以至于不容易被猜到。将 ID 映射到用户的 IP 地址。如果他们的 IP 发生变化，则强制他们重新登录，并创建一个新 ID。

在第二次阅读时，听起来您想要双手被绑住的高度安全性。用户必须选择保持登录状态，从而增加他/她的风险。您可以从应用程序和服务器的角度实现世界上所有的安全性，但是如果用户忘记了他们的笔记本电脑在 Tim Horton（加拿大星巴克）的桌子上，那么这对您没有任何好处。

让用户选择他们是否保持登录状态，并警告他们他们的信息有风险。

于 2008-11-21T01:12:35.023 回答
1

在饼干罐上盖上盖子。

撇开玩笑不谈，最好的选择已经说明 - 使 cookie 成为一个不起眼的 ID，并将其与服务器端的 IP 地址查找相关联。由于您编辑说您不能将其绑定到 IP 地址，因此留下了晦涩的 ID 部分。您的选择受到 cookie 的限制——您在客户端上放置东西的那一刻，它就会成为一种风险。

于 2008-11-21T01:43:45.197 回答
0

Bernd - 你说将IP地址连接到cookie不是一个选项，我假设这是b / c用户可以通过DHCP连接，因此每次都可以使用不同的IP。您是否考虑过将 cookie 绑定到 DNS 主机名？您可以使用私钥加密 cookie，并将其存储在用户的盒子中。然后每当他们进来时，检查 cookie，取消加密，然后检查用户当前的 DNS 主机名与 cookie 中的主机名。如果匹配，则允许他们进入。如果不匹配，则不允许自动登录。

仅供参考 - 在 ASP.Net 中，要获取用户框的 DNS 主机名，只需查看

Page.Request.UserHostName
于 2008-11-21T16:13:09.013 回答