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
If the script relies heavily on user input, it will need that all important sanitisation. Although a badly validated form won’t always equate to an insecure script, 9 times out of 10 if I can pass unsavoury data through one, the rest of the script is pants too. Best to start with JavaScript disabled to bypass any virtually pointless client-side validation and then stuff fields with HTML tags — if your output looks formatted or any of your tags have slipped through there’s an issue right there. Try this with search forms, contact forms, etc.
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: my-best-friend@hotmail.com, my-other-friend@gmail.com
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.
04 Aug at 9:07 pm
Good article. Thanks for this. *learns*
04 Aug at 9:32 pm
Thanks for the tips, Jem!
04 Aug at 10:05 pm
Thanks alot for great tutorial.
04 Aug at 10:52 pm
Nice one, thanks!
05 Aug at 1:54 am
Thanks Jem! I’ve done a few of these tests myself, but a few of the others I hadn’t thought of (e.g. changing file extensions). I’ll have to give them a run through (before sending them to you anyways :P)
05 Aug at 2:16 am
Your tutorials and tips are also so helpful! I don’t fiddle with PHP much, but if I ever do, I’ll definitely try to remember this page.
05 Aug at 12:29 pm
Make sure there is a part 2 soon!
05 Aug at 5:41 pm
Great and very educational article!
05 Aug at 9:17 pm
Not using uploads myself, but before I ever will I do need to get a better understanding of this extension thing. About URL manipulating: so far I’ve used an array with allowed values, then I set default value and if URL value is in my array then I overwrite the default value. That should be safe, right?
06 Aug at 9:39 am
Great help and just in time too; I’m starting to write my own scripts! :) Thanks a bunch, Jem!
06 Aug at 8:36 pm
This entry is very enlightning! Very helpful for us noobs who are in the begining stages of learning PHP. And those tips are helpful for any other language not just PHP.
06 Aug at 8:58 pm
Most common forms related to security for the programmer I’ve seen(under URL Manipulation) are SQL-Injection and on the same branch with scripts that scale directories. These scripts often create vulnerabilities where the attacker can navigate into other directories or files and obtain sensitive data. I look forward to your subsequent articles on this topic.
07 Aug at 6:44 pm
Thanks, that helps a lot. Half of the non-Wordpress user bloggers I know use Cutenews and you’d think it’s safe. =) Can you recommend a safer content manager? [I don’t want WordPress, installing is a little bit complicated for me.] By the way, Swimchick started to sell her layouts!
07 Aug at 9:26 pm
@Dicle: FanUpdate?
07 Aug at 10:08 pm
Better than that – you could just give me the l33t PHP ninja side of your brain? That’d save the boring learning part.
09 Aug at 8:27 pm
I have no clue about PHP coding -_-
01 Oct at 9:47 pm
Hey, my Tagboard script keeps getting spammed (hacked), would you be willing to have a look over it for me? If so please email me as soon as possible. Thanks, Chris
27 Nov at 4:49 am
Sometimes you don’t have a choice but to check for extensions as mime types are all reported as application/octet-stream. Otherwise, decent guide :)