"Jim Moseby" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > >> (snipped) >> "Ben" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> > Gustav Wiberg wrote: >> >> if (isset($_REQUEST["frmUsername"])) { >> >> >> >> $un = $_REQUEST["frmUsername"]; >> > >> > If you're going to use $_REQUEST you might as well just >> turn on register >> > globals (no, don't!). >> > >> > If you're expecting a post look for a $_POST, if you're >> expecting a get >> > look for a $_GET. Ditto with cookies. You really need to >> know where your >> > variables are coming from if you want a measure of security. >> >> Why is using $_REQUEST a security issue? You know every >> value in the entire >> array came from the end-user, and needs to be validated >> somehow. If your >> code is written so the end-user can send this data to you via a >> POST/GET/COOKIE, why not use $_REQUEST? > > Suppose you have a form that posts set hidden values. A malicious user > could modify the URI to change those values. > > 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?
Interesting idea. But, a malicious user would probably send a POST, with the modified hidden values. Using $_REQUEST may make it easier for them to alter the values, but your php page needs to handle the possibility of modified values anyway. IF you have the identical POST and GET value-names, you will need to use $_GET and $_POST to identify them. But, this isn't a security issue, more of a coding-style issue. So, I still don't see a security problem -- unless I misunderstood the "modified hidden post values" issue. DanB -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
