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?
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.
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!
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.
The textbook I read says that $_REQUEST has security problem so we better use $_POST.
Is this OK?
I would say that it is dangerous to characterise $_POST as more secure than $_REQUEST.
If the data is not being validated and sanitized before being used, you have a possible vector of attack.
In short:
It doesn't matter where the data comes from if it is not being handled in a secure manner.
Well, the reason that $_REQUEST has issues is that it picks up values from $_GET, $_POST, and $_COOKIE, which means that if you code things certain ways and make certain invalid trusting-the-client assumptions, a malicious user could take advantage of that by supplying a value in a different place than you expected and overriding the one you were trying to pass.
This also means that you may have given your henchman incorrect instructions, because it may have been a GET or COOKIE value that he was picking up from $_REQUEST. You would need to use whatever place the value you're looking for actually shows up, not necessarily $_POST.
As was mentioned already in several answers: Any data coming from the client cannot be trusted and must be treated as being malicious by default. This includes $_POST, $_GET, $_COOKIE and $_REQUEST (the combination of the former) but others as well.
When talking about some of them being more dangerous than others I would indeed separate $_GET and $_REQUEST (as it includes $_GET) out from $_POST, as it is slightly harder to generate, i.e. manipulate, a POST request than a GET request. The emphasis here is slightly, but using POST for sensitive operations at least removes another layer of low hanging fruits to exploit.
Especially when it comes to Cross Site Scripting (or XSS) and cookie theft, it is rather easy to get a victim's browser to issue a GET request to the server under attack by simply inserting a hidden image with a manipulated URL into a page or forging a link.
Issuing a POST request at least requires some JavaScript, which is slightly harder to inject into the victim's browser for execution (depending on the situation). Obviously POST requests can be generated by attackers directly, so they can't be trusted either, but for scenarios where an attacker is going through a 3rd party browser, they are a little bit harder to manipulate.
Security is always about making it as hard as possible to break your application - taking implementation constraints etc. into account. It can never be about being 100% secure. So it's best practise to choose the alternative which is more difficult to exploit, even if the difference is marginal, when having the choice between different implementation approaches.
In the end it is always about removing low hanging fruits. Sure, POST requests can be manipulated as well, but for any operation that has an elevated risk, use a POST request and restrict yourself to using $_POST in your code. That way you have have already excluded some very easy GET drive-by attacks and can now focus on validating your POST data. Just don't assume that using POST suddenly made the operation safe by default.
It's certainly okay to tell people to use $_POST instead of $_REQUEST. It is always better to be more sure about where your getting your data.
#Christian:
When talking about some of them being more dangerous than others I would indeed separate $_GET and $_REQUEST (as it includes $_GET) out from $_POST, as it is slightly harder to generate, i.e. manipulate, a POST request than a GET request. The emphasis here is slightly, but using POST for sensitive operations at least removes another layer of low hanging fruits to exploit.
Bzzt. Sorry, but this just ain't true.
Anybody who understands the difference between GET and POST or how unsanitized inputs might be exploitable, won't hesitate for a second to fire up Tamper Data.
Some people have it right here: there is NO security lost or gained by using $_REQUEST in a well-designed system.
There's no real security difference between using $_POST and $_REQUEST, you should sanitise the data with equal scrutiny.
The biggest problem with $_REQUEST is you may be trying to get data from a POST'd form, but might have a GET parameter with the same name. Where will the data come from? It's best to explicitly request the data from where you expect it, $_POST in that example
There are slight security benefits - it's easier to perform XSS (more specifically XSRF) attacks on GET parameters, which is possible if you use $_REQUEST, when you really just want POST data..
There's very few situations when you need data either from POST, GET or cookie.. If you want to get POST data, use $_POST, if you want to get data from from GET parameters, use $_GET, if you want cookie data, use $_COOKIE
The most secure way is to verify and validate the data. I usually generate a random unique id for a form and store it in the user's session, but this is easily bypassed by a determined attacker. Much better is to clean up all incoming data. Check out htmlspecialchars() and its related function. I also use a third party utility for cross-site, like HTML Purfier
On some practical notes, always use intval() what is supposed to be numeric, escape all incoming strings, use regex for phone numbers, emails or anything that is going to be part of a SQL query.
Hope this helps.
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.