应该在存储会话内容之前散列会话ID吗？

Question

我想知道在将会话写入会话存储之前散列我的会话ID是否明智，以防止会话ID泄露。

我正在Symfony框架的基础上用PHP编写一个应用程序。默认情况下，PHP使用会话ID作为文件名的一部分，将会话存储为PHP进程可读的目录中的文件。我看到的问题是，如果应用程序中存在本地文件包含错误或RCE，攻击者可以轻松地列出所有有效的会话if和劫持会话。

PHP的替代会话存储存在，如Redis或Memcache，但它们也存在相同的缺陷。您可以轻松地枚举Redis或memcache中的所有键，从而获得有效会话ID的列表。

我关于缓解的想法很简单。不要使用会话ID作为键来存储会话，而是使用散列(会话ID)作为键。如果攻击者随后枚举所有现有密钥，则仍然没有任何会话If。性能问题和会话的生存期相对较短(相对于密码而言)，因此我将使用像SHA-256或BLAKE这样的快速散列，而不是使用bcrypt来哈希会话ID。

我的问题是:这有什么意义吗？这能给我买点额外的保安吗？或者本地文件包含错误或RCE已经意味着“游戏结束”，这仅仅是安全剧场吗？

我并不是第一个看到这种可能的威胁的人，但是我找不到任何提到这一点，或者将会话in作为一种良好的缓解或深入防御的方法。也许我只是缺少合适的词汇投入谷歌？

Answer 1

会话文件上的LFI是可能的，但是还有很多其他选项，如/proc/self/environ、文件描述符、web服务器日志、原始数据库文件、SSH/FTP/mail日志、上传的文件或位于/tmp中的临时上载文件也是可能的，因此通过这样做可以获得很少的安全性。如果攻击者能够枚举所有会话文件，他们只需尝试所有这些文件，直到其中一个有效为止。您最好把开发时间花在服务器上，或者检查代码。

Answer 2

根据我的经验，这不是一个常见的安全要求，甚至钢笔测试人员也不这么认为。

这里有几个注意事项：

• 其原因可能与性能与安全性有关:现在您应该使用像bcrypt这样的散列算法，它的速度很慢(从~250 ms到~1 s)，这对于一个登录请求来说是可以接受的，但对于N个请求却不是很好的扩展。
• 泄漏密码对最终用户有很大影响，相反，泄漏会话ID可以更容易、更透明地管理。
• 密码通常是长寿对象，会话ID短对象。
• 如果您的服务器上有RCE，他/她已经可以(理论上)访问最终数据，他/她也可以创建/替换散列会话。
• 使用散列会话，如果攻击者发现只读类型的漏洞，或者在某些有效的会话ID发生数据破坏的情况下，您肯定有优势。

我的最后一个建议是与您的团队找到最佳的折衷方法(例如，哈希会话，但使用更快的哈希，或者只将普通会话ID存储在内存中)，同时考虑到数据的相关风险(例如银行信息或比萨订单信息)，并将应用程序/服务器上要执行的强化任务排序。

PS: OWASP ( web安全的一个良好参考点)没有提到它，但在日志中公开的会话ID除外。

Answer 3

如果攻击者可以直接读取web目录之外的文件，则会话ID是您最不担心的。如果他们能写文件，那么是时候将其从轨道上核爆了。

正因为如此，在存储会话ID时损坏它们并不会给您带来额外的安全性。它只是给你一些默默无闻。

但是，采取措施确保会话ID的安全仍然是有用的。用于此目的的最有用的工具是会话ID重新生成。在安全敏感的应用程序中，PHP手册建议每15分钟使用一次重新生成会话ID。OWASP建议使用每个请求重新生成会话ID，尽管我不知道它们当前的指导是什么。

无论会话ID多长时间重新生成一次，用户登录时都必须重新生成会话ID，以防止会话固定攻击。