PHP 会话变量的安全性如何？

Posted 2023-02-19

【中文标题】PHP 会话变量的安全性如何？

【英文标题】：How safe are PHP session variables?

【发布时间】：2010-11-13 22:40:43

【问题描述】：

我有一个登录脚本，可以根据“用户”表中的数据验证用户名/密码。此外，我有一个“角色”表，它指定给定用户的访问级别。假设我正在使用安全登录脚本，在成功登录后简单地执行附加查询以发现用户的授权级别并将其存储到会话变量中是否存在任何安全漏洞？然后的想法是，在任何具有混合权限的页面上，我可以简单地查询会话变量以发现登录用户的授权级别。

谢谢。

【参考方案1】：

应该注意的是，在 Apache 中，php $_SESSION 超全局变量可以跨虚拟主机访问。考虑这种情况：

您的服务器托管两个域，example.com 和 instance.org。 PHP 会话存储在仅限于域的 cookie 中。 用户登录到 example.com 并收到一个会话 ID。 Example.com 设置了一些会话变量（它们存储在服务器上，而不是在 cookie 中）。 第三方在传输过程中截获 cookie 并将其传递给 instance.org。 Instance.org 现在可以访问 example.com 会话变量。

当您控制服务器上的所有虚拟主机时，这没什么大不了的，但如果您在共享机器上，那就有问题了。

【讨论】：

如果可能的话，您知道如何限制每个虚拟主机一个 sperglobal 吗？

@JRsz 您可以通过 session_save_path() 函数 (php.net/manual/en/function.session-save-path.php) 更改 php.ini 中存储会话的目录。

【参考方案2】：

如果您依赖存储在会话变量中的值来确定角色，那么您将无法更改数据库中的值并将其反映到用户的当前会话中。如果您查看 Zend Framework，身份验证和授权之间有明显的区别，并且手册中措辞强硬的警告仅在会话中存储最少量的数据（即“是的，他是用户 #37 并且他已登录”） .

就“安全”而言 - 除非您在共享主机上，否则无需担心。在正确配置的共享主机上，它们也应该相对安全。

【参考方案3】：

会话比 cookie 安全得多。但是仍然有可能窃取会话，因此黑客可以完全访问该会话中的任何内容。避免这种情况的一些方法是 IP 检查（效果很好，但 fi 非常低，因此本身不可靠），以及使用随机数。通常使用 nonce，您有一个每页的“令牌”，以便每个页面检查最后一页的 nonce 是否与它存储的内容匹配。

在任一安全检查中，都会失去可用性。如果您进行 IP 检查并且用户位于 Intranet 防火墙（或导致此情况的任何其他情况）后面，该防火墙没有为该用户保留稳定的 IP，则他们每次丢失 IP 时都必须重新进行身份验证。使用随机数，您会得到“点击返回会导致此页面中断”的有趣情况。

但是使用 cookie，黑客可以通过使用相当简单的 XSS 技术窃取会话。如果您将用户的会话 ID 存储为 cookie，他们也容易受到此攻击。因此，即使会话仅对可以进行服务器级黑客攻击的人来说是可渗透的（如果您的服务器是安全的，这需要更复杂的方法并且通常需要一定数量的权限），您仍然需要一些额外的验证级别根据每个脚本请求。您不应同时使用 cookie 和 AJAX，因为如果该 cookie 被盗，这会使您更容易完全进入城镇，因为您的 ajax 请求可能无法对每个请求进行安全检查。例如，如果页面使用随机数，但从不重新加载页面，则脚本可能只检查该匹配。如果 cookie 持有身份验证方法，我现在可以使用偷来的 cookie 和 AJAX 漏洞去城里做我的坏事。

【讨论】：

需要注意的是PHP将会话ID存储为cookie。

关于 nonce 的 wiki 文章很轻，但有不错的链接：en.wikipedia.org/wiki/Cryptographic_nonce 基本思想，据我所知，就像一个令牌，但它只能使用一次（使用一次的数字）。每个页面请求都会检查最后一个随机数并创建一个新随机数。因此，如果我尝试对您的密码进行暴力攻击，我会得到一枪，因为随机数在第 2 轮不会匹配。如果我窃取该页面的会话和随机数，我可以继续发出请求并更新随机数，直到你提出一个抛出随机数匹配的请求。因为它会看到我的请求和我的 nonce，所以更新...

到新的，然后你的请求（你在我最后一次请求之前得到的随机数）将过期，从而导致脚本终止会话。

@Anthony 如果您也为 AJAX 请求重新生成会话 ID，则无法利用“漏洞”。

@Pacerier - 2 年后，我和 AJAX 都取得了长足的进步。正如您所建议的，我现在尝试在每个可能的级别上实施相同的安全技术。当时我不知道的一个功能是能够在每个请求上重置会话 ID。这不仅降低了会话 ID cookie 被盗的风险，而且还针对每个请求完成，因此 ajax 和标准请求获得相同的安全优势（以及潜在的漏洞利用）。

【参考方案4】：

只有在您的服务器上执行的脚本才能访问 _SESSION 数组。如果您定义会话 cookie 的范围，您甚至可以将其限制在特定目录中。除了您之外，其他人可以获得该会话数据的唯一方法是将一些 PHP 代码注入您的一个页面。

对于您使用的系统，这是可以接受的，并且是保存数据库调用的好方法，但请记住，它需要用户注销并再次登录才能应用任何授权更改。因此，如果您想锁定一个帐户并且该用户已经登录，则不能。