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

Posted 2023-02-24

技术标签:

【中文标题】散列会话指纹真的有必要吗？【英文标题】：Hashing a session fingerprint really necessary? 【发布时间】：2011-09-22 03:48:56 【问题描述】：

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

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

此指纹生成通常发生在每个请求中，以验证会话的当前用户确实是原始会话用户。这就是为什么我想知道，salt 和 hash 在这样的事情上真的有必要吗？

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

非常感谢任何信息。

【问题讨论】：

您要确保我无法预测地重新创建您的会话密钥（因此是私有盐）。如果可以，那么我不需要访问您的服务器，我可以通过随机生成一个密钥来强行进入您的系统，直到我进入。 @Geoffrey Wagner 首先，为什么服务器端的盐对暴力攻击很重要..？对于任何试图冒充该用户以访问其会话的人，我会使用相同的盐服务器端吗？对于暴力破解，他们仍然只需要在这种情况下猜测客户端头部输入即可进行攻击，因为服务器会为他们进行哈希处理。我撤回我的声明，我完全不是服务器的心态，哎呀 【参考方案1】：

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

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

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

当涉及到加盐和散列时，那是没有用的。它们不会增加您的身份检查的强度。他们唯一做的就是使您的设计复杂化。就此而言，我认为它们会降低您的安全级别。

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

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

【讨论】：

来自同一用户的任何其他访问都将使用相同的 U-A，因此如果用户通过 HTTP 进行 any 浏览，则攻击者可以嗅探 U-A。 @tc 没错。因此，检查 UA 似乎更像是一个额外的thin 安全层。你说盐+散列是没用的，但同时你说你应该保护你的会话存储。在我看来，使用这两个东西将有助于隐藏这些信息，所以如果黑客获得了对数据库的访问权限，但没有获得生成这些条目的确切代码，他仍然不知道这些是什么（假设你也没有保存该信息在同一台计算机上的其他地方清楚，显然......就像你的日志。）【参考方案2】：

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

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

【讨论】：

1.将会话数据存储在 cookie 中？听起来很奇怪，如果你将它存储在会话中，为什么还要将它存储在 cookie 中？ 2. 这是真的，但是如果您的共享服务器允许其他帐户持有人打开您的 tmp 文件，那么您无论如何都会遇到严重的安全问题......我曾经使用过的每台共享服务器都不允许您访问其他人的 tmp 文件。然而，这是一个非常好的观点。 1. cookie 是会话。不需要任何服务器端存储。即，不是 cookie 持有指向带有数据的服务器端资源的指针，而是数据实际上在 cookie 中。 2. 我不是指“（共享服务器）端”资源，我指的是“共享（服务器端）”资源——即，即使是私有服务器也有一个共享的 /tmp 文件系统。它不仅仅是文件。可以是数据库表或 memcache 集群。我并不是说散列指纹会增加很多安全性，但这并不是一个可怕的想法。至少，它为您提供了一个较短的字符串来存储和比较。 :) 1.会话数据不是 100% 存储在一个叫做 cookie 的 cookie 中吗？ 2. 你是否暗示会话文件，通常存储在 tmp 文件夹中，可以被外人访问？存储在 tmp 中的文件是否比文件系统的其他部分更容易访问，因为它是服务器上的共享资源？任何有关这方面的信息都会很棒。 1.你说番茄... :) 2. 当然有可能。可能是配置错误，或者只是一个懒惰的系统管理员。但总的来说，出于这个原因，/tmp 不被认为是存放会话数据的好地方——会话文件应该位于 Web 服务器用户明确拥有的子目录中，而不是世界可读的。即使 /tmp 中的文件只能由 Web 服务器用户读取，我也可能会看到它们的文件名，然后在我的站点上编写一个 3 行 php 脚本，它可以显示其他任何人的会话文件的内容。（因为脚本将由 Web 服务器用户运行...）我能想到一个更好的方法来修复2：在数据库中，将会话数据存储在h(session_id)下。这意味着数据库转储不会泄露会话 ID，前提是您的会话 ID 具有足够的熵并且您的哈希是抗原像的（两者都不难实现）。此外，以网络服务器用户身份运行所有脚本首先是一个安全漏洞......【参考方案3】：

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

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

重点是分层安全和深度防御：

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

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

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

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

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

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

从妥协的第一步开始，攻击者可能会（并且严重程度越来越高）：

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

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

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

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

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

【讨论】：

【参考方案4】：

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

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

【讨论】：

【参考方案5】：

您可以在此处找到可行的解决方案： http://shiflett.org/articles/the-truth-about-sessions

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

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

如果你的文件系统中有黑客，你会有更大的问题：D

【讨论】：

如果一开始就没有安全地生成会话 ID，那么您已经迷路了。您链接到的帖子给出了12345 的示例，并将其称为“安全彻底的默默无闻”。你猜怎么了？猜测 User-Agent 比猜测 5 位数字更容易！ “散列是为了使数据统一。盐是为了掩盖散列过程 - 因此攻击者无法为他自己的 HTTP 标头组合生成有效指纹。” - 为什么散列服务器端会阻止攻击者猜测标头信息？如果他们试图冒充某人的会话，服务器将在尝试匹配之前以与存储信息相同的方式对他猜测的标头进行哈希处理。喜欢这篇文章，以及所有的 cmets。 @tc session_id 存储在 $COOKIE 中，指纹存储在会话中（服务器上等等） @dqhendricks 如果您仔细阅读 cmets，您会发现评论 Chris “根本没有理由使用 md5() 或 salting。这种有效但有点过时的技术是创建一个同时存储在客户端和服务器上的指纹。”【参考方案6】：

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

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

【讨论】：

可能我误会了你，但是浏览器升级/IP 更改通常是重置会话的充分理由（如果你不做“记住我”功能，女巫本身就很糟糕）。跨度> IP 更改是重置会话的可怕原因。它一直发生在 IPv6 上，或者当您将笔记本电脑从工作地点搬到家中时，或者当您的 DSL 调制解调器重新连接时，或者...... 看来这真的取决于国家。在我正在开发的网站上，我们做了一些研究，只有不到 1% 的用户在他们的 IP 中的最后一个八位字节更改次数超过一周一次（当然，我们每天只有大约 2k 的唯一身份，所以这是不是很好的统计数据）。让他们每次都重新登录似乎并不困扰他们（他们的活动统计数据与其他人相似）。你有一些数字来确认你的帖子吗？我对此非常感兴趣。我说的是 IP 变化，而不是移动到不同的 /24。您还提到了“最后一个八位字节”，所以大概您还没有启用 IPv6。我也坚持我的说法，即任何可以嗅探会话 cookie 的人也可以嗅探 U-A，并且可能也可以很容易地使用相同的 IP，因此“指纹”的用途有限。不，我们没有启用 IPv6，但作者说“几个 ip 块”，所以很可能他也没有使用它。关于“任何可以嗅探会话 cookie 的人......都可以使用相同的 IP”：并非如此，有很多特定于 cookie 的漏洞：en.wikipedia.org/wiki/… 等等，IP 窃取/伪造要困难得多，在大多数情况下可以检测到。 TLDR：您很可能只能通过“入侵”用户的计算机/网络来伪造 IP，但是没有它也有很多方法可以窃取 cookie。【参考方案7】：

如果黑客可以找到你文件系统以查看您的会话文件内容，你不是已经在那一点？

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

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

【讨论】：

【参考方案8】：