You can get a signed 9″x3.81″ poster of this strip in the XKCD store

Dave’s slides on cross-site scripting (XSS) and cross-site request forging:

Mike Creuzer’s slides on SQL Injection:

Dan Day gave an impromptu demo of the Burp Suite

Thanks to Viveli for hosting this month’s event, and they’ve offered to have us back for January! See you then, and happy holidays!

SQL injection is one of the biggest security problems in the PHP world. But, it doesn’t have to be a problem.

The simplest thing you can do to prevent SQL injection is to sanitize your inputs. If you’re expecting an integer, check that the value is an integer before you plug it into your query. Some people suggest using the addslashes() function on any value you plug into a query, but that still leaves room for improvement. The mysql_real_escape_string() function provides a little better security.

An even better way to thwart SQL injection is through prepared statements. They’re supported by the MDB2 library from the PEAR project, and I’m sure many other libraries support them. A prepared statement query looks something like this:

SELECT * FROM users WHERE username = ?

When you run the query, you give the database library a list of values to match up with the ?s in the prepared statement. The library then passes those values to the database, saying “I want you to find this exact value. Don’t interpret it, just look for this value verbatim.” If someone tries SQL injection against a prepared statement, they’re just going to get 0 results back.

Sure, there’s a performance penalty for doing prepared statements, but the security benefits are well worth the overhead. You don’t want your site to be one of the “tens of thousands” infecting other people’s PCs, now, do you?

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:

1. 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']

2. 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.”;

}

3. 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.

4. 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.