Re: Looking for a reasonable explanation as to why $_REQUEST exists
| From: | Shawn McKenzie | Date: | Mon, 07 Jul 2008 19:16:45 +0000 |
| Subject: | Re: Looking for a reasonable explanation as to why $_REQUEST exists | ||
| References: | 1 2 3 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-276401@lists.php.net to get a copy of this message | ||
mike wrote:
On 7/7/08, Eric Butera <eric.butera@gmail.com> wrote:I do agree with your distrust of $_REQUEST though. I doubt that it will be removed as many applications probably use it. It comes down to secure coding. It is required to know where from you are getting data (post or get), because it's not valid to perform an action (other than retrieval) based upon a get request, hence the name GET. You should only perform actions (insert, update, delete, whatever) with POST (or PUT, DELETE if available). -ShawnLaziness/convenience. I always get my data from the exact source I want. If someone chooses to use REQUEST it shouldn't break their application. You say it is a security risk, but not really. As long as everything is filtered/escaped properly it should be fine because you force the data to play by your rules.I'm not talking about escaping/filtering. I'm talking about variable overriding. In the past, it was $_GET['foo'] $foo register_globals fixed that. however, if your app is relying on $_SESSION['username'] or $_COOKIE['username'] or something like that, depending on the variables order, it can be overridden. I don't see why if you -know- you need $_COOKIE['username'] someone would be lazy and use $_REQUEST['username'] It winds up allowing the end user to override information themselves (again, depending on the variables order) which depending on that and how poor the code is (which to me if you're relying on $_REQUEST you've probably got some bugs and exploitable holes in there) creates a security risk. and session vars are in $_REQUEST, I tried it to sanity check myself before posting this :)