On Wed, September 14, 2005 2:08 pm, Jim Moseby wrote: > Suppose you have a form that posts set hidden values. A malicious > user > could modify the URI to change those values.
Sure. Or they could save your HTML on their hard drive, edit it in their editor of choice (some of which require NO brains to drive) and then POST the modified data back to you. POST is *NOT* *NOT* *NOT* more "safe" nor less likely to be modified than GET. Well, okay, maybe the dumbest of the dumb can't figure out how to save/edit HTML... The point is that relying on POST being "safer" than the user modifying the GET paramters of a URL is just plain silly. You're putting a barrier in place that is about an eighth of an inch high. It's not much of a barrier. Meanwhile, you now have to clean *ALL* of $_GET/$_POST/$_COOKIE in three different iterative constructs. Or you could do *one* iteration and clean $_REQUEST, and ignore $_GET/$_POST/$_COOKIE > Which raises the question, in the scenario above, you may have an > identical > 'post' value and 'get' value submitted to the same page. Which takes > precidence in $_REQUEST? The precedence is CLEARLY defined in the GPC settings in php.ini! If you don't like the default precedence order, feel free to change it. Or you can accept the default precedence, which is probably the safest assumption for portable code. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
