I am new to PHP.
I have been advised to sanitize $_GET and $_POST. I have been following this advice.
However, if I just want to check the variable with
if(isset($_GET['login']))
do I need to do any sanitization on that?
Also, do I need to sanitize $_SESSION values I use?
No, you do not have to do any kind of sanitization or anything : isset() will allow you to check if the variable (or item array, in your case) exists -- and that's pretty much it.
Here, as you are testing whether the item/variable exists or not, you cannot sanitize it : to sanitize the data, you need it to exist.
Note, though : isset() will return false if that item exists, but is null !
Which, in the case of a $_GET item, will quite not probably happen.
No. If you just want to check whether variable exists or not - then your code is just fine.
No, there's no risk in doing that.
Sanitization is required before you proceed to use the values in $_GET/$_POST in your business logic (e.g. building database queries with it or displaying it to the user as part of your HTML output); here you are just testing if a value exists at all.
No, you don't. But better way to do this would be:
if(key_exists('login',$_GET)) {
}
I think there is no need for sanitation, if you need only to check if the key login is setted, it is better to doing so:
if(array_key_exists('login',$_GET))
Because if the key is not setted your code will throw a notice error.
Related
I was recently placed on a project with some PHP, and I don't know much about PHP. There are a couple instances in the site where upon clicking a button, the user is redirected to another page with some URL parameters. The next page then uses $_GET to get those parameters and move on.
Another issue in the code caused the page to reload the second page without the parameters, so using $_GET would return errors, but with the other issue fixed, I can't think of a reason why the parameters wouldn't be there.
While debugging, I came across advice to always check $_GET using isset(), but theoretically there should never be an instance when those parameters aren't there (otherwise something else is really wrong with the server or the code).
Is it still worth putting in the checks and working out a backup solution, even though there shouldn't be a need for it? I want to make sure I'm not ignoring some other potential issue that I may not be aware of.
It is always good practice+recommended to check your variables before applying any logic.
!empty() is recommended to use instead of isset() because it check both that variable is initialized and have some values too.
In case of array count($array)>0 can be used as a check.
Why to use !empty() check here:- !empty() Vs isset()
If you are expecting or requiring data to be sent via $_GET you should check if it's set. Especially since that data can be easily manipulated. Also like #Alive to Die said !empty() is better.
isset() checks if a variable has a value including ( False , 0 , or
empty string) , but not NULL. Returns TRUE if var exists; FALSE
otherwise. On the other hand the empty() function checks if the
variable has an empty value empty string , 0, NULL ,or False.
For example, if I want to use the code:
$foo = $_POST['foo']. $_GET['foo'];
to get a value whether passed by POST or GET, is this acceptable or bad practice?
Don't see anything in your answer which is to be unsetted, though you can use $_REQUEST['foo'], as that will consider $_POST as well as $_GET but again, your code will be dirty, say for example I tweaked the method value, for login form, users can easily attack your website...
So be wise, use $_GET[] and $_POST[] instead of using loose $_REQUEST[]
If for any means, you are using $_REQUEST thank make sure you use conditions to check whether the request is GET or POST using $_SERVER['REQUEST_METHOD']
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
//Do something
}
I would go with:
$foo = isset($_REQUEST['foo']) ? $_REQUEST['foo'] : null;
More at: http://php.net/manual/pt_BR/reserved.variables.request.php
to get value whether passeb by POS or GET use this
$foo = $_REQUEST['foo'];
If you configure your development server PHP to throw all warnings, you will find out.
why are you using . operator, if i am not wrong this would concatenate the result, as the above suggested using $_REQUEST would be the better approach.
Yes, it's terrible. There are two problems:
It will raise a warning
Concatenation is not suited for this use case
If you want to get a key from either $_POST, or $_GET, and you don't care which one the key is present in, you can use the $_REQUEST superglobal with the following idiom:
$var = isset($_REQUEST['foo']) ? $_REQUEST['foo'] : null;
$_REQUEST is the union of $_GET and $_POST.
I'm using Zend_Form subclasses to pass array of data to my controllers and sometimes I need some extra logic in the controllers, as such:
$post = $request->getPost();
if (array_key_exists('signatureData', $post) && !empty($post['signatureData'])) {
...
}
To avoid getting php warnings, first, I need to check if the signatureData key exists and only then I can check if the value is not empty.
Anyway I can make this IF statement a little shorter without adding custom php function?
Accepted standard :
if (isset($post['signatureData']) && !empty($post['signatureData']))
Apparently, this is also possible :
if (!empty($post['signatureData']))
-edit-
If you're really lazy, there's a dirty way :
if (#$post['signatureData'])
I'd recommend against it though.
As pointed out in the comments, don't actually use this. It's bad, bad, bad bad, bad. Really though, please don't ever use it. It's only here as a reference.
Using zf, use this
If ($request->getParam('signatureData', false))
Best practice IMO
I'm a little confused with the benefit of using filter_has_var($_POST['id']) over isset($_POST['id']).
Can Somebody please tell me if it's simply an alias function?
Not alot ;) According to the manual page for filter_has_var one user finds filter_has_var a little quicker. Also worth noting... filter_has_var isn't working on the live array ($_POST) but on the actual provided input... if you ever add/remove/update what's in that array you won't see those changes with a filter_has_var call (while isset will reflect the current state)
By the way the usage is filter_has_var(INPUT_POST,"id");
Update: Perhaps worth mentioning, filter_has_var was introduced in PHP 5.2.0 (somewhat new) while isset has been around for all of PHP4+5. Most servers keep up to date on this, but isset will always work (no one still runs PHP3 do they?)
First of all, it's not
filter_has_var($_POST['id'])
It's
filter_has_var(INPUT_POST, 'id')
Secondly, it doesn't actually query the $_POST superglobal. It analyzes the request parameter that came in with the request, so it's a better method to use in case $_POST gets dirtied in some way by the PHP script.
I think you mean filter_has_var(INPUT_POST, 'id') over isset($_POST['id']).
There is a small difference in that isset returns false if $_POST['id'] is NULL; you'd have to use key_exists('id', $_POST) to have similar behavior in that regard.
Besides that, the only difference is that filter_has_var doesn't consider modifications to the $_POST array (see this comment).
Function doesn't check live array
<?php
$_GET['a'] = 1;
echo filter_has_var(INPUT_GET, 'a') ? 'Exist' : 'Not exist';
will print Not exist
Ok I cannot remember the details on this but on some servers you can use
$var instead of $_GET['var'] to access a variable in the URL, I know this is BAD but I can't remember why it is bad?
I think you mean Register Globals.
You shouldn’t use them because you cannot distinguish the source of that variable values since they can come from any source of the EGPCS variables (Environment, GET, POST, Cookie, Server).
So if you have a the $var, you cannot say if the value is either from $_ENV['var'], $_GET['var'], $_POST['var'], $_COOKIE['var'] or $_SERVER['var'].
The feature is called Register Globals and it allows people to inject variables into your code. See the documentation for examples; here's one:
<?php
// define $authorized = true only if user is authenticated
if (authenticated_user()) {
$authorized = true;
}
// Because we didn't first initialize $authorized as false, this might be
// defined through register_globals, like from GET auth.php?authorized=1
// So, anyone can be seen as authenticated!
if ($authorized) {
include "/highly/sensitive/data.php";
}
?>
You can use that if your server has register_globals set to 1 (or true) on the php.ini file.
At some point, this started to be off by default, and applications started to break, which is a reason why this is a bad practice.
You can see a list of php.ini variables here.
It's also bad because you can confuse yourself with the way that PHP will scope your variables. You may wind up overwriting data if you aren't careful. Also, using $_GET is much clearer as to what you are attempting to accomplish.
Because letting people inject values into arbitrary variables is a very bad thing. You could be storing anything there and they could overwrite some value that compromises your security. Remember to use isset to check that a value has been set before trying to use it.
It's bad because if you're not careful to initialize every variable before you use it (something that PHP won't force you to do), people can easily cause your code to do Very Bad Things with a request as simple as /myapp/index.php?admin_privileges=1.
The setting is called REGISTER_GLOBALS and it was discussed here:
Why is REGISTER_GLOBALS so bad?
If you can do that, then "register_globals" is turned on. This is bad because you won't know where a variable came from, and it mixes your variables with the ones any user can inject via the URL. Read more here: http://www.php.net/manual/en/security.globals.php
Once you get used to using $_POST, $_GET, etc your code's purpose will be easier to read and much, much easier to maintain.
Register globals would work but it's going to go away in a future version of PHP. Not to mention that it really is wrong to have it enabled.
You can use extract() for a more controlled behavior. It will extract the keys from an array (in this case, $_GET) into the local context as variables. You can give them a common prefix so that they don't collide with your existing variables. And you can filter the array beforehand to make sure you're only getting the expected variables.
int extract( $var_array [, $type = EXTR_OVERWRITE [, $prefix ]] )
Import variables from an array into the current symbol table.