当前位置:  开发笔记 > 编程语言 > 正文

$ _REQUEST有安全问题吗?

如何解决《$_REQUEST有安全问题吗?》经验,为你挑选了3个好方法。

我的心腹正在学习PHP,
他给我发了他的PHP代码,
我发现他在代码中使用$ _REQUEST.

我读过的教科书说
$ _REQUEST有安全问题所以
我们最好使用$ _POST.

所以我回答了心腹,
我们最好使用$ _POST.

这个可以吗?



1> Toby Hede..:

我会说将$ _POST描述为比$ _REQUEST更安全是危险的.

如果在使用数据之前未对数据进行验证和清理,则可能存在攻击向量.

简而言之: 如果没有以安全的方式处理数据,那么数据来自何处并不重要.


虽然你说的是真的,但我仍然主张从它应该来自的地方获取数据.不要跳过验证,而是要放松它.
我希望我可以更多地投票 - 来自客户端的数据永远不会被信任 - 我可以像其他任何东西一样轻易地伪造POST数据.它在地址栏中不容易看到的事实只意味着我必须拔出我的数据包嗅探器.始终验证传入的数据,并假设客户端的任何数据可能是以恶意发送的.

2> chaos..:

好吧,$_REQUEST有问题的原因是它从$_GET,, $_POST和中获取值$_COOKIE,这意味着如果你以某种方式编写代码并做出某些无效的信任 - 客户端假设,恶意用户可以通过提供值来利用它在一个不同于你预期的地方并覆盖你试图通过的那个地方.

这也意味着你可能已经给了你的心腹不正确的指示,因为它可能是他正在接受的GET或COOKIE值$_REQUEST.您需要使用您要查找的值实际显示的任何位置,不一定$_POST.


也就是说,无论如何,总是有可能正在编辑这些值中的任何一个.有很多插件可以让你动态更改Firefox的POST数据(我也假设其他浏览器).几乎任何浏览器都可以轻松更改GET和COOKIE数据.
@ Chacha102:我同意,就理想而言,但教授PHP用户使用$ _GET和$ _POST要比教他们不信任客户端更容易(地狱,甚至发生的事情)客户端和服务器上发生的事情),验证数据和操作,以及通常编写安全代码.

3> Christian Ha..:

正如在几个答案中已经提到的那样:来自客户端的任何数据都不可信任,默认情况下必须被视为恶意数据.这包括$_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突然使操作安全.


的,但使用POST进行敏感操作至少消除低垂的果实利用的另一层.
难以注入受害者的浏览器执行(取决于具体情况).显然,POST请求可以由攻击者直接生成,因此它们也不可信任,但对于攻击者正在通过第三方浏览器的情况,他们操作起来有点困难.
推荐阅读
Gbom2402851125
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有