将cookie会话从HTTPS传输到HTTP时的安全问题

Question

在我的网站上，我有几个 HTTPS 页面和一些 HTTP 页面。当用户通过 HTTPS 登录时，会存储包含电子邮件地址等的Cookie。当用户点击我网站的 HTTP 页面时，Cookie会因创建Cookie而丢失在 HTTPS下。因此，要解决该问题，我在HTTP页面中添加了 PHP 代码：

session_start();

$currentSessionID = session_id();

我认为这会获取为 HTTPS 页面存储的Cookie并将其拉出来，因此 HTTP 可以看到它吗？这是一种安全漏洞吗？我不确定cookie是否实际上是通过 HTTP 传输的，还是只是拉动浏览器已经存储在 temp internet files 中的内容？

Answer 1

是，如果您在HTTP连接上设置了识别Cookie，则可能会被劫持，并且他们识别的帐户可能会受到侵害。

通过HTTP发送会话cookie（这实际上是一件非常常见的事情）是允许Firesheep工作的原因。基本攻击是：

1. 用户通过HTTPS登录（这是安全的）。
2. 服务器设置会话cookie，以便识别用户。
3. 用户开始通过HTTP浏览页面，根据定义，该页面涉及将会话cookie发送到未加密的服务器。
4. 所有这一切都很常见。许多站点（包括Stack Overflow）仅对登录页面使用HTTPS，然后通过HTTP为站点的其余部分提供服务。令人讨厌的部分是，同一网络上的攻击者可以监听HTTP流量，查找会话cookie，然后使用它们来冒充他们识别的用户。这就是Firesheep的作用：你可以去星巴克，连接到wifi，打开Firesheep并劫持其他人的Facebook和Twitter帐户。

好消息是，同一网络窃听攻击在大多数情况下并不是特别实际的攻击。 Firesheep工作的唯一原因是因为全世界的每个人都有Facebook / Twitter /任何帐户，这意味着当你连接到星巴克的开放式wifi时，会有劫持帐户。

你能做什么？

• 将您的Cookie设置为“安全”，以便它们只能通过HTTPS发送。
• 设置整个站点以通过HTTPS提供服务，并将所有经过身份验证的用户重定向到HTTPS资源。

如果你不这样做，你可以依赖这样一个事实：窃听并不是一个特别实际的攻击，如果你的网站真的很受欢迎，那么劫持你网站的支持可能只会在Firesheep中实现; - ）< / p>

更直接地解决您的问题的细节：如果您的HTTP页面可以识别用户，那么该用户的帐户可能被劫持，因为服务器必须继续进行的是用户的cookie < / strong>即可。

Answer 2

你要做的是非常不安全，明显违反了OWASP A9。在任何时候都不能通过HTTP公开经过身份验证或将通过身份验证的会话ID。