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

Question

使用Firesheep，公共Wi-Fi的所有人现在都拥有了一键会话劫持工具。

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

据我了解，这也意味着仅靠HTTPS安全登录并不能解决这个问题，因为后续的HTTP流量中仍将包含明文的会话cookie。

将会话与特定IP地址绑定由于NAT而无用，将其与用户代理绑定易于欺骗。

因此，是否始终使用100％的HTTPS是防止此类会话劫持的唯一方法？人们是否可以嗅探整个HTTPS流量，包括握手过程，还是这些内容是安全的？（我想到了重放攻击，但在这方面没有任何知识。）

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

- Michael Stum

Answer 1

Firesheep并不是什么新鲜事物。自从网络应用程序使用会话ID以来，会话劫持已经存在了很长时间。通常黑客只需在地址栏输入以下内容即可设置自己的cookie：javascript:document.cookie='SOME_COOKIE'。这个工具是为脚本小子设计的，他们害怕一行JavaScript。

如果您在整个会话期间没有使用HTTPS，则可能会劫持Cookie，这是OWASP A9-传输层保护不足的一部分。但是您也可以通过XSS劫持会话。

1）使用httponly cookies。

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

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

还要不要忘记CSRF！（Firesheep没有解决此问题。）

- rook

---

这个工具是给那些害怕一行JavaScript的脚本小子用的。哈哈，我一能投票就点赞。 - Kenny Cason

不，这个工具是为那些需要展示“任何人”都可以入侵他们宝贵网站的愚蠢高管而设计的。 - Konrad Rudolph

HTTP会话劫持也可以针对查询参数中的会话ID进行攻击。 - Darron

@Michael Stum, SSL握手会被缓存。HTTPS非常便宜，也是为用户提供安全会话的唯一方法。（就是这样，没有其他解释了。） - rook

@telent：3...2...1...开始一波否认的浪潮吧（真实故事：很久以前，我被委托“检查安全问题”；我发现了几个问题，写了一个简单而可怕的概念验证，高管们的反应是“哪有人想黑我们呢？我们需要更多的铃鼓声。”然后有一天，一个普通用户无意中在表单中输入了150;而不是150，结果把当天的所有记录都删除了（真的！）。之后才允许进行一些安全修复。幸运的是，我已经不在那里工作了） - Piskvor left the building

Answer 2

Rook已经回答了部分问题，我将回答你问题的其他部分。

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

没错。100% HTTPS是唯一的方法。而且百分之百很关键。

人们不能简单地嗅探整个HTTPS流量，包括握手吗？这些东西安全吗？（我在考虑重放攻击，但对那方面没有了解）

HTTPS内置了防止重放攻击的保护机制。如果正确实现，HTTPS是真正安全的。

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

- Sripathi Krishnan

---

+1 对于 SSL 剥离攻击。虽然我认为显而易见的是必须始终使用 HTTPS。哦，好吧。 - rook

始终使用HTTPS无疑是最好的方式，但并非唯一可行的方式。您可以将会话cookie保持不安全以维护会话，并拥有第二个（仅限HTTPS）cookie来处理身份验证。这是一种很好的方法，可以分离维护会话和身份验证这两个问题，即使始终使用HTTPS也是如此。 - martinstoeckli

Answer 3

我认为SSL是一种便宜且完整的解决方案。但在你没有它或寻找额外层保护时，以下是如何保护您的SESSION数据。

像往常一样，深度防御是正确的方法。 1. 使用Sessions存储用户登录数据 2. 如果管理员已登录，请检查数据库，这可能会减慢速度，但由于管理员数量很少，其余用户可以接受此可行的安全性加强。 3. 保护您的SESSION <=！

会话保护： 将会话开始放入对象文件中，在自我构建时调用“is_session_valid()”函数。此函数将检查$_SERVER超级全局变量的（IP / TIME / Browser）并将它们存储在会话中。下次加载时，如果值不同，则仅浪费更多资源注销用户并显示索引页面。

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

原始想法来自Kevin Skoglund，如果您有兴趣保护您的应用程序，请查看他的安全PHP教程。 https://www.lynda.com/PHP-tutorials/Creating-Secure-PHP-Websites/133321-2.html

P.S.需要使用其他几种防御措施（至少包括CSRF），才能使AP相对安全

再见 :-)

- user3649978