This seems like a bit of a silly question, but I couldn't find a definitive answer either way and am not sure where to look.
I'm working on a new PHP code base, and have used $_GET in some places. However the person reviewing my code has stated that:
$_GET and $_POST will be phased out at some point in favour of $_REQUEST
I'm new to PHP, but this seems dubious as being able to know how URL variables were set is important for security. Is this statement correct?
Absolutely not. The person reviewing your code is not aware of the differences between $_GET, $_POST, and $_REQUEST and the implications of using $_REQUEST instead of the more specific array.
Use $_REQUEST if you have a reason to not care about the verb being used for the request. Also remember that cookies appear in $_REQUEST.
I don't think so, GET and POST are two different methods used in parameters passing. And Their usages are quite different, if you use the GET method, parameters are passed directly in the url, and you can see the parameters in your server's log, while if you use POST method, parameters are not shown in the url, and there will be no trace of parameters in the log at all.
Besides, if you are familiar with the REST, you will find more difference. GET is used to get data from the service while POST is used to create new data entry in the service.
Hope helps!
Related
I was searching where to use $_POST, $_REQUEST, $_GET but I only saw the differences among them.
The only I got to know that
$_REQUEST contains remaining two.
$_GET is used for fetching.
$_POST is used for inserting, updating, deleting.
I want to know these things
I want to know that when $_REQUEST can perform all the tasks then why there was need to create remaining two.
Explain the situations where we choose either $_REQUEST
and where we choose
$_GET or $_POST and not $_REQUEST
And what will the loss if we use use $_REQUEST instead of $_GET or $_POST
If it doesn't matter to you wether data comes in via post or via get you can use $_REQUEST. If you know which of the two will be the method data will be provided to your server-side code, use the appropriate super global. E.g. it's extremely easy to tamper with GET parameters, so you might want to avoid this method in certain parts of your application for security reasons. If you use POST you shouldn't read $_REQUEST, because there's a risk someone might add additional parameters in the URL via GET.
Which is better to use with sensitive information $_REQUEST or $_POST? I'm trying to do this as securely as possible, could anyone see the value with either functions?
If you are not using SSL, then anyone will be able to read EITHER of those with ease. If you want to send information securely, you need to consider a secure transport such as SSL / https://
Passing it through $_GET basically means sending it as part of the URL.
However, neither $_REQUEST nor $_POST are as secure. Encrypt your data before sending, and be sure to salt your passwords.
It's recommended to use post because it prevents bookmarking the url with the password in it or leaving the browser session open.
As with all security it's just a layer - even using POST you could still examine the request with a HTTP Proxy such as fiddler or look in firebug. If you want real security you should use SSL also.
As well as the points others have mentioned, using GET will mean the password will show up in log files, which isn't very secure, e.g.
GET http://example.com/login/process?email=tom#jones.com&password=its_not_unusual
Your best bet is to POST with SSL.
It is generally bad to pass important information using the query string as it very easy for a user to modify the variables passed. Post variables are not so easy to tamper with.
I have seen a website where sql statements where passed through the url, and another where php commands were passed and then executed with exec(), this is stupid beyond belief.
$_REQUEST returns as well the $_POST, the $_GET as the $_COOKIE variables. Sending passwords this way is nood a good idea. Try checking the passwords in your php and adding the active user to your $_SESSION
That's not functions used to pass something but rather arrays, used to access passed data.
POST method should be used and $_POST array to access posted data,
If I am passing some parameters in the URL is it a bad practise to retrieve them using $_REQUEST super globa as opposed to $_GET super
Well, since you expect them to be coming in as GET variables only, why use $_REQUEST and not $_GET?
The problem with $_REQUEST is that if there are variables of GET, POST and/or COOKIE, one will override the other in that superglobal. It's semi-predictable what values you end up getting if you try to access $_REQUEST.
There are several issues with using $_REQUEST.
It can be confusing to your future self and other maintainers as to where the data is coming from.
It can cause collisions, and create hard-to-find bugs in which you are getting the wrong data (because $_REQUEST covers $_GET, $_POST, and $_COOKIE).
There may be others that I don't remember right now, too.
So yes, it's bad practice.
No, it's not bad practice. The only thing is that $_REQUEST will contain values passed in GET and POST commands, and COOKIES values. So if you want to process only values passed in the URL, you will probably want to use $_GET...
It is possible to set the order of GET POST COOKIE vars in php.ini so if you have a POST or COOKIE var with the same name, the GET var won't be the active one in REQUEST.
It's really best to just use the appropriate superglobal for the type of data you're accessing.. in your case, $_GET
And otherwise you (or anyone else) don't know were the data came from when using $_REQUEST
One benefit to $_GET and $_POST are that you know exactly how your script received the parameters. It also keeps them in separate namespaces, so that $_GET['foo'] will always be distinct from $_POST['foo'], which $_REQUEST does not do.
In the end, it is a design choice that is up to you, but one day down the road, you'll look back and be glad that you used $_GET instead of $_REQUEST (unless you had a specific reason not to). One thing to remember though, as always: $_GET, $_POST and $_REQUEST all possibly contain user-manipulated data, and so SHOULD NOT be trusted. Always sanitize!
It's usually not a problem. Typically you want to hava a form/API accessible with any method. Then $_REQUEST is the best choice. You should differentiate on the functionality. If an access modifies data, then make it dependend on $_POST. If an access is strictly for querying, then force it to use $_GET only.
There are security implications of using $_REQUEST (the cookies fixation issue), but they are usually blown out of proportion. It's outdated for current PHP configurations anyway. So with a grain of salt - there were a few former discussions to the topic:
What's wrong with using $_REQUEST[]?
Why should I use $_GET and $_POST instead of $_REQUEST?
Does $_REQUEST have security problem?
So, I've been coding for a little (2 years), and I have a very subjective question:
Is it wrong to use $_REQUEST for Data?
This mainly pertains to authentication by the way.
If you think about the 3 ways data can occur in $_REQUEST, it can come from either a cookie, a form, or a query string. Now, I know that most people directly grab the information from either $_POST or $_GET, using $_COOKIE only when they are expecting a cookie.
My theory is that in reality, there shouldn't be any difference in this data, and it shouldn't make any difference if you replaced $_POST or $_GET with $_REQUEST.
If you are authenticating a user into the system, does it really mattered if the authentication details are contained in the $_POST or $_GET array? Heck, it probably shouldn't matter if they are in $_COOKIE either. They are still giving you credentials to log into the site, which you should check for correctness, and if so log them in.
Now, I do realize there are security issues if you try to have a login form that submits data via a query string, but I don't believe that pertains to the question. Also, if someone fails a login too many times, there should be proper limits set in place to avoid overloading the server.
I'd like to here the opinion about this.
Community Wiki'd for good measure.
Oh, and just by the way, here are other StackOverflow questions that relate if you have other questions about $_REQUEST
Why should I use $_GET and $_POST instead of $_REQUEST?
When and why should $_REQUEST be used instead of $_GET / $_POST / $_COOKIE?
In "good" coding practice, you want to disambiguate as much as possible.
Since $_REQUEST contains the data from $_POST, $_GET, and $_COOKIE by default, the value held by the variable that stores the data retrieved using $_REQUEST will be ambiguous as to which method it came from.
If we are more specific, it will benefit readability of code, as well as understanding of logic, and helps for debugging in the future.
(Let alone the security issues concerning each method, especially the $_GET one)
I'd say avoid it all together. I agree with Sev that disambiguation is important for many reasons (debugging, clarity/self-documentation, elegance, etc.), but there are significant security issues that could arise, and that would be my main reason for avoiding it.
As a simple example, what happens when the same key is sent in two of the arrays (e.g. $_POST['criticalInfo'] and $_GET['criticalInfo'])? As with most security issues, the vulnerabilities present themselves in the individual implementation, so it would be impossible to guess your specific risks. The fact is that ambiguity often opens up holes.
Don't leave it up to "variables_order" in PHP_INI to determine where your script gets variables from. Use $_GET, $_POST, etc.
It is also about not letting credentials come in any other way than a POST request. I would not want my GET request to have side-effects (like logging in the user).
Is it wrong? No.
Is it inferior to $_GET or $_POST? Yes. Use the right array and you'll avoid all kinds of problems that stem from not knowing where the array contents of $_REQUEST came from.
I have a form a user can enter their name, then it will add it to $message to be sent in an email.
Is it better to use $_POST or $_REQUEST?
Here is a snippet of using $_REQUEST
$message.= "Name: ".$_REQUEST["fname"]." ".$_REQUEST["mname"]." ".$_REQUEST["lname"]."\n";
My approach used to be to use $_REQUEST for everything which I think is a big mistake. Lately, I've been trying to be more diligent about using GET only for read-requests & POST only for write-requests.
To that end, I think using $_GET for GET requests & $_POST for POST requests makes my intent much more clear in my code.
The answer is: It depends on how you want it to be used.
If you're using $_POST, that means it can only come in via POST.
If you're using $_REQUEST, that means you accept POST, GET (and COOKIE, but it's mainly the first two we're interested in).
For something like this, $_POST would probably be neater, but if you were making a search engine, allowing to set up a search URL would probably be a good idea. However, you might want to allow for a ton of special parameters to narrow down the search, and if that can take up a lot of URL space, you'll probably want to allow POSTDATA as well.
As Dylan mentions, keep in mind that neither is a replacement for any kind of security.
doesn't matter which one you use. just make sure you use some form of security with forms.
I just listened to Security Now episode #166 which was all about cross-site request forgery, and in it, Steve makes a good case for using $_POST for forms rather than $_REQUEST. (Indirectly, he doesn't talk about PHP itself, but does say that you shouldn't accept both GET and POST for forms.) The reason is that it's easy to use GET requests for CSRF attacks but not so easy to use POST.
Using $_POST itself doesn't eliminate the possibility of CSRF attacks, but it does reduce it. Steve also suggests using a cryptographically strong pseudo-random hidden field in the request that will eliminate the possibility of "blind" requests.
_POST if data is being updated somewhere (i.e. if the action has a side-effect), _REQUEST otherwise, and if you don't care whether or not the data comes via GET, POST, or any other method.
Unless you have a good reason to do otherwise (such as the search engine mentioned by Michael), it's probably better to use $_GET and $_POST for their respective methods instead of $_REQUEST, to avoid any ambiguity or confusion over possibly having the same argument name in the GET and POST data.
The only time I use $_REQUEST is when I need to be able to support data from either $_POST or $_GET.
For example, if I have a form that's supposed to modify a record, I might initially pass the record ID in the url as id=X. So when first loading the form, I could use $_GET['id'] to figure out what record we're trying to modify.
However, when submitting the modify operation, the form should be POSTed, since it will be changing data and is not idempotent. In this case, the record ID would be accessible as $_POST['id'] when processing the form submission.
But what happens if there's an error in the form submission and I need to reload the form with a helpful error message? In this case, the form generation code needs to figure out what record to use by looking at the POSTed id, which is not in the URL.
In cases like this, I would use $_REQUEST['id'] in the form display logic, so that it could support either scenario. But for form processing, I would use $_POST['id'] for strict checking.