Encryption 使用时间戳防止会话劫持？

我一直在寻找防止会话劫持的方法，即有人窃取会话cookie并使用它访问系统

诸如使在开放无线网络上嗅探会话变得容易的程序，以及获取会话的其他方式，包括跨站点脚本攻击，或者只是从受害者的计算机上物理地将其解除

使用SSL保护所有会话cookie/服务器通信对于防止Firesheep嗅探非常关键，在cookie上设置HTTPOnly有助于防止JavaScript在XSS攻击中读取会话cookie，但它仍然容易受到基于AJAX的攻击

另一层是在会话cookie中包含一个安全令牌或nonce，该cookie在每次请求时更新。您将令牌存储在服务器端数据存储和cookie中，并在每次请求时比较cookie中的令牌是否与数据存储中的令牌匹配

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

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

缓解此问题的一种方法是，服务器保留最后几个令牌的历史记录，并检查它们是否匹配，但随后会出现保留多少令牌的情况，这取决于连接的脆弱程度或用户的点击满意度，服务器可能会在连接恢复和浏览器更新用户会话之前循环浏览历史记录

保留令牌历史记录的另一种方法是为每个会话添加时间戳，并检查时间戳是否在某个短的指定范围内，例如30秒。如果用户的会话cookie时间戳在服务器存储的会话时间戳的30秒内，则该会话被认为是可信的

示例伪代码

def authenticate_request():

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

这避免了必须保留令牌历史记录（时间戳成为令牌），但攻击者有30秒的机会在会话被盗后劫持会话。虽然这是真的，但令牌历史记录替代方案并没有更好，因为它为攻击者提供了一个潜在的更长的机会窗口

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

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

---

使用时间戳令牌是正确的方法还是有更好的方法？30秒的缓冲时间对吗？我遗漏了什么边缘案例

我看不出时间戳是如何工作的。它要求用户在向服务器发送另一个请求之前，在一个页面上花费的时间不得超过30秒。我敢肯定，我花了30多秒的时间阅读这一页，并在按下“Post”之前输入了这个回复

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

你发送的任何代币都有相同的故事。黑客可以拦截令牌并复制它

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

---

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

这不要求他们每30秒重新加载一次页面——他们可以离开任意长度的时间。重要的是，他们会话中的时间戳与下一个请求时存储在服务器上的时间戳相匹配。是的，任何未复制的数据都可以被拦截和复制，但除非他们从用户发出的最后一个请求中拦截会话，令牌/时间戳将在用户的下一个请求时更新，因此拦截的令牌将无效。唯一有效的时间是他们是否能够在用户最后一次请求的30秒内拦截并使用它。我想我不明白你的时间戳代表什么时间，你也在比较它。我只是重读了你原来的帖子，你说“每次会议的时间戳”。但是什么时候？它是什么时候创建的？上次向用户发送页面的时间？在任何情况下，您都会说这个时间戳会被发送回服务器。但是，任何嗅探该行的人都可以看到会话id和时间戳。我不知道你得到了什么。无论如何，我认为你需要进一步澄清你在做什么。会话cookie由用户id、会话id和ti组成