9

我最近遇到了几个流行的 PHP 相关答案，建议使用 superglobal $_REQUEST，我认为这是代码异味，因为它让我想起了register_globals.

您能否提供一个很好的解释/证据来说明为什么$_REQUEST是不好的做法？我将抛出一些我已经挖掘出来的示例，并且希望获得有关理论攻击向量和现实世界漏洞的更多信息/观点，以及系统管理员可以采取的合理步骤以降低风险的建议（缺少重写应用程序......或者，我们是否需要去管理层并坚持重写？）。

漏洞示例：默认GPC数组合并顺序意味着 COOKIE 值覆盖 GET 和 POST，因此$_REQUEST可用于 XSS 和 HTTP 攻击。PHP 让 cookie 变量覆盖超全局数组。本演讲的前 10 张幻灯片给出了示例（整个演讲很棒）。phpMyAdmin 利用CSRF 攻击示例。

对策示例：重新配置$_REQUEST数组合并顺序 from GPC以CGP使 GET/POST 覆盖 COOKIE，而不是相反。使用Suhosin阻止覆盖超全局变量。

（另外，不会问我是否认为我的问题是骗人的，但令人高兴的是，对于“何时以及为什么应该使用 $_REQUEST 而不是 $_GET / $_POST / $_COOKIE？”的压倒性 SO 答案是“从不”。 )

4

4 回答 4

6

照原样对待它：一种从用户那里获取数据的方法。它必须经过清理和验证，那么您为什么要关心它是以 POST、GET 还是 cookie 的形式出现的呢？他们都来自用户，所以说“他们可以被欺骗！” 是多余的。

于 2008-11-03T14:20:04.030 回答
5

$_REQUEST 与 $_GET、$_POST 和 $_COOKIE 一样是邪恶的。虽然我认为有使用 $_REQUEST 的有效场景，但有一个很好的理由不使用 $_REQUEST 并将其标记为“不良做法”。

使用 $_REQUEST 的主要原因是参数可以在 $_POST 或 $_GET 中传输。通过访问 $_REQUEST 您不必同时检查 $_GET 和 $_POST 它的值已设置。问题是 ini 设置gpc_order可以改变构建 $_REQUEST 的行为。此设置可能因服务器而异，您的脚本可能会改变行为。

于 2008-11-03T16:00:17.493 回答
5

$_REQUEST$_GET是有问题的，因为它忽略了 URL ( ) 和请求正文 ( )之间的区别$_POST。HTTP-GET 请求应该没有副作用，而 HTTP-POST 可能有副作用，因此不能被缓存。将这些完全不同的数据源放入一个桶中，需要非REST -ful 的应用程序，也就是糟糕的应用程序。

于 2008-11-03T17:16:15.873 回答
0

它容易受到 URL 上传递的任何东西的影响。因此，如果表单包含与表单一起提交的带有“userid”的隐藏字段，尽管理论上用户无法编辑它，但如果足够敏锐，没有什么能阻止他们更改值。

如果您只是想从请求中获取价值，那很好，但您需要意识到它很可能被欺骗，因此您需要采取相应的行动，当然不要将其用于安全的参数/值数据。

于 2008-11-03T14:06:57.847 回答