我在这里看过很多帖子说不要使用$_REQUEST变量.我通常不这样做,但有时它很方便.它出什么问题了？
从两者中获取输入$_GET并$_POST以组合方式完全没有错.事实上,这就是你几乎总想要做的事情:
对于通常通过GET提交的普通幂等请求,有可能您想要的数据量不适合URL,因此它已经变为POST请求而非实际问题.
对于具有实际效果的请求,您必须检查它是否由POST方法提交.但是这样做的方法是$_SERVER['REQUEST_METHOD']明确检查,而不是依赖于$_POSTGET的空.无论如何,如果方法是POST,您仍然可能需要从URL中获取一些查询参数.
不,问题与$_REQUEST混淆GET和POST参数无关.默认情况下,它也包括$_COOKIE.而cookie实际上并不像表单提交参数:你几乎从不想把它们视为同一个东西.
如果您不小心在您的网站上设置了与您的某个表单参数同名的cookie,那么由于cookie值会覆盖预期的参数,依赖该参数的表单将神秘地停止正常工作.如果您在同一个站点上有多个应用程序,这很容易做到,并且当您只有几个使用旧cookie的用户时,如果您不再使用旧的cookie并以不同的方式破坏表单,则可能非常难以调试 - 其他人可以重现.
您可以使用PHP 5.3中的request_order配置将此行为更改为更明智GP(不C)的顺序.如果这是不可能的,我个人会避免,如果我需要一个组合的GET + POST阵列,手动创建它.$_REQUEST
我一直在浏览PHP Internals上的一些新闻组帖子,并发现了一个关于该主题的有趣讨论.初始线程是别的事情,但此话出自Stefan Esser,如果一个(如果不是该在PHP世界)的安全专家转向使用$ _REQUEST几个职位的安全性问题的讨论.
引用Stefan Esser的PHP Internals
$ _REQUEST是PHP中最大的设计缺点之一.使用$ _REQUEST的每个应用程序很可能容易受到延迟跨站点请求伪造问题的影响.(这基本上意味着如果存在名为(年龄)的cookie,它将始终覆盖GET/POST内容,因此将执行不需要的请求)
并在以后回复同一个帖子
这不是因为有人可以伪造GET,POST; COOKIE变量.事实上,COOKIE将覆盖REQUEST中的GET和POST数据.
因此,我可以使用一个cookie来感染您的浏览器,例如action = logout,从那天开始您不再使用该应用程序,因为REQUEST [action]将永远注销(直到您手动删除cookie).
并且用COOKIE感染你是如此简单...
a)我可以在子域上的任何应用程序中使用XSS vuln
b)曾经尝试为*.co.uk或*.co.kr设置cookie单域有吗？
c)其他跨领域无论如何......如果你认为这不是一个问题那么我可以告诉你,有一个简单的可能性设置fe*.co.kr cookie导致几个PHP版本只返回白页.想象一下:只需一个cookie即可杀死*.co.kr中的所有PHP页面
通过在一个名为+ PHPSESSID = illegal的变量中对*.co.kr有效的cookie中设置非法会话ID,您仍然可以使用PHP会话在韩国使用DOS进行每个PHP应用程序的DOS ...
继续讨论更多帖子,阅读很有意思.
正如你所看到的,$ _REQUEST的主要问题不是它有来自$ _GET和$ _POST的数据,而是来自$ _COOKIE.列表中的其他人建议更改$ _REQUEST填充的顺序,例如首先填充$ _COOKIE,但这可能会导致许多其他潜在问题,例如使用会话处理.
你可以从$ _REQUEST全局中完全省略$ _COOKIES,这样它就不会被任何其他数组覆盖(事实上,你可以将它限制为它的标准内容的任意组合,比如variable_order ini设置中的PHP手册告诉我们:
variable_order设置EGPCS(Environment,Get,Post,Cookie和Server)变量解析的顺序.例如,如果variables_order设置为"SP",则PHP将创建超级全局$ _SERVER和$ _POST,但不创建$ _ENV,$ _GET和$ _COOKIE.设置为""表示不会设置超级全局.
但话又说回来,您可能还会考虑不使用$ _REQUEST,因为在PHP中您可以在自己的全局变量中访问Environment,Get,Post,Cookie和Server,并且可以减少一个攻击向量.你仍然需要清理这些数据,但是要担心这个问题要少一些.
现在您可能想知道,为什么$ _REQUEST毕竟存在以及为什么不删除它.这也是在PHP Internals上提出的.引用Rasmus Lerdorf关于为什么$ _REQUEST存在？在PHP内部
我们删除的内容越多,人们就越难以快速转移到更新,更快,更安全的PHP版本.这会让每个人感到更加沮丧,而不是一些"丑陋"的遗留功能.如果有合适的技术原因,性能或安全性,那么我们需要仔细研究它.在这种情况下,我们应该关注的不是我们是否应该删除$ _REQUEST,而是我们是否应该从中删除cookie数据.许多配置已经这样做了,包括我自己的所有配置,并且有一个强大的有效安全原因,不包括$ _REQUEST中的cookie.大多数人使用$ _REQUEST来表示GET或POST,没有意识到它也可能包含cookie,因此坏人可能会做一些cookie注入技巧并打破天真的应用程序.
无论如何,希望能够有所启发.
$_REQUEST指的是各种请求(GET,POST等).这有时很有用,但通常最好指定确切的方法($ _GET,$ _POST等).
GET请求应该是幂等的,而POST请求通常不是.这意味着,在数据$_GET和$_POST一般应该以不同的方式使用.
如果您的应用程序使用数据$_REQUEST,则GET和POST请求的行为相同,这违反了GET的幂等性.
$_REQUEST 通常被认为是有害的,因为简单到中等复杂度的数据转换通常在应用程序代码中执行而不是在SQL中声明:一些程序员很糟糕.
因此,如果一个人倾向于在$_REQUEST任何地方使用,我可以通过GET做任何事情,我可以通过POST,这意味着
然而,这是因为新手,或至少没有经验的PHP程序员犯了简单的错误.首先,知道什么类型的数据是合适的.例如,我有一个Web服务,它可以返回URLEncoding,XML或JSON中的响应.应用程序通过检查HTTP_ACCEPT标头决定如何格式化响应,但可以通过发送format参数将其强制转换为一个.
在检查format参数的内容时,它可以通过querystring或postdata发送,具体取决于多种因素,其中最重要的是调用应用程序是否希望将"&format = json"与其请求混合在一起.在这种情况下,$_REQUEST非常方便,因为它节省了我必须键入这样的东西:
$format = isset($_POST['format']) ? $_POST['format']
: (isset($_GET['format']) ? $_GET['format'] : null);
我不打算进一步絮絮叨叨,但足以说$_REQUEST使用不会被劝阻,因为它本质上是危险的 - 它只是另一种工具完全按照它的要求,无论你是否理解这些含义 - 它是一个贫穷,懒惰或缺乏经验的程序员导致这个问题的糟糕,懒惰或不知情的决定.
$_REQUEST安全使用了解您的数据:您应该对将要获得的数据类型有所期望,因此请相应地对其进行清理.数据库的数据？ addslashes()或*_escape_string().要将它显示给用户吗？htmlentities()或htmlspecialchars().期待数值数据？ is_numeric()或ctype_digit().事实上,filter_input()它的相关功能只是为了检查和清理数据而做的.始终使用这些工具.
不要直接访问用户提供的超全球数据.养成每次都清理数据的习惯,并将数据移动到清理变量,即使它只是$post_clean.或者,您可以直接在超全局中清理,但我提倡使用单独的变量的原因是因为这样做可以很容易地发现代码中的漏洞,因为任何直接指向超全局的东西而不是它的清理等效被认为是危险的错误.
知道数据的来源.从上面引用我的例子,允许通过GET或POST发送响应格式变量是完全合理的.我还允许通过任一方法发送"action"变量.但是,这些操作本身对于哪个HTTP Verb是可接受的有非常具体的要求.例如,对服务使用的数据进行更改的功能只能通过POST发送.可以响应于来自任一方法的请求来服务对某些类型的非特权或低特权数据(诸如动态生成的地图图像)的请求.
总之,请记住这个简单的规则:
我强烈推荐bobince的建议:如果可以,请将request_orderphp.ini中的参数设置为"GP"; 也就是说,没有cookie组件.在98%以上的情况下,几乎没有理性的推理,因为cookie数据几乎永远不会被认为与查询字符串或postdata相当.
PS,轶事!
我认识一个程序员,他想到了$_REQUEST一个可以简单地存储以超全局方式访问的数据的地方.重要的用户名和密码,文件路径,您为其命名并存储在其中$_REQUEST.当我告诉他变量如何表现时,他有点惊讶(虽然不幸的是,但不是很滑稽).不用说,这种做法已被废除.
这很模糊.你不真正了解数据得到了你,因为它携带后,获得和cookie数据.我不一定认为这总是坏事,除非您需要了解或限制交付方式.
京公网安备 11010802040832号 | 京ICP备19059560号-6 