Page 3 of 3
Posted: Fri Aug 10, 2007 3:46 pm
by RobertGonzalez
Why use $_REQUEST when you know your input should come from $_POST? Or from $_GET? To me it seems lazy. If you know the data is coming from $_POST, well dang it, put $_POST in the code. When you say request, you are telling the app that data can come from $_POST, $_GET, $COOKIE or $_SESSION. How many different ways can that be exploited? Does every validate SESSION data? Or cookie data?
I know (as do a lot of other developers) that all input should be filtered and validated. But not all developers think of COOKIE data and SESSION data as inputs. COOKIE data can both be spoofed, and SESSION data can easily be overlooked with the emphasis put on GET and POST data. If there is a security risk in REQUEST it is that not all members of REQUEST are filtered to the same extent, and mostly that has to do with developers that spend a lot of time validating POST/GET data, but not COOKIE/SESSION data.
It just makes sense to me that if I am accepting a form, I should check the $_POST array and accept only that. If I am accepting query string vars, then I know that I am looking only for $_GET. Same for COOKIE and SESSION. Is it really that hard to code cleanly for expected behavior?
Posted: Fri Aug 10, 2007 3:54 pm
by Benjamin
Actually, I have been working on a site lately where virtually every single page has a few variables that can either come from $_POST or $_GET, so $_REQUEST is something I have been using. Onion provided a good solution where you use $_POST before $_GET, but either way in the end the only way to tell where it's coming from is to use $_POST or $_GET.
@volka, that form would do the job. The extra layer of defense doesn't hurt though. A lot of social networking sites don't allow javascript so they are able to at least block their own members from doing damage to other profiles and such through the use of $_POST.
Posted: Fri Aug 10, 2007 4:03 pm
by volka
Everah wrote:If there is a security risk in REQUEST it is that not all members of REQUEST are filtered to the same extent, and mostly that has to do with developers that spend a lot of time validating POST/GET data, but not COOKIE/SESSION data.
This one I do not understand. If the common developer isn't able to remember four arrays to contain untrustworthy data why is a single array (and the name _REQUEST screams "user input, validate me") less preferable?
Don't get me wrong, I usually use _POST and _GET and _COOKIE and so on. But this discussion began (again) with the general notion "_REQUEST => security risk". I like to blame things for the right thing

Posted: Fri Aug 10, 2007 4:06 pm
by superdezign
volka wrote:Don't get me wrong, I usually use _POST and _GET and _COOKIE and so on. But this discussion began (again) with the general notion "_REQUEST => security risk". I like to blame things for the right thing

$_REQUEST can be
riskier than simply specifying where you accept the request from. Most of the reasons are from bad programming, but sometimes you can miss a security hole here and there.
Posted: Sat Aug 11, 2007 1:21 pm
by onion2k
volka wrote:Everah wrote:If there is a security risk in REQUEST it is that not all members of REQUEST are filtered to the same extent, and mostly that has to do with developers that spend a lot of time validating POST/GET data, but not COOKIE/SESSION data.
This one I do not understand. If the common developer isn't able to remember four arrays to contain untrustworthy data why is a single array (and the name _REQUEST screams "user input, validate me") less preferable?
Don't get me wrong, I usually use _POST and _GET and _COOKIE and so on. But this discussion began (again) with the general notion "_REQUEST => security risk". I like to blame things for the right thing

Ok, you're right. In itself $_REQUEST isn't a security risk so long as you clean up the incoming data. However, it's a bigger risk than $_GET and $_POST if you're not very experienced because it adds another level of doubt - someone who uses $_REQUEST without doing all the other things need to secure a site is opening a hole that they might not realise exists. To put that another way, using $_GET and $_POST is more secure than $_REQUEST if you're not cleaning up incoming data because you at least have 1 very, very basic check going on - that the data is coming from the expected part of the request.