Op 2/24/10 11:18 AM, Ashley Sheridan schreef:
> On Wed, 2010-02-24 at 07:55 +0000, Jochem Maas wrote:
>> Op 2/22/10 10:49 PM, John Black schreef:
>>> On 02/22/2010 11:42 PM, Michael Shadle wrote:
>>>> The difference here is you can at least have some control over the data
>>>> and expect it in a certain fashion. Also the behavior of cookies vs. get
>>>> vs. post are different (cookies have length and expiration limits, get
>>>> has length limits, post has server confgured limits)
>>> The cookie and post/get part is all mixed up now :)
>>> I use $_COOKIE when I want cookie information but I know that the data
>>> is not to be trusted and is easily fabricated.
>>> When reading get or post I just use $_REQUEST nowadays because I don't
>>> have to care how the submitting form is written. This makes my form
>>> handling data more portable.
>> a. if your updating/inserting/storing data for the user you should require
>> POST in order to mitigate CSRF et al - not to mention using a nonce in your 
>> forms.
>> b. when you use $_REQUEST like you do you assume it's either GET or POST 
>> data, but
>> it might be COOKIE data ... which will overwrite what is sent via GET or 
>> POST in the
>> $_REQUEST array .. which creates a potential for a denial-of-service attack 
>> on the
>> users of a site:
>> imagine an 'id' parameter for displaying articles, then imagine a
>> user was tricked into loading a cookie onto his machine for your domain with 
>> the
>> name of 'id' and a value of 1 ... said user would only ever be able to see 
>> the
>> article referred to be id=1 if you wrote code that took the 'id' parameter 
>> from the
>> $_REQUEST var.
>> ... I advocate not trusting any data *and* being explicit about the input 
>> vectors
>> on which any particular piece of data is accepted in a given context. (GET, 
>> are 3 different vectors)
> Which becomes a moot point if you use the request_order ini setting to
> specify the ordering of the overriding of variables in $_REQUEST.

which I think is another bit of magic I can do without. besides you don't
always have control of the ini file (and you obviously can't change this value
during the running of the script as $_REQUEST is already defined)

> I do see what you're getting at, and yes there are concerns to be had
> with one global array overriding another if you don't know to look out
> for such a caveat. The thing is, there are many times where $_REQUEST is
> just perfect. Imagine a stylesheet picker, that remembers the visitors
> choice in a cookie. You can utilise $_REQUEST to handle the whole thing
> very easily, and in a way that makes sense.

which would require a request_order of CPG - the opposite of what it normally 
which is a complete WTF for any new developer of the code base, all so you can
save a couple of lines of very simple code. I don't think it's worth it.

BUT given that you do know what all the ramification are and can control the
request_order in your environment then it's true to say that in your case there
is no actual problem.

> Thanks,
> Ash
> http://www.ashleysheridan.co.uk

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to