Re: Looking for a reasonable explanation as to why $_REQUEST exists

Daniel Brown schreef:

On Mon, Jul 7, 2008 at 2:47 PM, mike <mike503@gmail.com> wrote:

I don't see why if you -know- you need $_COOKIE['username'] someone would be lazy and use $_REQUEST['username']

    That's the point --- it's intended as a fallback where you *don't*

know the method that will be used, or if you want to be lackadaisical with your code (which, as we all know, is HIGHLY unrecommended).

    So if you are an application service provider (ASP) who, perhaps,

runs a simple word shuffling script, with no database, email, or other externally-processed services, you may have a script like so: <?php $word = $_REQUEST['word']; echo str_shuffle($word)."<br />\n"; ?>

    Because, in this case, it really doesn't matter if $word is

obtained via GET or POST, so you can allow external users to use your service via an HTTP POST form or a plain URL.

    Conversely, it can also be used as a login mechanism or other

secure system, if you know what you're doing with regard to EGPCS

the C allow DoS attacks on clients via XXS/etc if $_REQUEST is used. imagine setting a cookie "id=CANT_USE_THIS_SITE_ANYMORE" for a webshop that has urls like "article.php?id=123" where article.php uses something like: $id = (int)$_REQUEST["id"]; $_REQUEST is borked and should not contain ECS (of EGPCS) ... at least one should be able to exclude certain superglobals without actually making not set at all, currently you can't do that .. last I looked. $_REQUEST = array_merge($_GET, $_POST); // the only sensible thing to do in all cases.

(which I mentioned to the wrong poster before! :-\) and proper secure coding techniques. It will go through a matter of precedence, which can be useful in some (rare) circumstances.

but still borked in the case of REQUEST, Stefan Esser wrote about it.