register_globals
Christian’s presentation from August:
Register Globals
Why are webhosts paranoid and turn register_globals off? PHP version 4.2 and later comes with register_globals turned off by default and rumor has it that PHP 6 does not even support register_globals.
What is register_globals and how does it work?
URL: http://www.yourdomain.com/index.php?id=1
Will result in $id=1 inside the requested script if register_globals are turned on. Seems okay but what if the URL is http://www.yourdomain.com/index.php?useraccess=admin
Oops, we may have just bypassed this script
if($username == “techguy”) && ($password == “somethingdifficulttoguess”) {
$useraccess = “admin”;
}
if($useraccess == “admin”) {
And we are going straight to:
echo $all_our_confidential_data;
} else {
Echo “Hello Guest! Isn’t the weather nice today?!”;
}
Ever wondered how banned or unapproved members are able to post Viagra ads on your philately message board. That’s how. Use a popular open source script and spammers know exactly how it is coded (everyone has access to the source code because it’s a free download) and they know which variables to inject in order to bypass your message boards’ ‘new member approval’ process. This also works for formmail scripts, shopping carts, voting applications, etc.
Still think your server administrator has watched one too many episodes of XFiles? How about http://www.yourdomain.com/index.php?sql=DELETE * FROM \’records\’
Ah, I thought I’d get your attention eventually.
Although, it might be a bit of a hassle to make your scripts work with register_globals off but, believe me, you will lose less hair fixing your scripts than while having to explain to your client why a few thousand credit card numbers were stolen and then their customer database deleted. If you have found a way to explain this to your clients without them hiring a hit man on you, please share it with the rest of us because even the most security-conscious of us programmers don’t always practice what they preach.
Okay, let’s see how our lives and that of our families shall remain reasonably safe:
-
specify all variables you receive through user input, sessions, or cookies by amending REQUEST:
If you are expecting a telephone number as submitted variable change $telephone_number to $_REQUEST['telephone_number']
-
set any variable to a default value before running any functions:
$telephone = 0;
if (isset($_REQUEST['telephone_number']) != 0) {
echo “alright. I’ll call you.”;
} else {
echo “Don’t be shy, I’m not a stalker … anymore.”;
}
-
to secure your script even more, specify, where you want the variable to come from. $_REQUEST covers GET, POST, COOKIE, SESSION, ENVIRONMENT. Narrow it down to the specific superglobal like $_GET, $_POST, $_COOKIE, $_SESSION, and $_ENV instead of the generic superglobal $_REQUEST and you’ll sleep even tighter at night. This way you make sure that a session variable cannot be injected via GET or POST. You get the idea.
-
now that your scripts are ready run with register_globals turned off, make sure they are indeed turned off (if your server administrator is reluctant to do it, do it yourself by posting php.ini files with register_globals turned off into each vulnerable directory and ask your server administrators if they can spell CODE INJECTION).
Btw., the php.ini file also works the other way around, so if sky diving and bungee jumping are not enough adrenaline, go on and live on the wild side and override the server settings by turning register_globals back on in your own php.ini file but have your escape plan ready in case your clients remember who coded their application.
Also, try to rename some of the more popular filenames like formmail.pl to something spambots are less likely to look for: lovelyquilts.pl
Change any e-mail address listed on a website in plain form into hex code (e-mail riddler) because e-mail harvesters don’t yet see a pattern in that. If you properly code your form processing script (hard code the recipients e-mail address in it or go through a database to verify valid recipient addresses), there is no need for having a hidden recipient field in your form and thereby revealing the recipient’s e-mail address in the html source code.
Oh yeah, register_globals was the topic … Just turn them off and make the Internet a better place.
Loading ...
