$ _REQUEST有多邪恶，什么是可接受的创可贴对策？

Question

我最近遇到了几个与PHP相关的流行答案，建议使用超级全局$_REQUEST，我认为这是代码味道，因为它让我想起了register_globals。

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

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

示例对策：从$_REQUEST重新配置GPC数组合并顺序到CGP，因此GET / POST会覆盖COOKIE，而不是相反。使用Suhosin来阻止覆盖超全球。

（另外，不会问我是否认为我的问题是一个骗局，但很高兴对"When and why should $_REQUEST be used instead of $_GET / $_POST / $_COOKIE?"的压倒性回答是“永远不会。”）

Answer 1

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

Answer 2

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

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

Answer 3

$_REQUEST存在问题，因为它忽略了网址（$_GET）和请求正文（$_POST）之间的差异。 HTTP-GET请求应该没有副作用，而HTTP-POST可能有副作用，因此无法缓存。将这些完全不同的数据源放入一个存储桶中，需要使用非REST - 的应用程序，即不良应用程序。

Answer 4

它容易受到传递给URL的任何内容的攻击。因此，如果表单包含带有表单提交的“userid”的隐藏字段，虽然理论上用户无法对其进行编辑，但如果足够敏锐，则没有什么能阻止他们更改值。

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