请仔细阅读以下内容后再投票……
我看到许多会话管理类通过用户代理和一些IP块进行连接来创建指纹。他们似乎还会添加一个盐并在将其存储在会话变量中之前对该指纹进行哈希处理。
为了验证当前会话用户是否确实是原始会话用户，这种指纹生成通常会在每个请求中发生。因此，我想知道，像这样的盐和哈希真的必要吗？
如果黑客可以进入您的文件系统以查看会话文件内容，那么此时您不是已经遭受了攻击吗？
非常感谢任何信息提供。
对于会话指纹来说，进行哈希处理是否真的必要？
34
- dqhendricks
3
你需要确保我无法可预测地重新创建你的会话密钥（因此是私有盐）。如果我可以这样做，那么我就不需要访问你的服务器，只需随机生成密钥直到进入系统。 - Geoffrey Wagner
1@Geoffrey Wagner 首先，为什么服务器端的盐值会对暴力攻击有影响呢？如果我在服务器端为任何试图冒充该用户以获取其会话访问权限的人使用相同的盐值，那么他们仍然只需要猜测客户端头部输入来进行攻击，因为服务器会为他们进行哈希。 - dqhendricks
我撤回我的话，我完全没有处于服务器思维状态，糟糕。 - Geoffrey Wagner
8个回答
11
大部分内容都很合理，但是哈希和加盐一点也不合理。
如果将会话与IP地址绑定，则更难劫持会话。我建议这样做，但您无需完全严格执行此操作。您可以仅绑定到IPv4的前三个部分左右。选择权在于您。 IP检查越严格，安全性越高，但对用户来说越不方便。
至于基于用户代理绑定会话，那也可能有所帮助。必须意识到，如果您使用未加密通道（例如HTTP），则用户代理检查的用处就较小，因为黑客也可以复制它。
当涉及加盐和哈希时，这是无用的。它们对身份验证检查没有增强作用。它们唯一做的是使设计变得复杂。对此我认为它们降低了安全级别。
像往常一样，请记住以下几个规则：
- 使用强会话标识符。这意味着使用良好的随机源并确保有足够的位数。
- 将会话绑定到IP，至少在某种程度上。
- 如果可能，将会话绑定到用户代理。
- 使用SSL / TLS。没有它，理论上所有会话系统都是不安全的。
- 保护您的会话存储。无论是基于文件系统还是基于数据库。
- Tower
3
同一用户的任何其他访问都将使用相同的U-A，因此如果用户通过HTTP进行任何浏览，则攻击者可以嗅探U-A。 - tc.
@tc 没错。因此，检查UA似乎更像是一层额外的薄安全层。 - Tower
你说盐值+哈希是无用的，但同时你说你应该保护你的会话存储。在我看来，使用这两个东西将有助于隐藏信息，因此如果黑客可以访问数据库，但无法访问生成这些条目的确切代码，他仍然不能知道这些是什么（假设你不会在同一台电脑上的其他地方以明文保存这些信息，显而易见......比如日志文件）。 - Alexis Wilke
4
我能想到两种情况下使用这个功能会很有用：
1. 当会话数据存储在客户端时（例如cookie中）。这样，我就无法将我的cookie带到另一台计算机上，并且我也无法伪造自己的cookie内容。（好吧，这不太可能发生...）
2. 当会话数据存储在某些共享的服务器端资源（例如/tmp）中，并且容易被窃听。在这种情况下，如果窃听者能够看到会话的内容，他们仍然无法伪造与该会话的连接，因为他们不知道哪些数据用于生成指纹。
1. 当会话数据存储在客户端时（例如cookie中）。这样，我就无法将我的cookie带到另一台计算机上，并且我也无法伪造自己的cookie内容。（好吧，这不太可能发生...）
2. 当会话数据存储在某些共享的服务器端资源（例如/tmp）中，并且容易被窃听。在这种情况下，如果窃听者能够看到会话的内容，他们仍然无法伪造与该会话的连接，因为他们不知道哪些数据用于生成指纹。
- Alex Howansky
5
- 在cookie中存储会话数据？听起来很奇怪，如果您已经在会话中存储了它，为什么还要在cookie中存储它呢？
- 这是真的，但是如果您的共享服务器允许其他账户持有者打开您的tmp文件，那么您无论如何都存在严重的安全问题...然而，我曾经使用过的每个共享服务器都不允许您访问其他人的tmp文件。尽管如此，这仍然是一个非常好的观点。
- Cookie就是会话。不需要任何服务器端存储。也就是说，cookie不再保存指向服务器端资源的指针，而是实际上将数据保存在cookie中。
- 我的意思不是“(共享服务器)-端”资源，我是指“共享（服务器端）”资源——即使是私有服务器也有共享/tmp文件系统。而且这不仅仅是文件，还可以是数据库表或memcache集群。我并不是说哈希指纹会增加很多安全性，但这并不是一个可怕的想法。至少，它给你提供了一个更短的字符串来存储和比较。 :)
- 会话数据不是完全存储在一个叫做cookie的cookie里吗？哈哈？
- 你是在暗示会话文件通常存储在tmp文件夹中，可以被外部访问吗？因为它是服务器上的共享资源，所以在tmp中存储的文件比文件系统的其他部分更容易被访问吗？任何相关信息都将非常有用。
- 你说番茄... :)
- 可能是配置错误，或者只是懒惰的系统管理员。但一般来说，由于这个原因，/tmp 不被认为是存储会话数据的好地方——会话文件应该在一个子目录中，由 Web 服务器用户明确拥有，并且不可被全局读取。即使 /tmp 中的文件仅可被 Web 服务器用户读取，我也可以看到它们的文件名，然后在我的网站上编写一个三行 PHP 脚本，可以显示任何其他人的会话文件内容。（因为脚本将由 Web 服务器用户运行...）
我可以想到一个更好的方法来解决2号问题：在数据库中，将会话数据存储在h(session_id)下。这意味着数据库转储不会泄露会话ID，只要您的会话ID具有足够的熵并且您的哈希是预像防护的（这两者都不难实现）。此外，以web服务器用户身份运行所有脚本本身就是一个安全漏洞... - tc.
3
除了@Kai Sellgren (+1)提供的一些有关如何保护会话存储的提示之外，我还想补充一些特定应用程序中哈希和盐的解释。
我不是在谈论使用cookie作为会话存储的应用程序，例如Prestashop电子商务解决方案仍在使用此方法，并加密cookie内容（他们为什么要将会话存储在cookie中？）。我理解我们正在讨论服务器端会话存储。
关键点是分层安全和深度防御：
妥协从来不是二元事物，您不是“完全妥协”或“完全安全”。我喜欢的一个真实历史故事是mySpace worm explanation，它展示了一个真正的攻击以及防御措施如何被打破。总是有新的障碍。举个例子，在办公室时，当我和我的老板使用相同的IP和浏览器时，这可能会破坏基于IP +用户代理的安全性。
因此，在会话标记的哈希和盐中，我们显然是在一些墙倒塌后才采取行动。 Kai向我们展示了其中一些墙。当他谈论保护会话存储时，我想补充两件事：
从这个妥协的第一步开始，攻击者可能会潜在地（且严重地）：
- 读取会话时间戳，或许找到他需要伪造的信息以获取相同的时间戳 - 构建一个新会话，其中包含适用于他的配置的有效会话时间戳，然后在您的应用程序上使用此新会话标识符。您的应用程序将找到会话文件并接受它。 - 更改其中一个有效会话以以相同方式修改时间戳
简单的时间戳哈希会使他的生活更加艰难，但这只是要打破的墙，盐使这堵墙变得更难打破。
一个重要的点是，从您的问题来看，如果有人可以更改会话存储中的内容，我是否已经处于不好的情况？好吧，也许不完全是。如果这是chroot /分离/应用程序安全的唯一允许他执行的操作，那么这个盐对他来说将是一场噩梦。
第二个重要点是：我是否应该在每个Web应用程序上进行如此深入的安全性？答案是否定的。过度工程是一件坏事，并且可以通过简单地使应用程序变得更难理解和维护来降低应用程序的安全性。如果：
- 您已经拥有相当不错的会话存储分离水平 - 您独自在服务器上，只有一个应用程序，没有任何类型的多站点处理 - 您的应用程序安全级别非常弱，以至于攻击者不需要进行会话固定：-)
我不是在谈论使用cookie作为会话存储的应用程序，例如Prestashop电子商务解决方案仍在使用此方法，并加密cookie内容（他们为什么要将会话存储在cookie中？）。我理解我们正在讨论服务器端会话存储。
关键点是分层安全和深度防御：
妥协从来不是二元事物，您不是“完全妥协”或“完全安全”。我喜欢的一个真实历史故事是mySpace worm explanation，它展示了一个真正的攻击以及防御措施如何被打破。总是有新的障碍。举个例子，在办公室时，当我和我的老板使用相同的IP和浏览器时，这可能会破坏基于IP +用户代理的安全性。
因此，在会话标记的哈希和盐中，我们显然是在一些墙倒塌后才采取行动。 Kai向我们展示了其中一些墙。当他谈论保护会话存储时，我想补充两件事：
- 更改每个PHP应用程序的
session.save_path和open_basedir是一个非常好的主意（并为每个应用程序获取单独的虚拟主机）。很少这么做。 - 如果您的应用程序安装在路径上（例如/myapp），请在会话cookie上添加前缀路径（并为同一服务器上的任何其他应用程序修复它）
- 该应用程序正在运行的网站上还有其他应用程序在其他路径（或在同一服务器上的其他域中）运行。其中至少一个应用程序非常不安全。最坏的情况下，可能会在此应用程序中注入服务器端代码，但某些安全墙（如open_basedir或其他chrooting技术）可以防止此注入代码影响您单独的应用程序（或数据）。
- 某些JavaScript库附带一些包含高度不安全脚本的测试子目录，其中不仅有漂亮的会话披露，还可能提供一些会话固定或预测。
- 该应用程序是共享的，谈论类似WordPress的软件，您可以想象一些平台共享许多不同的安装，其中包括不同的模块和可能是一些自定义代码。在这样的平台上，您将找到允许为每个消费者更改盐的设置，有一个原因。其中一个网站可能会影响其他网站的安全性，并且如果应用程序想要全面管理网站，则难以进行清晰的分离。
从这个妥协的第一步开始，攻击者可能会潜在地（且严重地）：
- 读取会话时间戳，或许找到他需要伪造的信息以获取相同的时间戳 - 构建一个新会话，其中包含适用于他的配置的有效会话时间戳，然后在您的应用程序上使用此新会话标识符。您的应用程序将找到会话文件并接受它。 - 更改其中一个有效会话以以相同方式修改时间戳
简单的时间戳哈希会使他的生活更加艰难，但这只是要打破的墙，盐使这堵墙变得更难打破。
一个重要的点是，从您的问题来看，如果有人可以更改会话存储中的内容，我是否已经处于不好的情况？好吧，也许不完全是。如果这是chroot /分离/应用程序安全的唯一允许他执行的操作，那么这个盐对他来说将是一场噩梦。
第二个重要点是：我是否应该在每个Web应用程序上进行如此深入的安全性？答案是否定的。过度工程是一件坏事，并且可以通过简单地使应用程序变得更难理解和维护来降低应用程序的安全性。如果：
- 您已经拥有相当不错的会话存储分离水平 - 您独自在服务器上，只有一个应用程序，没有任何类型的多站点处理 - 您的应用程序安全级别非常弱，以至于攻击者不需要进行会话固定：-)
- regilero
1
我可以想象哈希指纹信息的目的是为了节省存储空间，因为生成的哈希值具有固定长度。
但同时使用盐并没有太多意义。因为正如你已经说过的那样，由于这些数据存储在会话数据存储位置中，如果有人能够获取这些数据，你已经面临比会话固定/劫持更大的问题了。
- Gumbo
1
您可以在这里找到一个可行的解决方案： http://shiflett.org/articles/the-truth-about-sessions
指纹识别可以防止会话劫持。
攻击者不仅需要您的session_id，还需要任何敏感的HTTP头。
它为攻击者增加了另一个障碍，尽管这个障碍很容易被克服。
哈希函数用于使数据统一。盐值用于混淆哈希过程，以便攻击者无法为自己的HTTP头组合生成有效的指纹。
如果黑客进入了您的文件系统，那么您就有更大的问题:D
- Halcyon
6
如果会话 ID 一开始就没有安全地生成，那你已经输了。你链接的帖子举了
12345 的例子，并称其为“安全深度浅”。猜测用户代理甚至比猜测一个 5 位数字更容易！ - tc.哈希是为了使数据统一。盐是为了混淆哈希过程，这样攻击者就无法为自己的HTTP头组合生成有效的指纹。如果攻击者试图冒充某人的会话，服务器端进行哈希处理后，将以与存储信息相同的方式对其猜测的标头进行哈希处理，然后再尝试匹配它，因此服务器端哈希可以防止攻击者猜测标头信息。 - dqhendricks
喜欢这篇文章，也喜欢所有的评论。 - dqhendricks
@tc
session_id 存储在 $COOKIE 中，指纹存储在会话中（因此存储在服务器上）。 - Halcyon如果你看一下评论，你会发现Chris的评论：“根本没有必要使用md5()或者加盐。这种技术虽然有效，但已经有点过时了，现在更好的方法是创建一个指纹并将其存储在客户端和服务器上。” - Halcyon
“指纹”存储位置并不重要，因为攻击者只需要嗅探正确的U-A和IP地址，如果您已经嗅探到COOKIE，这是微不足道的。 - tc.
1
很多不太了解安全的人会将网络上流传的建议组合起来，希望最终得到的结果足够“好”。将会话 ID 绑定到 U-A 会破坏浏览器升级（Chrome 经常这样做），将其绑定到 IP 地址会破坏移动性（任何使用 Wi-Fi 的笔记本电脑用户），而且许多 ISP 没有连续的分配。任何能够嗅探 cookie 的人也可以嗅探 U-A，并且可能可以访问相同的 IP 地址，因为他们从 NAT 后面的不安全 Wi-Fi 中获取了 cookie。
你可能想要在登录尝试时更改会话 ID，这是一种可靠的方法，可以防止“会话固定”攻击（攻击者使受害者加载 http://example.com/?SESSIONID=foo，例如通过
你可能想要在登录尝试时更改会话 ID，这是一种可靠的方法，可以防止“会话固定”攻击（攻击者使受害者加载 http://example.com/?SESSIONID=foo，例如通过
<img>，等待您登录，现在知道受害者的会话 ID）。没有什么理由保留跨登录的会话，您可以复制需要保留的少数内容（例如购物车）。- tc.
8
也许我误解了你的意思，但浏览器升级/IP更改通常是重置会话的足够好的理由（如果您没有使用“记住我”功能，这本身就很糟糕）。 - XzKto
更改IP地址是重置会话的可怕理由。这在IPv6上经常发生，或者当您将笔记本电脑从工作地点带回家时，或者当您的DSL调制解调器重新连接时，等等。 - tc.
似乎这真的取决于国家。在我正在开发的网站上，我们进行了一些研究，发现不到1%的用户每周IP地址的最后一个八位数会改变超过一次（当然，我们每天只有大约2k个独立访客，所以这不是非常好的统计数据）。让他们每次重新登录似乎并不会打扰他们（他们的活动统计数据与其他人相似）。您是否有一些数字来证实您的帖子？我对此非常感兴趣。 - XzKto
我说的是更改IP地址，而不是移动到另一个/24。你还提到了“最后一位八位数”，所以我推测你没有启用IPv6。我仍然坚持我的观点，即任何能够嗅探会话cookie的人也可以嗅探U-A，并且很可能也可以轻松地使用相同的IP地址，因此“指纹识别”具有有限的用途。 - tc.
不，我们没有启用IPv6，但作者说“几个IP块”，所以他很可能也没有使用它。关于“任何可以嗅探会话cookie的人...都可以使用相同的IP”：实际上并不是这样，有很多特定于cookie的漏洞：http://en.wikipedia.org/wiki/HTTP_cookie#Cookie_theft_and_session_hijacking，还有更多，窃取/伪造IP要困难得多，并且在大多数情况下可以被检测到。简而言之：您很可能只能通过“黑客攻击”用户的计算机/网络来伪造IP，但有很多方法可以在不进行此类攻击的情况下窃取cookie。 - XzKto
显示剩余3条评论
1
如果黑客可以进入您的文件系统查看会话文件内容，那么此时您不是已经完蛋了吗？
如果您正在使用 PHP 作为 CGI（例如在 nginx 的情况下），那么我认为不会。如果您设置了正确的权限，则 PHP 用户必须具有读/写权限，而您的 PHP 文件应该只有读取权限。因此，如果您将盐从 Web 服务器传递给 PHP，则 PHP 用户无法访问它（他无法创建任何新的/更改现有的 PHP 文件，这些文件可以由您的 Web 服务器运行，并且他无法访问 Web 服务器，因为它是在另一个用户上运行的），因此他实际上无法黑掉（更改）cookie（只能删除它们），因为他无法获取盐。当然，您还需要从 Web 服务器传递数据库设置。
我从未真正尝试过，所以如果我错了，请纠正我。
如果您正在使用 PHP 作为 CGI（例如在 nginx 的情况下），那么我认为不会。如果您设置了正确的权限，则 PHP 用户必须具有读/写权限，而您的 PHP 文件应该只有读取权限。因此，如果您将盐从 Web 服务器传递给 PHP，则 PHP 用户无法访问它（他无法创建任何新的/更改现有的 PHP 文件，这些文件可以由您的 Web 服务器运行，并且他无法访问 Web 服务器，因为它是在另一个用户上运行的），因此他实际上无法黑掉（更改）cookie（只能删除它们），因为他无法获取盐。当然，您还需要从 Web 服务器传递数据库设置。
我从未真正尝试过，所以如果我错了，请纠正我。
- XzKto
0
“像这样的[http客户端指纹]，盐和哈希真的有必要吗？”
哈希可能有用，可以减少会话数据中指纹所占用的字节数。只要哈希指纹的大小比指纹本身小，这在空间减少方面是有意义的。代价是消耗系统资源来生成哈希。
这真的有意义吗？你需要进行基准测试才能这么说。
那么盐如何有帮助呢？我必须承认，我看不出盐有什么理由。它只有在让从哈希中猜测指纹变得更加困难时才有意义。但是，由于我没有看到在哈希指纹中有任何安全好处（它仅保留在服务器端，并且已经相当安全），因此添加盐并没有增加任何东西。
如果会话存储本身不被视为安全（如果这是争论的原因），则应该加密整个会话，而不仅仅是指纹。
因此，特别是对于指纹，我不认为哈希和加盐有太多用处。
哈希可能有用，可以减少会话数据中指纹所占用的字节数。只要哈希指纹的大小比指纹本身小，这在空间减少方面是有意义的。代价是消耗系统资源来生成哈希。
这真的有意义吗？你需要进行基准测试才能这么说。
那么盐如何有帮助呢？我必须承认，我看不出盐有什么理由。它只有在让从哈希中猜测指纹变得更加困难时才有意义。但是，由于我没有看到在哈希指纹中有任何安全好处（它仅保留在服务器端，并且已经相当安全），因此添加盐并没有增加任何东西。
如果会话存储本身不被视为安全（如果这是争论的原因），则应该加密整个会话，而不仅仅是指纹。
因此，特别是对于指纹，我不认为哈希和加盐有太多用处。
- hakre
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接