I know $_REQUEST is bad because it contains cookie data as well.
Is it still bad to use $_REQUEST if we use some sort of clean function to it? Would someone be able to elaborate?
$_REQUEST is not specifically dangerous. Any user input can be an attack and should be treated as such. For any input medium $_GET, $_POST, $_COOKIE, use an appropriate method intval(), preg_match(), ... to verify that the value you receive is something you expect.
For example if you expect a file name and intend to send it to the user, make sure it does not contain .. or / so the user won't be able to access your filesystem.
If you want to insert a user generated value in a database, make sure you are escaping your values, using the old mysql_real_escape_string, or better PDO or mysqli prepared statements.
Related
In PHP I am creating a table where I have inserted an input box and it is named as A,B,C,D,E,.....,Z (Caps).
Now I have to fetch the data inserted in that particular input box. Is there any way I can convert string A,B,C,D,E.... into a variable?
Keep in mind the data inserted into the input box should be fetched.
Whatever is the question, you can surely use $_REQUEST["whatever"].
This is perfect for you at this stage, as data are always available with it, no matter the scope
In most cases, it is also very bad for security, as it allow special crafted xss, session cookie hijacking, sql injection, and more fun stuffs.
From my view, it is very good to play with it now, and see what are the differences with $_GET, or $_POST.
$_REQUEST This is a 'superglobal', or automatic global, variable. This
simply means that it is available in all scopes throughout a script.
There is no need to do global $variable; to access it within functions
or methods.
The variables in $_REQUEST are provided to the script via the GET,
POST, and COOKIE input mechanisms and therefore could be modified by
the remote user and cannot be trusted.
http://php.net/manual/en/reserved.variables.request.php
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.
$category = $_GET['sortBy'];
query_posts(array('order' => 'ASC', 'cat' => $category));
Is this a security risk?
Should i sanitize get?
In wordpress, this is not necessary. But always keep that in mind.
You should always sanitize data that comes from an untrusted source; since $_POST and $_GET (and $_COOKIE) data can be edited easily by the user to contain malicious code/garbage values, you should always validate their contents.
Generally, I would suggest calling mysqli_real_escape_string(), or using prepared statements at a bare minimum. However, it seems you are using WordPress, so you will want to look at the WordPress documentation to see how (and if) they sanitize the parameters passed to their query_posts() function.
Yes you should sanitize all $_POST, $_GET and $_COOKIE variables. You can make use of many different functions, one of them being mysql_real_escape_string(). You can read a lot about it on the internet. An article that might be useful for you is this one.
Other than that I'd always advise you to make use of $_POST variables because they are not visible to the user upon submitting a form. While $_GET variables are shown in the address bar (e.g.: http://www.website.com/submit.php?name=John&surname=Doe&activationkey=81sd6s1). This makes it very easy to modify for a user with bad intentions. While editing $_POST variables require a little more skills.
Wordpress santize it automatically, you do not need to worry about it here. However, in these cases, use
mysql_real_escape_string();
mysqli_real_escape_string();
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?
I'm passing PHPSESSID to a PHP page (via POST) and I was wondering what's the best way of sanitizing the input. Would mysql_real_escape_string suffice? Is there anything special I should take into account when dealing with session IDs (I mean, they can only be letters and numbers right?)?
EDIT:
To clarify the question, what I really want to know is: if someone tampers with the POST data, can he send a malicious string as PHPSESSID that would do something nasty when I call session_id($_GET['PHPSESSID'])?
I personally cannot think of any, but better safe than sorry...
Thanks
nico
Good thinking, but as far as I can see, there is no need to sanitize this input. The PHPSESSID will be passed on to session_id().
session_id indeed has some limitations:
Depending on the session handler, not all characters are allowed within the session id. For example, the file session handler only allows characters in the range a-z A-Z 0-9 , (comma) and - (minus)!
But session_id() should deal with deviations from these rules with an error message. (You may want to catch that error message and terminate the script on error.)
The only real danger that I can see is when you use a custom session handler that e.g. connects to a database. You will have to sanitize the input in that case, e.g. using mysql_real_escape_string(). However, that is something that should take place inside the custom session handler.
It goes without saying that if you use the session ID in some other context - say, as a parameter in a HTML form - you need to take the sanitation measures necessary for that specific output (In that case, htmlspecialchars()).
If you really need to pass on a session ID via POST (can´t see why really...) and you know what characters you want to allow, I would use a regular expression to check for that.
mysql_real_escape_string is for database input and requires a database connection and is not sanitizing anything, just escaping some special characters.
Would mysql_real_escape_string suffice?
Wrong. You should always sanitize data using an appropriate method to the place you are writing the value to. You'd only use mysql_real_escape_string() if/when you are writing a value to a MySQL database.
It's not clear from your comment what exactly you are doing. Do you mean you are using curl in PHP to create the POST? If so then there's no sanitization required (not strictly true - but curl does it for you) if you pass CURLOPT_POSTFIELDS as an array - but you need to urlencode the value if you are passing CURLOPT_POSTFIELDS as a string.
Are you writing the value out to the browser so the user can submit the value? In which case you'd use htmlentities() to write the value into the form field.
Something else?