Roja : the point you make is fine IF someone uses a common library of variables.. that's IF someone uses that common variable names. In the end though, if they actually DO something like that, wouldn't you say that they are gonna be screwed no matter HOW they code? Because if they are using that kinda variable scheme, then they are going to be wide open in general.
But what you just showed was a pre-defined variable (NOT an undefined variable) that is executed. And you are also assuming that this variable is going to be used for system control usage.
In the long run, so long as someone checks to validate any information they are going to be exceuting (which is
strongly recommended by the entire php community for security purposes), they will be fine.
As for it hiding the varible, that is EXACTLY my point! If the variable names and meaning are hidden, then yes the person is secure SO LONG as they practice safe variable naming. But this is my last point on this. Even if you use a nother variable writing scheme, and even if you make your script as secure as possible, there
will be hackers out there who will want to exploit any type of security holes you have in general.
That's why you would configure apache to validate any script coming in, apply correct security measurements to your network infrastructure, and validate any/all code you are wanting to process.
IF you follow those rules, and have E_ALL turned off, you have no worries. Production sites should NOT have E_ALL turned on due to security issues in general. Testing sites that are located locally on the programmers' pc and does not effect the production websites can have E_ALL reporting turned on to test any/all code they possess.
But you need to understand, your theory of someone being hacked has a flaw due to your assumption they are using common variable naming schemes. Again, if they are doing this, they are already screwed as they have a really good chance of having a lot more worries and security vulnerablities aside from a variable name and it's purpose.
But the whole point of this conversation isn't URL passing. $_GET is used when globals are turned off. Therefore, the variable YOU are trying to argue on is a variable related to globals being turned ON! Not off! I"m talking about a variable that consists of a result. IE : a result from a table query, or a result from a file read. Or any number of other variables. If that variable (say it's $bob) is defined, we want to perform another action. If it's not assigned, we want to exit :
Code: Select all
if($bob) {
//do something
} else {
exit;
}
this is a very valid statement even if it DOES give errors when you ahve E_ALL on. But the whole point of this conversation is the fact that you should have E_ALL OFF, not ON on production sites. If you are testing, again, it's no big deal. If you are live, then it's a very big deal. I agree with you there. But you have to agree that if I name a variable $_MySQL_Result, or $_Jon_Result_to_EXPORT_HOME, what harm is there in this? I use naming schemes that are common, but common ONLY for me, not the rest of the world. But so long as we validate that variable, check it and strip it to ensure we are recieving what we want, we have no real security threat that hasn't already existed from the beginning of time.
ONLY AN IDIOT would name a variable $cmd = my_shell_command_here. And if that person uses that naming scheme, I say let him/her be hacked due to the ignorance they are performing to their coding practices.