是否存在防止 cookie 被盗的方法？答案

【问题标题】：Exists a way to prevent cookies from getting stolen?是否存在防止 cookie 被盗的方法？
【发布时间】：2010-09-23 09:03:52
【问题描述】：

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

谢谢，伯纳德

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

【问题讨论】：

标签： security authentication cookies

【解决方案1】：

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

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

让用户自行选择是否保持登录状态，并就其信息存在风险向他们发出警告。

【讨论】：

嗨 Kieveli，这对用户来说听起来不太方便。有很多IP地址经常变化的环境，用户不想一遍又一遍地登录，这就是他/她选择“记住我”的原因。
Cookie 只能由特定域访问。想一想：如果有人可以窃取 cookie，则意味着小偷可以访问计算机，如果可以，他可以打开浏览器并访问该站点。但是，是的，可以执行一些攻击。我建议您按照上面的方式进行操作。
洛基——这是不正确的。 Cookie 以明文形式通过互联网发送；嗅探它们相当简单，尤其是在您使用无线网络时。

【解决方案2】：

在饼干罐上盖上盖子。

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

【讨论】：

【解决方案3】：

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

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

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

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

希望这会有所帮助。

【讨论】：

如何将此用例应用于 F5 LB？假设 SSL 在 BigIP 终止。到后端服务器的流量是纯文本的，通过 HTTP。假设 F5 LB 设置了 Cookie Persistence。我认为您必须使用 Cookie Hash/iRules 来模拟一次性使用令牌，我相信您在此处所描述的正是这一点。如果攻击者破坏了 HTTPS（即 MITM），那么此时您可能无能为力，除了规避对 HTTPS 连接的攻击。
IP 欺骗有什么帮助？这不会使响应转到错误的 IP 地址，因此恶意请求不会返回给该请求的发起者吗？

【解决方案4】：

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

【讨论】：

【解决方案5】：

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

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

Page.Request.UserHostName

【讨论】：

【解决方案6】：

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

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

窃取受害者的 cookie
欺骗正确的 IP 地址
欺骗正确的用户代理

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

【讨论】：

这似乎不太安全。有人可以通过将代码注入用户浏览器或拦截纯文本 HTTP 以编程方式获取所有这些参数。
如果用户使用手机浏览网站，我认为这种方法不起作用。 4G网络，不断改变IP..

【解决方案7】：

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

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

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

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

【讨论】：

您无法在真人发出另一个请求之前阻止对 cookie 的使用，但您可以检测到对 cookie 的第二次使用并发出警报，知道某些事情不正确并且两者之一请求可能是一种黑客攻击。