$_POST vs $_REQUEST
in [General]
|
From: tedd on 23 Feb 2010 09:58 At 11:07 PM +0100 2/22/10, John Black wrote: >On 02/22/2010 10:37 PM, Michael Shadle wrote: >>On Mon, Feb 22, 2010 at 1:30 PM, David >>Murphy<david(a)icewatermedia.com> wrote: >>>Richard, >>>The use of $_REQUEST it no more a security hole than $_GET or $_REQUEST, >>>they should ALL be treats as bad data until normalized and sanitized. The >>>claim that it opens a security hole is just false, that's like saying PHP >>>is insecure, its not it just allows for lazy coding such as $_REQUEST. > >>It represents a way for people to exploit coders who don't know any better. >>Expecting a cookie value to come through in $_REQUEST but you could >>override using a query string parameter makes for easy exploitation. > >And how is this more secure? I can create a cookie, send post or get >on my client machine and send anything I want to the server. Just >because you are getting a cookie does not mean that you created it :) > >So you might as well use request because the data can not be trusted >either way. > >-- >John It is true that you cannot trust any data coming from a client (i.e., POST, GET, COOKIE, REQUEST, Whatever). However, in trying to secure what you are doing it makes sense to know specifically the origin of your data. Additionally, if you know specifically where your data is coming from, then there are no surprises as there can be by using REQUEST. I am sure you realize that the data provided by a REQUEST can be overridden by processes you may have not accounted for. For example, while you are thinking that the data you're working on was provided by one super global it actually was overridden by another can lead to problems, including security. One security directive is to keep the process simple and under control. The more complicated you make it, the less secure it becomes regardless of the method of data collection. Cheers, tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.com
From: Jochem Maas on 23 Feb 2010 20:07 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(a)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 > > >
From: Jochem Maas on 24 Feb 2010 02:55 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, POST and COOKIE are 3 different vectors)
From: Ashley Sheridan on 24 Feb 2010 05:18 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, POST and COOKIE > 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. 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. Thanks, Ash http://www.ashleysheridan.co.uk
From: Rene Veerman on 24 Feb 2010 06:34
sry i gotta disagree. a function that queries $_POST/$_GET first and then $_COOKIE seems much wiser to me. it consolidates all logic in the script, and making that logic obvious by syntax, rather than relying on functionality being determined by php.ini, which could well cause a new developer to lose heaps of time if he/she has to work on it.. On Wed, Feb 24, 2010 at 11:18 AM, Ashley Sheridan <ash(a)ashleysheridan.co.uk> wrote: > 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, POST and COOKIE >> 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. > > 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. > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > > |