Re: $_POST vs $_REQUEST
| From: | Jochem Maas | Date: | Wed, 24 Feb 2010 01:07:18 +0000 |
| Subject: | Re: $_POST vs $_REQUEST | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-302326@lists.php.net to get a copy of this message | ||
Op 2/23/10 10:27 AM, Ashley Sheridan schreef:
> On Tue, 2010-02-23 at 09:19 +0000, Richard wrote:
>
>> Hi,
>>
>> Well people better than me (how is that possible?!) have said that
>> $_REQUEST has the potential to open your app up to security
>> vulnerabilities, and that it should be avoided because of that. Here's
>> a post from Stephan Esser about it on the PHP-Internals list:
>>
>>
>> http://www.mail-archive.com/internals@lists.php.net/msg32832.html
>>
>> Stephan heads up the Hardened-PHP project and when it comes to
>> security, I don't know of anyone better. So, if he advises not to use
>> _REQUEST, it's a good idea to follow that advice.
>>
>> --
>> Richard Heyes
>>
>
>
> Well, he's only saying there that it 'most probably vulnerable' and
> mentions that cookies can overwrite post and get data. This isn't a
> problem with $_REQUEST itself but rather an applications' use of it. So
> what if someone crafts a cookie to send a bad value. If someone has the
> gen to do that, then they are going to know how to send get and post
> values as well. Only decent sanitisation will be able to protect against
> this.
>
> If the order of override variables in $_REQUEST is such an issue too,
> use the request_order ini setting to specify the order you'd prefer.
>
> I've never had any issues with using $_REQUEST, but found a lot of
> advantages to using it, as I often use a mix of data sources in the same
> app.
and that is exactly Essers point. you use $_REQUEST and assume the data came
from either GET or POST ... I'd hazard a guess your apps never expect such 'mixed'
data to be coming via COOKIE ... so your app will work as 'advertised' but if some
one happens to slip a cookie onto someone else machine whose name matches some
rather important GET/POST input then it's that user who potentially has just suffered
a denial of service - and you'll get the blame for the fact things don't work and
you'll probably never be able to work out that it's a rogue cookie on the client putting
a spanner in the works. (imagine you have an 'id' parameter and I managed to set a
cookie on your users' machine called 'id' with a value of 1 ... have fun with that)
you should be as strict with exceptable input vectors as you are with sanitisation
of the actual input.
use of $_REQUEST is rather lazy - if you want to except either POST or GET for a given
input write a simple wrapper function for that specific requirement - this will also
save you from unforeseen problems related to incorrect or changed values for the
request_order ini setting.
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>