On Mon, Jul 7, 2008 at 2:55 PM, Shawn McKenzie <nospam@xxxxxxxxxxxxx> wrote: > mike wrote: > >> On 7/7/08, Eric Butera <eric.butera@xxxxxxxxx> wrote: >> >> Laziness/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 :) >> > > Well, either your sanity or your PHP is broken. Session vars are not in > $_REQUEST. The session ID may be because it might be in a cookie var which > is in $_REQUEST. > > -Shawn > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > Where I see this used a lot is in searching/pagination type scenarios...for the submission, the form is POSTED and then on subsequent pages, the data is stored in the url and posted back to the same script. Using $_REQUEST means that you won't really care about whether the data is POST or GET. -- Bastien Cat, the other other white meat
