php - 散列会话指纹真的有必要吗？

Question

请在投票前仔细阅读此内容...

所以我看到了很多会话管理类，它们通过用户代理和几个 ip 块或其他的连接来创建指纹。他们似乎还添加了盐，然后在将指纹存储在会话变量中之前对其进行哈希处理。

这种指纹生成通常发生在每个请求中，以验证会话的当前用户确实是原始会话用户。这就是为什么我想知道，像这样的东西真的需要盐和哈希吗？

如果黑客可以进入您的文件系统以查看您的会话文件内容，那么您当时不是已经被淹没了吗？

非常感谢任何信息。

Answer 1

其中大部分是有道理的，但散列和加盐是没有意义的。

如果将会话绑定到 IP 地址，则劫持会话变得更加困难。这是我建议做的事情，但你不需要非常严格。您可以只绑定到 IPv4 的前三个部分左右。这是你的选择。越严格的IP检查越安全，但对用户来说越不方便。

至于基于用户代理绑定会话，这也可能有所帮助。必须意识到，如果您在未加密的通道（例如 HTTP）上工作，则用户代理检查的用处不大，因为它也可以被入侵者复制。

当涉及到加盐和散列时，那是没用的。它们不会增加您的身份检查的强度。他们唯一做的就是使您的设计复杂化。对于这件事，我相信他们会降低您的安全级别。

与往常一样，要记住一些规则：

• 使用强会话标识符。这意味着使用良好的随机源并确保有足够的位。
• 至少在某种程度上将会话与 IP 绑定。
• 如果可能，将会话绑定到用户代理。
• 使用 SSL/TLS。没有它，理论上所有的会话系统都是不安全的。
• 保护您的会话存储。无论是基于文件系统还是基于数据库。

Answer 2

我可以想到两种有用的情况：

1. 当会话数据存储在客户端时。（就像在 cookie 中一样。）因此，我将被阻止将我的 cookie 带到另一台计算机上，并且我将被阻止制作我自己的 cookie 内容。（好吧，所以这不太可能发生......）
2. 当会话数据存储在一些共享的服务器端资源（即/tmp）中并且容易受到窥探时。在这种情况下，如果窥探者能够看到会话的内容，他们仍然无法伪造与该会话的连接，因为他们不知道哪些数据进入了指纹。

Answer 3

作为对@Kai Sellgren (+1) 的回复的补充，其中包含有关如何保护会话存储的一些很好的提示，我将添加一些想法，而不是解释某些特定应用程序的哈希和盐。

我不是在谈论使用 cookie 作为会话存储的应用程序，我们仍然可以在 Prestashop 电子商务解决方案中看到这一点，对 cookie 内容进行加密（他们为什么决定将会话存储在 cookie 上？） . 我知道我们谈论的是服务器端会话存储。

关键是分层安全和深度防御：

妥协从来都不是布尔值，你不是“完全妥协”或“完全安全”。我喜欢的真实历史之一是mySpace 蠕虫的解释，它显示了真正的攻击以及必须如何打破防御步骤。总有一面新墙。举个例子，当我在办公室时，我与老板共享相同的 IP，并且可能使用相同的浏览器，这可能会破坏仅基于 IP+user-agent 的安全性。

因此，在会话标记的哈希和盐中，我们显然是在几堵墙倒塌之后采取行动。凯向我们展示了其中一些墙。当他谈到保护会话存储时，我会添加两件事：

• 更改每个 PHP 应用程序的session.save_path和是一个非常好的主意open_basedir（并为每个应用程序获取一个单独的虚拟主机）。很少做。
• 如果您的应用程序安装在路径上（如 /myapp），请在会话 cookie 上添加一个 prefix_path（并为同一服务器上的任何其他应用程序修复它）

现在让我们想象一个现实的妥协。您有几种方法可以破坏服务器端的会话：

• 该应用程序在一个网站上运行，而其他一些应用程序在其他路径（或同一服务器的其他域）中运行。至少这些应用程序中的一个是非常不安全的。在最坏的情况下，服务器端代码可能会被注入此应用程序，但某些安全墙（如 open_basedir 或其他 chrooting 技术）可能会阻止此注入代码影响您的单独应用程序（或数据）。
• 一些 javascript 库带有一些包含高度不安全脚本的测试子目录，不仅有很好的会话披露，而且可能有一些会话固定或预测可用。
• 该应用程序是共享的，谈到类似 wordpress 的软件，您可以想象一些平台共享许多不同的安装、不同的模块，也许还有一些自定义代码。在这样的平台上，您会找到允许为每个消费者更改盐的设置，这是有原因的。其中一个网站可能会影响其他网站的安全，如果应用程序想要对网站进行一体化管理，则可能更难做到彻底分离。

如果会话存储可以与其他应用程序中的某些脚本共享，或者您自己的应用程序中您甚至没有注意到的脚本共享会话存储，那么您的目标应用程序可能会受到环境的影响（例如 javascript 库中的这些 f*** 示例，你为什么不在静态文件目录上暂停php执行！）

从妥协的第一步开始，攻击者可能会（并且严重性增加）：

• 阅读会话标记，也许找到他应该伪造哪些信息以获得相同的标记
• 构建一个包含对其配置有效的会话标记的新会话，然后在您的应用程序上使用这个新的会话标识符。您的应用程序将找到会话文件，并接受他。
• 更改您的一个有效会话以以相同方式修改图章

一个简单的邮票哈希会让他的生活更难，但这只是一堵墙，很难打破，盐让这堵墙更难打破。

重要的一点是，根据您的问题，如果一个人可以更改会话存储中的某些内容，我是否已经心情不好？. 好吧，也许不完全。如果这是应用程序的 chroot/分离/安全化允许他做的唯一事情，那么这个盐对他来说将是一场噩梦。

第二个重点是：我应该对每个 Web 应用程序都进行这种级别的深度安全吗？. 答案是否定的。过度工程是一件坏事，并且会降低应用程序的安全性，因为它变得更难理解和维护。在以下情况下，您不需要复杂化您的应用程序：

• 你有一个相当好的会话存储分离水平
• 你一个人在你的服务器上，只有一个应用程序，而不是任何类型的多站点处理
• 您的应用程序安全级别太弱了，以至于可以在应用程序上进行简单的代码注入，因此攻击者不需要会话固定:-)

Answer 4

我可以想象指纹信息的散列点是存储空间，因为生成的散列具有固定长度。

但也使用盐对我来说没有多大意义。因为，正如您已经说过的，由于该数据存储在会话数据存储位置，如果有人能够获取该数据，那么您将遇到比会话固定/劫持更大的问题。

Answer 5

你可以在这里找到一个合理的解决方案：http: //shiflett.org/articles/the-truth-about-sessions

指纹识别与会话劫持作斗争。攻击者不仅需要你的session_id，他还需要任何敏感的 HTTP 标头。它为攻击者增加了另一个障碍，尽管很容易克服。

哈希是为了使数据统一。盐是用来掩盖散列过程的——因此攻击者无法为他自己的 HTTP 标头组合生成有效指纹。

如果黑客在您的文件系统中，您会遇到更大的问题：D

Answer 6

许多对安全性不太了解的人结合了互联网上流传的一些建议，希望他们最终得到的结果“足够好”。将会话 ID 绑定到 UA 会破坏浏览器升级（Chrome 经常这样做）并且绑定到 IP 地址会破坏移动性（任何拥有使用 Wi-Fi 的笔记本电脑的人），而且许多 ISP 没有连续分配。任何可以嗅探 cookie 的人也可以嗅探 UA，并且可能会访问相同的 IP 地址，因为他们从 NAT 后面的不安全 Wi-Fi 中获取了 cookie。

您可能想要做的是在登录尝试时更改会话 ID，这是防止“会话固定”攻击的可靠方法（攻击者使受害者加载http://example.com/?SESSIONID=foo例如通过<img>, 等待你登录，现在知道受害者的会话 ID）。几乎没有理由跨登录保留会话，并且您可以复制需要保留的少数东西（例如购物车）。

Answer 7

如果黑客可以进入您的文件系统以查看您的会话文件内容，那么您不是已经被冲洗了吗？

如果您使用 PHP 作为 CGI（例如 nginx），那么我认为不会。如果您设置权限正确，那么您的会话文件必须具有 PHP 用户的读/写权限，而您的 PHP 文件应该只有读权限。因此，如果您将盐从 Web 服务器传递给 PHP，那么 PHP 用户将无法访问它（他无法创建任何新的/更改可以由您的 Web 服务器运行的现有 PHP 文件，并且他不能访问网络服务器，因为它在另一个用户上运行），所以他不能真正破解（更改）cookie（只能删除它们），因为他不能得到盐。当然，您还必须从 Web 服务器传递数据库设置。

我从来没有真正尝试过，所以如果我错了，请纠正我。

Answer 8

像这样的[http客户端指纹]真的需要盐和哈希吗？

哈希可能有助于减少会话数据中指纹消耗的字节数。因此，只要散列指纹的大小小于指纹本身，这在空间减少方面是有意义的。价格是生成哈希所消耗的系统资源。

这真的有意义吗？您需要对此进行基准测试才能这样说。

那么盐有什么用呢？我必须承认，我认为没有理由加盐。只有让从哈希中猜测指纹变得更难才有意义。但是由于我没有看到散列指纹的任何安全优势（它仅保存在服务器端并且已经相当安全），因此加盐并没有添加任何东西。

如果会话存储本身不被认为是安全的（如果这是为了参数），则应该对整个会话进行加密，而不仅仅是指纹。

因此，特别是对于指纹，我看不出在散列和加盐方面有多大用处。