真的需要哈希会话指纹吗？

Question

请在投票前仔细阅读

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

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

如果黑客可以访问您的文件系统以查看您的会话文件内容，那么您是否已经在这个时候进行了管理？

任何信息都非常感谢。

Answer 1

大部分都有意义，但散列和腌制毫无意义。

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

至于基于用户代理绑定会话，这也可能有所帮助。必须要认识到，如果你使用未加密的通道（例如HTTP），那么用户代理检查就不那么有用了，因为它也可以被入侵者复制。

当谈到腌制和散列时，这是没用的。他们没有增加你的身份检查的力量。他们唯一做的就是让你的设计复杂化。对于这件事，我认为他们会降低你的安全水平。

一如既往，要记住一些规则：

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

Answer 2

我可以想到两个有用的案例：

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

Answer 3

作为对@Kai Sellgren（+1）的回应的补充，其中包含一些关于如何保护会话存储的一些好的提示，我会添加一些想法，而不是解释哈希＆amp;某些特定应用的盐。

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

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

妥协绝不是布尔事物，你不是'完全妥协'或'完全安全'。我喜欢的真实历史之一是mySpace worm explanation，它显示了真正的攻击以及必须如何打破防御步骤。总有一堵新墙。举个例子，当我在办公室时，我与老板共享相同的IP，也许是相同的浏览器，这可能会破坏仅基于IP +用户代理的安全性。

所以在哈希＆amp;会议印章的盐我们显然是在几个墙倒下后行动。凯为我们展示了一些这样的墙。当他谈到保护会话存储时，我会添加两件事：

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

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

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

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

从攻击的第一步开始，攻击者可能会（并且在严重程度上增加）：

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

印章的简单哈希会让他的生活变得更加艰难，但它只会是一道破墙，盐会让这堵墙真的难以打破。< / p>

一个重要的一点是，从你的问题来看，如果一个人可以改变会话存储中的某些内容，我已经心情不好了吗？。好吧，也许不完全。如果应用程序的chroot /分离/证券化是唯一允许他这样做的话，对他来说将是一场噩梦。

第二个重点是：我应该在每个Web应用程序上都进行这种级别的深度安全性吗？。答案是否定的。 过度工程是一件坏事，可以通过简单的事实来降低应用程序的安全性，因为它变得更难以理解和干扰。如果出现以下情况，则无需复杂化应用程序：

• 您的会话存储分离水平非常高
• 您只在服务器上，只有一个应用程序，而不是任何类型的多站点处理
• 您的应用程序安全级别太弱，以至于应用程序上可以使用简单的代码注入，因此攻击者不需要会话固定： - ）

Answer 4

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

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

Answer 5

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

指纹识别打击会话劫持。 攻击者不仅需要您的session_id，还需要任何敏感的HTTP标头。 它为攻击者增加了另一个障碍，尽管可以轻易克服。

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

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

Answer 6

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

您可能做希望做的是在登录尝试时更改会话ID，这是防止“会话固定”攻击的可靠方法（攻击者使受害者负载{{3例如，通过<img>，等待您登录，现在知道受害者的会话ID）。几乎没有理由在登录中保留会话，您可以复制需要保留的一些内容（例如购物车）。

Answer 7

  

如果黑客可以攻击你   filesystem来查看你的会话文件   内容，你不是已经在冲洗了   那一点？

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

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

Answer 8

  

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

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

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

盐怎么能有用呢？我必须承认，我认为没有理由加盐。只有从哈希中猜测指纹才更有意义。但是，由于我没有看到散列指纹的任何安全优势（它仅保留在服务器端并且已经相当安全），因此盐析不会添加任何内容。

如果会话存储本身不被认为是安全的（如果是参数），则whole session should be encrypted，而不仅仅是指纹。

特别是对于指纹，我没有看到很多用于散列和腌制它。