RE: [PHP] Re: trying to figure out the best/efficient way to tell whois logged into a site..
(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?
JM
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: trying to figure out the best/efficient way to tell whois logged into a site..
Suppose you have a form that posts set hidden values. A malicious user could modify the URI to change those values. A malicious user could just as easily modify the http header that sets the POST, or the cookie that sets the COOKIE, or whatever. In other words, if it comes from the user, it could have been tampered with. 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? That is configurable in php.ini (I think). By default, COOKIE overwrites POST overwrites GET. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: trying to figure out the best/efficient way to tell whois logged into a site..
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
Re: [PHP] Re: trying to figure out the best/efficient way to tell whois logged into a site..
On Wed, September 14, 2005 1:57 pm, Dan Baker wrote: (snipped) If you're going to use $_REQUEST you might as well just turn on register globals (no, don't!). More mis-information. $_REQUEST is simply the array_merge() of $_GET, $_POST, and $_COOKIE. You either check the contents of any of those 4 $_ variables for what variables you expect. Or you don't check the keys, in which case you might as well have register_globals on because you *ARE* initializing your un-initialized script variables with whatever comes in from the outside world. But it really does NOT matter that you assume all of $_REQUEST is equally suspect, and validate that, and use it, instead of doing GET/POST separately. Or, at least, not in terms of register_globals being on/off. If you are using the same variable in both GET and POST in one request, yeah, you need to look into both to get the two values. But that's usually a Bad Idea, since it's too confusing to get the same variable in both at once. But, really, the user over-writing GET data with POST data (or vice versa) is a non-issue. The malicious user can just as easily over-write POST data with whatever POST data they want to send you in the first place! register_globals is all about the user providing default values for un-initialized variables. It's got NOTHING to do with GET versus POST data being more/less suspect , or GET/POST over-writing POST/GET 99.9% of the people who insist on using GET/POST instead of REQUEST mistakenly believe that POST is more secure than GET. They're wrong on that score. There may be OTHER reasons to use GET/POST, if only to be clear on where you expect the data to come from in the other parts of the application, but it's not about security It can't be about Security because POST and GET are equally easy to forge and send in, so any Security measure based on them being different is flawed, by definition. -- 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
