我试图通过使用 cookie 身份验证的登录页面上的“编辑此 Cookie”扩展名导出我的所有 cookie。注销时，我尝试插入那些 cookie，希望我能登录，但什么也没发生。
经过搜索，我知道发送的 cookie 是加密形式的。但是该页面没有使用任何 TLS 加密。我错过了什么吗？
编辑：我在登录时
尝试使用相同的 cookie，即导出所有 cookie 并在隐身窗口中导入，但没有任何反应。
此外，这种攻击似乎不适用于谷歌、Facebook 等最流行的网站。那么它们如何防范此类攻击呢？
为什么窃取 cookie 不足以进行身份验证？
信息安全
验证
饼干
2021-08-27 14:28:55
4个回答
从技术上讲，即使 cookie 中的内容被加密，如果 cookie 被正确复制到新浏览器并且新浏览器发送相同的 HTTP 标头（相同的用户代理字符串，引荐来源如预期，计算机具有相同的 IP 地址，并且服务器之前可能存储并比较的所有其他标头），理论上服务器将无法区分原始浏览器和新浏览器。
我假设您正在尝试从一个站点复制 cookie，该站点在您每次打开浏览器并且您没有注销时都会自动登录您。
一些网站可以使用其他方法来检测这是否是被盗的 cookie/会话，但这是一场失败的战斗，因为所有这些仍然可以被欺骗 例如：
- 检查IP地址是否改变
- 用户代理是否相同
- 检查推荐人是否有意义
- 浏览器发送的任何其他 HTTP 标头
要回答您的问题，如果您正在处理自动登录站点并且尚未注销，您应该能够使其工作。确保新浏览器发送的所有 HTTP 标头都相同，IP 地址相同，引荐来源网址是预期的，相同的用户代理。
请注意，您正在使用的服务可能正在使用您忘记复制的第二个 cookie，因此会产生异常并将您踢出局。
cookie 的内容是应用程序定义的，并且有多种使用方式。以下是您的努力失败的一些可能原因的简短列表。
- cookie 绑定到您未捕获的 IP 地址、设备指纹或其他非 cookie 数据。
- 原始 cookie 包含过期时间，并且已经过期。
- cookie 是一次性使用的，即服务器在每次请求/响应时轮换该值，并使任何已使用的 cookie 值无效。
- cookie 绑定到服务器上不再存在的会话（可能是因为您已注销）。
- cookie 与页面中的隐藏元素（例如 CSRF 令牌）配对，您没有捕获或重新创建该值。
- 服务器是负载平衡的，会话状态在 proc 中，并且由负载平衡器强制执行临时会话粘性机制。在您的新会话中，您的客户端被分配到场中不存在会话的不同节点。
- Web 服务器使用规则引擎来检测可疑活动，并且您的欺骗性 cookie 出现顺序不正确或出现在意外时间。
- cookie 很好，但是您弄乱了其他一些细节，例如引荐来源标头。
- cookie 本身可能已被签名或加密，而不是传递它们的连接。
- 当您注销时，服务器可能已从其数据库中删除了会话。
如前所述，当您注销时，服务器会使您刚刚窃取的 cookie 无效，这使得试图假装自己变得毫无价值。
因此，如果您想真正测试尝试窃取您的 cookie 以测试从该特定 Web 服务窃取您的会话所需的内容，您将需要导出您的 cookie 并将它们导入新的浏览器/隐身模式，而无需注销您的原始浏览器选项卡。
但是，需要注意的是，cookie 也经常根据一系列其他标准进行检查。我们可以检查 IP、用户代理等。https://wingsdream.wordpress.com/tag/mitigating-http-session-hijacking/
我们还可以设计更聪明的策略，例如不断刷新令牌或浏览器指纹的系统，以仔细检查拥有此 cookie 的人是否是我们提供该 cookie 的人，并且它没有被盗。因此，即使您“窃取”了身份验证 cookie，您仍然可能无法使用它们进行身份验证。