如何在网络应用程序中保护存储会话值？

Question

编辑:我把这篇文章的标题从“如何管理网络应用程序中的会话？”“如何在网络应用程序中保护存储会话值？”因为这可能是误导

在最近几个月里，我碰巧遇到了有趣的场景，这让我想知道如何管理web应用程序会话。

几个月前，我读到了一个允许攻击者执行会话劫持的Joomla3.4中的SQL注入。这是可能的，因为Joomla3.4将连接到Joomla的每个用户会话的值存储在数据库中。有趣的是，几个星期前，我在一个朋友的地盘上表演了一些，他建了一个时间圈。他的网站太老了，他还在使用Joomla1.1。我可以立即在他安装的插件中找到一个SQL注入，因此我想起了会话表，并查找了它。我找到了，我试着向他展示弱点的影响。问题是..。我做不到。存储在数据库中的值与浏览器接收的值不同。我检查了Joomla源代码，结果是Joomla1.1生成了一个伪随机数，使用这个数字执行了一些md5操作，并将伪随机数发送到浏览器，并将md5操作的结果存储在数据库中。通过这种方式，我根本无法执行会话劫持。

我也尝试过通知 Joomla社区，但他们似乎并不关心。在我看来，10年前的软件不允许攻击者执行会话劫持，以防在新版本中发现SQL注入。

我开始想知道什么是管理会话值的最佳方法。为什么要将它们存储在数据库中？为什么不简单地使用后端编程语言所提供的(比如php中的session_start )呢？

你觉得那个怎么样？

Answer 1

是的，在数据库中散列会话令牌是最佳实践。这样，如果数据被公开，会话就不会被劫持。会话标记本身应该是生成至少64位熵。

因此，cookie = token中提供的值，数据库中存储的值= token散列。

从2016年起，建议使用沙二来创建哈希。请注意，使用充分熵生成的值不需要盐类。

服务器端会话存储通常需要数据库服务器，其中服务器是群集的(虽然可以使用缓存层)。虽然您可以使用PHP自定义处理程序来完成这个任务，但是Joomla的作者们似乎决定使用自己的版本，正如您提到的，这很容易受到数据提取攻击的攻击。

限制对存储机制的访问也是最佳做法。例如，具有对表的写访问权限的数据库帐户可用于登录、注销和更新会话到期，以及用于检查登录会话的读取访问权限的数据库帐户。应用程序的其余部分可以使用一个根本无法访问sessions表的数据库帐户。可以使用一个秘密的“胡椒”/“系统范围的盐”来减少会话表可能被写入的其他攻击。

Answer 2

不是的。

在你向我们展示的代码中有很多花招，但没有真正的安全魔法。

生成ids

如果我登录到我的银行的网站，并得到一个值为435812的会话曲奇，我不需要是一个特别的733 T黑客，我认为如果我把它改为435811,435810，.

会话ID需要不可预测，但同时也是唯一的。使用加密散列是创建随机和稀疏值集的好方法。巧合的是，大多数实现输出的值跨不同的表示形式(如urlencode、most实体、mysqli_real_escape_string等)可移植，而不需要额外转义。

获取会话数据的全部要点是，它是存储在服务器上的信息，可以在稍后的日期检索。这意味着来自用户的后续请求必须映射到相同的数据集。从您向我们展示的代码中，Joomla1.1似乎是通过维护一个将cookie值映射到会话id的查找表来做到这一点的。如果您可以注入SQL，那么您可能可以在其中注入带有联接或子查询的SQL。

威胁建模比缺乏保护更糟糕的是，它使得枚举会话变得更加容易--因为数据库中可以访问可用会话的列表。

但SQL注入黑帽只是一个威胁模型。代码注入也是一种风险(特别是在没有维护的、现成的CMS中，比如Joomla )。如果攻击者能够将PHP代码注入系统，则将会话id直接放入会话cookie并使用基于文件的处理程序同样容易受到攻击。

然后有可能直接攻击存储--无论是就地攻击还是从备份中发现会话中的数据。

管理会话值

的最佳方法

将它们存储在数据库中是继使用文件系统上的默认处理程序存储它们之后的第二低公共分母。它确实简化了共享主机上vhost之间会话数据的分离(虽然不多)。它也很容易扩展到多个服务于同一站点的设备。如果代码在基础表上没有通常的select特权，而是通过特权分离(例如，使用作为不同DB uid运行的存储过程)，则不能对它们进行枚举。

然而，这同样具有有限的适用性，并且没有解决数据被破坏的情况。

我的解决方案将使用一个随机生成的密钥加密会话数据，而该密钥根本不存储在服务器上。因此，数据在静止时受到保护。这种方法是有局限性的--它限制了能力，并将成为支持的一种方式。也许还有其他我没有预见到的问题。