HTTPS 是开放网络中对抗会话劫持的唯一防御措施吗？

Posted 2023-03-08

【中文标题】HTTPS 是开放网络中对抗会话劫持的唯一防御措施吗？

【英文标题】：Is HTTPS the only defense against Session Hijacking in an open network?

【发布时间】：2011-04-30 08:41:02

【问题描述】：

因此，有了Firesheep，公共 Wi-Fi 中的每个人现在都拥有一键式会话劫持工具。

据我了解，它的工作方式是简单地捕获所有流量并获取会话 cookie（因此它不会窃取密码）。

据我了解，这也意味着 HTTPS 安全登录并不能单独解决这个问题，因为进一步的 HTTP 流量将再次以明文形式包含会话 Cookie。

由于 NAT，将会话绑定到特定 IP 地址是无用的，并且将其绑定到用户代理很容易被欺骗。

那么 100% HTTPS 是否始终是防止此类会话劫持的唯一方法？人们不能简单地嗅探包括握手在内的整个 HTTPS 流量，或者这些东西安全吗？ （我正在考虑重放攻击，但对此领域一无所知。）

当然，不使用公共/开放式 Wi-Fi 网络是更好的选择，但我仍然对网站开发人员可以做些什么来保护他/她的用户感兴趣。

【参考方案1】：

Firesheep 不是什么新鲜事。只要 Web 应用程序一直在使用会话 ID，会话劫持就已经存在。通常黑客只是通过在地址栏中输入以下内容来设置自己的 cookie：javascript:document.cookie='SOME_COOKIE'。该工具适用于害怕 1 行 JavaScript 的脚本小子。

如果您在会话的整个生命周期内不使用 HTTPS，Cookie 可能会被劫持，这是OWASP A9 - Insufficient Transport Layer Protection 的一部分。但您也可以使用 XSS 劫持会话。

1) 使用httponly cookies。

2) 使用“secure cookies”（可怕的名字，但它是一个强制浏览器使 cookie 仅 HTTPS 的标志。）

3) 扫描您的 Web 应用程序以查找 XSS。

也不要忘记CSRF！ （Firesheep 没有提到。）

【讨论】：

"这个工具是为害怕 1 行 JavaScript 的脚本小子准备的。"哈哈，只要我能再次投票就 +1

不，此工具适用于需要证明任何人都可以入侵其宝贵网站的愚蠢高管。

HTTP 会话劫持也可用于查询参数中的会话 ID。

@Michael Stum 缓存了 ssl 握手。 HTTPS 非常便宜，并且是为您的用户提供安全会话的唯一方法。 （故事结束。）

@telent：在 3...2...1...几个，写了一个简单而可怕的概念验证，高管们的反应是“不，谁会想黑我们？我们需要更多的牛铃来代替。”然后有一天，一个普通用户偶然输入了150;而不是@ 987654327@ 进入一个表格并删除了他们当天的所有记录（说真的！）。之后允许进行一些安全修复。幸运的是，我不再在那里工作）

【参考方案2】：

Rook 已经回答了一些问题，我将只回答您问题的其他部分。

100% HTTPS 是否始终是防止此类会话劫持的唯一方法？

没错。 100% HTTPS 是唯一的方法。 100% 是关键。

人们不能简单地嗅探整个 HTTPS 流量，包括握手，或者这些东西安全吗？ （我正在考虑重放攻击，但对该领域一无所知）

HTTPS 具有针对重放攻击的内置保护。如果正确实施，HTTPS 是真正安全的。

即使正确实现了 HTTPS，也有办法绕过它。 SSL Strip 就是这样一种工具。该工具没有利用 SSL，它只是利用了人们总是在 url 中输入 mybank.com 而不是 https://mybank.com 的事实。

【讨论】：

+1 用于 ssl 条。尽管我认为很明显必须 100% 使用 https。哦，好吧。

一直使用 HTTPS 无疑是最好的方法，但不是唯一的可能。您可以让会话 cookie 不安全以维护会话，并使用第二个（仅限 HTTPS）cookie 来处理身份验证。这是将维护会话和身份验证这两个问题分开的好方法，即使一直使用 HTTPS 也是如此。

【参考方案3】：

我相信 SSL 既便宜又是一个完整的解决方案。但是直到你没有它或在这里寻找一些额外的层是如何保护你的 SESSION 数据。

一如既往地在部门防守是要走的路。 1st 使用 Sessions 存储用户登录数据 第二，如果管理员登录也检查数据库，可能会慢一点，但由于管理员数量很少，其余的是用户，这是一个可行的安全性加分。 第三次保护你的会话

会话保护： 将会话开始放入一个目标文件中，您可以在其中调用 self 构造的“is_session_valid()”函数。此函数将检查 $_SERVER 超全局的（IP / TIME / Browser），并将它们存储在会话中。 Up on Next load 查看值是否相同，如果不浪费更多资源注销用户并显示索引页面。

这不是一个完整的解决方案，因为它可能是同一网络上的同一浏览器，例如有很多用户和会话被劫持的 Wifi 也可能是最近的（及时）。 但是在不使用 SSL 之前，这要好得多。无论如何，受害者和劫持者使用相同的所有东西的情况很少发生......所以即使没有任何 SSL，这也有效地降低了成功攻击的机会！

Kevin Skoglund 的原创想法如果对保护您的 APP 不感兴趣，请参阅他的安全 php 教程。 https://www.lynda.com/PHP-tutorials/Creating-Secure-PHP-Websites/133321-2.html

附：需要使用其他几种防御措施（至少是 CSRF）才能拥有稍微安全的 AP

再见:-)