我的心腹目前正在学习PHP，
他给我发了他的PHP代码，
我发现他在代码中使用$ _REQUEST。
我读过的教科书说 $ _REQUEST有安全问题所以 我们最好使用$ _POST。
所以我回复了那个心腹的人 我们最好使用$ _POST。
这样好吗？
答案 0 :(得分：33)
我会说将$ _POST描述为比$ _REQUEST更安全是危险的。
如果在使用数据之前未对数据进行验证和清理，则可能存在攻击向量。
简而言之： 如果没有以安全的方式处理数据，那么数据来自何处并不重要。
答案 1 :(得分：19)
嗯，$_REQUEST有问题的原因是它从$_GET，$_POST和$_COOKIE中获取值，这意味着如果您以某种方式编写代码并且做出某些无效的信任客户端假设，恶意用户可以通过在与您预期不同的位置提供值并覆盖您尝试传递的值来利用它。
这也意味着你可能已经给了你的心灵不正确的指示，因为它可能是他从$_REQUEST获取的GET或COOKIE值。您需要使用您要查找的值实际显示的任何位置，而不一定是$_POST。
答案 2 :(得分：8)
正如在几个答案中已经提到的那样：来自客户端的任何数据都不可信任，默认情况下必须被视为恶意。这包括$_POST，$_GET，$_COOKIE和$_REQUEST（前者的组合），但也包括其他内容。
当谈到其中一些比其他人更危险时，我确实会将$_GET和$_REQUEST（因为它包括$_GET）从$_POST分开，因为生成（即操纵）POST请求比GET请求稍微困难。这里的重点是略微，但是使用POST进行敏感操作至少会删除另一层低悬的水果来开发。
特别是当谈到Cross Site Scripting（或XSS）和cookie被盗时，通过简单地插入带有被操纵的URL的隐藏图像，让受害者的浏览器向受攻击的服务器发出GET请求是相当容易的。进入页面或伪造链接。
发出POST请求至少需要一些JavaScript，稍微更难以注入受害者的浏览器执行（取决于具体情况）。显然，攻击者可以直接生成POST请求，因此它们也不可信任，但对于攻击者通过第三方浏览器的情况，它们操作起来有点困难。
安全性始终是要尽可能地破坏您的应用程序 - 考虑实施限制等。它永远不会是100％安全。因此，当在不同的实现方法之间进行选择时，选择更难以利用的替代方案，即使差异是边际的，这是最佳实践。
最后，它总是要去掉低垂的水果。当然，也可以操纵POST请求，但对于任何风险较高的操作，请使用POST请求并限制自己在代码中使用$_POST。这样你已经排除了一些非常简单的GET偷渡式攻击，现在可以专注于验证你的POST数据。只是不要假设默认使用POST突然使操作安全。
答案 3 :(得分：4)
当然可以告诉人们使用$_POST代替$_REQUEST。最好更确切地了解获取数据的位置。
答案 4 :(得分：2)
@Christian：
当谈到其中一些比其他人更危险时，我确实会将$ _GET和$ _REQUEST（因为它包含$ _GET）从$ _POST中分离出来，因为生成（即操纵）POST请求比创建POST请求要困难得多。一个GET请求。这里的重点是略微，但使用POST进行敏感操作至少会消除另一层低悬的果实。
Bzzt。对不起，但这不是真的。
任何了解GET和POST之间的区别或者未经过输入的输入可能会被利用的人都会毫不犹豫地激发Tamper Data。
有些人就在这里：在精心设计的系统中使用$ _REQUEST没有丢失或获得安全性。
答案 5 :(得分：1)
使用$_POST和$_REQUEST之间没有真正的安全性差异，您应该仔细审查数据。
$_REQUEST的最大问题是您可能尝试从POST表单中获取数据，但可能具有相同名称的GET参数。数据来自哪里？最好明确地从您希望的位置请求数据，在该示例中为$_POST
有轻微的安全优势 - 对GET参数执行XSS（更具体地说是XSRF）攻击更容易，如果你使用$_REQUEST，这可能是真的只想要POST数据..
当您需要来自POST，GET或cookie的数据时，情况非常少。如果您想获取POST数据，请使用$_POST，如果您想从GET参数中获取数据，请使用{{1如果你想要cookie数据，请使用$_GET
答案 6 :(得分：0)
最安全的方法是验证和验证数据。我通常为表单生成一个随机唯一ID并将其存储在用户的会话中，但这很容易被确定的攻击者绕过。更好的是清理所有传入的数据。查看htmlspecialchars（）及其相关函数。我还为跨站点使用第三方实用程序，例如HTML Purfier
在一些实际的注释中，总是使用intval（）应该是数字，转义所有传入的字符串，使用正则表达式的电话号码，电子邮件或任何将成为SQL查询的一部分。
希望这有帮助。