encryption - 使用时间戳来防止 session 劫持？

Question

我一直在寻找防止 session 劫持的方法，在这种情况下，有人会窃取 session cookie 并使用它来获得对系统的访问权限。

程序如 http://codebutler.com/firesheep使在开放的无线网络上嗅探 session 变得容易，其他获取 session 的方法包括跨站点脚本攻击，或者只是从受害者的计算机上物理地提取它们。

使用 SSL 来保护所有 session cookie/服务器通信对于防止 Firesheep 嗅探至关重要，并且在 cookie 上设置 HTTPOnly 有助于防止 JavaScript 在 XSS 攻击中读取 session cookie，但它仍然容易受到 AJAX-基于攻击。

另一层是在每次请求时更新的 session cookie 中包含安全 token 或随机数。您将 token 存储在服务器端数据存储和 cookie 中，并在每次请求时比较 cookie 中的 token 与数据存储中的 token 。

如果 token 不匹配，则可能表明有人窃取了 session 并试图使用它，因此您可以忽略请求或使 session 无效并要求用户重新进行身份验证。但是，不匹配的 token 也可能是由于连接缓慢/不稳定造成的。

例如，您可能遇到这样一种情况:服务器从真实用户接收请求，更新服务器数据存储中的 session token ，并使用包含更新 token 的 session cookie 响应用户。但是由于连接缓慢/不稳定，用户没有收到响应，因此用户仍然拥有旧 session token ，而新 session token 存储在服务器上。当用户重试请求时， token 将不匹配。

缓解此问题的一种方法是让服务器保留最后几个 token 的历史记录并检查它们是否匹配，但随后就变成了要保留多少 token 的情况，这取决于服务器的不稳定程度连接的好坏或用户点击的愉快程度，服务器可能会在连接恢复之前循环浏览历史记录，并且浏览器会更新用户的 session 。

保留 token 历史记录的另一种方法是为每个 session 添加时间戳，并检查时间戳是否在某个较短的指定范围内，比如 30 秒。如果用户的 session cookie 时间戳在服务器存储的 session 时间戳的 30 秒内，则该 session 被认为是真实的。

示例伪代码

def authenticate_request():

    if (stored_session.timestamp - session.timestamp > 30 seconds):
        return False
    return True

这避免了必须保留 token 历史记录——时间戳成为 token ——但攻击者有 30 秒的机会在 session 被盗后劫持 session 。虽然这是事实，但 token 历史替代方案也好不到哪里去，因为它为攻击者提供了可能更长的机会窗口。

检查 IP 地址和用户代理更改的其他方法也存在问题。用户代理很容易被欺骗，如果攻击者能够获得用户的 session ，他们可以通过相同的 XSS 代码或其他一些方式轻松确定用户代理。

如果用户使用移动设备，他们的 IP 地址可能会经常更改，从而导致许多误报。此外，攻击者可能位于同一公司防火墙之后，因此用户和攻击者的 IP 与外部 Web 服务器相同。

使用时间戳 token 是正确的方法还是有更好的方法？ 30 秒的缓冲时间是否合适？我缺少哪些边缘案例？

Answer 1

我不明白时间戳是如何工作的。它要求用户在向服务器发送另一个请求之前在页面上停留的时间永远不会超过 30 秒。我确定我花了 30 多秒阅读此页面并在按下“发布”之前输入此回复。

在我看来，存在一个固有问题，即您通过线路发送的任何数据都可能被拦截和复制。加密密码并不能解决问题，因为黑客可以拦截加密值，然后发送该加密值。他不一定关心未加密的值是什么。

对于您发送的任何 token ，情况都是一样的。黑客可以拦截 token 并复制它。

我听说过的唯一解决问题的想法是使用公钥和私钥的质询和响应系统:A 创建一个随机字符串，使用 B 的公钥对其进行加密，然后将其发送给 B。 B 使用他的私钥解密该字符串，并将解密后的值与他的应用程序数据一起发回。然后 A 验证解密后的值是否与原始值匹配。如果未通过验证，他将拒绝相关数据。

如果黑客不知道 B 的私钥，他就无法拦截来自 A 的消息并伪造响应。黑客无法使用之前截获的来自 B 的回复，因为随机字符串每次都不同。