我的心腹正在学习PHP,
他给我发了他的PHP代码,
我发现他在代码中使用$ _REQUEST.
我读过的教科书说
$ _REQUEST有安全问题所以
我们最好使用$ _POST.
所以我回答了心腹,
我们最好使用$ _POST.
这个可以吗?
我会说将$ _POST描述为比$ _REQUEST更安全是危险的.
如果在使用数据之前未对数据进行验证和清理,则可能存在攻击向量.
简而言之: 如果没有以安全的方式处理数据,那么数据来自何处并不重要.
好吧,$_REQUEST
有问题的原因是它从$_GET
,, $_POST
和中获取值$_COOKIE
,这意味着如果你以某种方式编写代码并做出某些无效的信任 - 客户端假设,恶意用户可以通过提供值来利用它在一个不同于你预期的地方并覆盖你试图通过的那个地方.
这也意味着你可能已经给了你的心腹不正确的指示,因为它可能是他正在接受的GET或COOKIE值$_REQUEST
.您需要使用您要查找的值实际显示的任何位置,不一定$_POST
.
正如在几个答案中已经提到的那样:来自客户端的任何数据都不可信任,默认情况下必须被视为恶意数据.这包括$_POST
,$_GET
,$_COOKIE
和$_REQUEST
(前者的组合),但其他人.
当谈到其中一些比其他人更危险时,我确实将其分开$_GET
并$_REQUEST
(因为它包括$_GET
)从中$_POST
,因为生成(即操纵)POST请求比GET请求稍微困难一些.这里要强调的是轻微的,但使用POST进行敏感操作至少消除低垂的果实利用的另一层.
特别是当涉及跨站点脚本(或XSS)和cookie盗窃时,通过简单地将带有操纵URL的隐藏图像插入页面或伪造,让受害者的浏览器向受攻击的服务器发出GET请求是相当容易的.一条链接.
发出POST请求至少需要一些JavaScript,这有点难以注入受害者的浏览器执行(取决于具体情况).显然,POST请求可以由攻击者直接生成,因此它们也不可信任,但对于攻击者正在通过第三方浏览器的情况,他们操作起来有点困难.
安全性始终是为了尽可能地破坏您的应用程序 - 考虑实现约束等.它永远不会是100%安全.因此,在不同的实现方法之间进行选择时,最佳做法是选择更难以利用的替代方案,即使差异很小.
最后,它总是要删除低悬的水果.当然,也可以操纵POST请求,但对于任何风险较高的操作,请使用POST请求并限制自己$_POST
在代码中使用.这样你已经排除了一些非常简单的GET偷渡式攻击,现在可以专注于验证你的POST数据.只是不要假设默认使用POST突然使操作安全.