Page 2 of 2
Re: Access form elements' properties in PHP
Posted: Sun Sep 07, 2008 4:21 pm
by marcth
Everah wrote:marcth wrote:I guess I'm going to have to start using a hidden variable called formAction--I really don't want to distinguish between get and post variables.
You should always distinguish between your superglobals. It makes for clean, maintainable, readable code later on. If you know it is coming from POST use POST, if it is coming from GET use that.
I would not use REQUEST (yes, that is a bit of a holy war around here... search and you will find all sorts of opinions about it) because PHP sets a precedent order on REQUEST, one that is tested in the code I posted above.
I can't agree with that--you proved me wrong once, so lets see if you can't do it again!
Thesis: Accessing HTTP request variables via the the REQUEST scope is easier and makes for more readable than accessing user-supplied data via the GET and POST scopes.
Assumptions: Submitting a GET and POST variables of the same name in one request is confusing and makes for unreadable code. For example:
Code: Select all
<form action="index.php?id=1">
<input type="hidden" name="id" value="2" />
</form>
Arguments:
- Request variables submitted via POST is just as insecure as data submitted via GET (or via a cookie for that matter)--one cannot be trusted more than the other.
- Accessing user data from one single source (REQUEST) is simpler than accessing it from multiple sources (GET, POST).
- Your views can be refactored to submit GET variables as POST variables and vice versa (should the need arise) without having to worry about the server-side scripts.
- Users can bypass your interface (ie form) and submit data directly via the URL (Think: sending a partially completed from via email as a practical example).
- [Edit] Forms submitted via Ajax may not be submitted via GET
Is any of this thinking flawed? What are the advantages of separating HTTP request variables by the way in which they are sent?
Re: Access form elements' properties in PHP
Posted: Mon Sep 08, 2008 12:37 pm
by RobertGonzalez
Yes, cookies and sessions live in the REQUEST array as well. That means that I can set a request var to anything I want to by manipulating cookies or session data.
I would agree on many of your points. I will never say that GET|POST is more secure than request. You must still validate, sanitize and filter your inputs and outputs. But using REQUEST means now that you have four separate layers of data that you must contend with (and so must any maintainers of the code later down the road).
If you know something is coming from GET and you tell your app that in the code, then nothing that gets passed to POST, COOKIE or SESSION will ever come in to play against what you have coded. Maintainers will also know when they see GET that there must be a querystring involved somewhere. The request method then comes into play. It is not necessarily more secure, but is certainly less prone to lapse of coverage since you are dealing with one known entity instead of four possible entities that may or may not be known.
I know the whole REQUEST vs GET|POST|COOKIE|SESSION discussion has come in to play before around here. Each has its own place. In my opinion, and this is only opinion, using REQUEST is akin to user register_globals without the extract part of it taking place. I will always know when my app is expecting POST or GET or COOKIE or SESSION and I personally will always code my apps for that.
Re: Access form elements' properties in PHP
Posted: Mon Sep 08, 2008 2:56 pm
by marcth
Everah wrote:Yes, cookies and sessions live in the REQUEST array as well. That means that I can set a request var to anything I want to by manipulating cookies or session data.
I would agree on many of your points. I will never say that GET|POST is more secure than request. You must still validate, sanitize and filter your inputs and outputs. But using REQUEST means now that you have four separate layers of data that you must contend with (and so must any maintainers of the code later down the road).
If you know something is coming from GET and you tell your app that in the code, then nothing that gets passed to POST, COOKIE or SESSION will ever come in to play against what you have coded. Maintainers will also know when they see GET that there must be a querystring involved somewhere. The request method then comes into play. It is not necessarily more secure, but is certainly less prone to lapse of coverage since you are dealing with one known entity instead of four possible entities that may or may not be known.
I know the whole REQUEST vs GET|POST|COOKIE|SESSION discussion has come in to play before around here. Each has its own place. In my opinion, and this is only opinion, using REQUEST is akin to user register_globals without the extract part of it taking place. I will always know when my app is expecting POST or GET or COOKIE or SESSION and I personally will always code my apps for that.
The $_REQUEST super global doesn't contain session data--only HTTP request variables. It's an "associative array that by default contains the contents of $_GET, $_POST and $_COOKIE".
I don't understand what is the benefit of accessing GET variables via the $_GET super global and POST variables via the $_POST super global. Why is it important to keep track of how the variable was submitted?
Re: Access form elements' properties in PHP
Posted: Mon Sep 08, 2008 6:38 pm
by Luke
I'd do this...
Code: Select all
function is_post() {
return ($_SERVER['REQUEST_METHOD'] == 'POST');
}
I think that's what zend framework's $request->isPost() does.
Re: Access form elements' properties in PHP
Posted: Mon Sep 08, 2008 7:34 pm
by Stryks
marcth wrote:I don't understand what is the benefit of accessing GET variables via the $_GET super global and POST variables via the $_POST super global. Why is it important to keep track of how the variable was submitted?
To my mind, the answer is in your comment. It's good practice to keep them separate because they ARE separate, and one solution doesn't fit all. I mean, for many forms on my site, I use a form token to ensure that form submissions are actually coming from my forms (see CSRF attacks). I do this because I don't want to allow spoofed form submissions, which is exactly what using the $_REQUEST checking does. It opens an easily accessible route for a (malicious) user to bypass my forms and bounce requests at my form handlers.
That said, there are definitely times where you will want to be able to put a link up somewhere that simulates a form submission (a search form comes to mind).
The thing is, while one is as (un)safe as the other, they are from different sources. If you're expecting a form submission, why open up an avenue for GET values to be sent instead? You're expecting a form, so just check POST. If you want to allow GET variables to simulate forms, then set up a method to *specifically* allow this.
Using REQUEST just seems to take the control away from me to specify where the data I am after is coming from.
But I think this is just one of those subjects that depends on the way you look at it. It will *work* either way, so there is probably no definitive right answer, but in my opinion specifying the source provides clarity and control with no real cost apart from a little more typing here and there.
Anyhow .. food for thought.