Usually if I don’t have the time to review a script I advise people to Google for security issues. Except, with the recent problem surrounding the false reports of a login issue with my scripts, it’s becoming more and more apparent that we can’t rely on only Google. Amongst good advice (of which there is plenty) are empty listings for scripts that aren’t popular enough to be hacked about or scripts that have been incorrectly listed by people who can’t tell the difference between a function and a fart. Here are the first five steps in a new guide (to fit alongside my PHP Beginners guide, of which I’m writing Part 3) that will help you execute some basic “attacks” so you can make an educated decision for yourself.
Note: if you’re testing a script but don’t have a local copy of apache or equivalent web server installed, create a directory on your host that nobody is likely to find during the testing. Be warned though, if a vigilant host thinks something funky is going on with your account they may suspend you.
Turn off register_globals
Most hosts disable it by default these days, but if you know that your’s doesn’t you can turn it off in the .htaccess file with
php_flag register_globals off. If that plays havoc with your script or disables some functionality, it’s just not worth having.
Fill Forms with Crap
Manipulate the URL
A lot of scripts have pagination but assume users won’t fiddle with the numbers — try replacing things like page=2 with page=random%20gibberish — although this may not do any out and out damage with a few odd words, it may cause MySQL errors which can deliver sensitive data back to the user (which won’t always be you!) If the script relies on what’s commonly known as “dynamic navigation” — i.e. it uses URLs like page=about.php — replace about.php with a URL to a few sites… you might find that the script is not validating against such a basic form of cross-site scripting either.
Spam a Few Friends
Test out e-mail forms by filling fields (usually the “e-mail” field is most abused) with basic header injection like
> CC: email@example.com, firstname.lastname@example.org etc — if they get some funny e-mails from you, it’s highly likely that other people would too if you made that script public. Of course, any decent script would validate against this but there are a lot that still don’t.
Upload a Virus
So, the chances are high you won’t have a virus on your system (deliberately, anyway) but there’s no reason why you can’t pretend. If your script allows user upload try it out by uploading a file with an extension that you don’t want on your website — a .exe or an .mp3 — and if that doesn’t work, get sneaky and rename a new text file document to image.jpg and try that. Sometimes script writers only check extensions and that’s simply not enough.
Of course the best advice for anyone looking for new website scripts is to use their common sense. How big is the community that surrounds the script? How long has it existed for? What’s its reputation like? If you’re determined to be an idiot about security then no amount of my guides and script reviews will help you, but it never hurt anyone to do a little bit of testing and help themselves.