For example, if one of your variables is $address. I don’t know what the risk is here. I would prefer my code be readable (for my own sake) and that variable names be as simple as possible.
Generally no - while obscurity (in this case making hard to guess variable names) can be used as an additional hurdle for potential attacker, one should not rely on it as a means of security protection.
In context of variable naming - the benefits of having readable code far outweigh the benefits of obscurity.
Thanks
Yes, I agree with you. Knowing the name of the variable does not lead to any security issues. But knowing the database information such table names, field names and so on, are dangerous can be injected easily(SQL Injection) if you coding is not secure.
Sorry, I cannot understand what you mean. Can you please explain in detail.
You mean possibility of security issues is high because of making the register_globals ON. Please explain.
Did you read the page I linked to? It’s explained there.
Yes, I did visit, But i cannot understand and it is first time that i’m hearing register_globals. Actually i’m new to php and started to learn just 2 months before. I don’t have deep knowledge on it. I think i’ve to refer more to understand that. At present what i understand from that is, it is like a global variable that can be ON or OFF. Thanks anyway. I’ll try to understand by referring more. If you can tell in simple words, then yes you can.
Thanks in advance.
in simple words:
if register_globals is on, then accessing page page.php?variable=value
automatically creates $variable as well as $_GET[‘variable’] and $_REQUEST[‘variable’]
on other hand, if register_globals is off the same would only generate:
$_GET[‘variable’] $_REQUEST[‘variable’]
so if your code were:
if($authenticated){//$authenticated gets set at some point by access control code.
//do authenticated stuff
}
then this logic could be exploited by person specifying page.php?authenticated=true
Also - good points on register_globals and table/field names - however it certainly would be poor coding if knowing them would mean that something could be exploited. Obscurity buys you time and rings warning bells (by appearing of unsuccessful guesswork tries in log files) and should not be overlooked, but taken to advantage.
In summary: Your security should not rely on these things being unknown, however it also means that you should not be “advertising” all your variable/file/table/field names to world.
Let’s take the first example from the page I linked to:
<?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";
}
?>
Now I could go use the query string to send a variable $authorized to your script:
http://www.yoursite.com/index.php?authorized=1
With register_globals OFF, that would have no effect, because the value I put in the query string would be only accessible through $_GET[‘authorized’].
With register_globals ON, php automatically creates a variable called $authorized with value 1. Which means that even if I didn’t authenticate, $authorized still has value 1, which means it will enter the second if and display the highly sensitive info.
Fine, Got some idea. Thanks Aleksejs and guido
People should be initializing their variables properly in the first place and it would be a none issue, but that said I agree – register globals is evil!
<?php
$authorized = false; // always assume person is not authorized
// 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";
}
?>
Of course. But without register globals its a none issue even if you forget to initialise one (which could happen since PHP doesn’t force you to).
but that said I agree – register globals is evil!
Indeed :devil:
As long as you intitialize, validate and clean you are good. Don’t worry learning about register globals, just initialize right like so:
if (empty($_POST['foobar'])) {
die('Go back and get some foobar!');
} else {
$foobar = trim(htmlspecialchars(strip_tags($_POST['foobar'])));
}
echo $foobar;
If that varaible is being used with a SQL query be sure to use at minimum, mysql_real_escape_string(). Don’t use addslashes()… ever.
Also see: http://php.net/manual/en/book.filter.php
If you don’t know about register globals it’s likely turned off on your server. PHP 5.4 will be removing the functionality for good.
Off Topic:
Standing ovation for PHP 5.4! :eyebrow: