Time Management as a techie

[#1]

One of the things I often find myself looking at whilst monitoring the platform are problems with our CGI platform caused by insecure or inefficient scripts. Almost once a week I find a page, or whole site that has been compromised. So I've decided to put together a quick list of good things to do and bad things to avoid doing on our platform. Some of these will apply to CGI systems in general, some will be more specific. 1) NEVER trust user input. This is a generic scripting maxim and applies to every sort of scripting and programming. One of the most common ways of exploiting CGI sites is through manipulation of the input that the script expects, for example PHP remote include vulnerabilities. Luckily this is often easy to resolve, but it's easier to bear this in mind right from the start of your development. I'm not a professional PHP developer (I'm a Networks bod here at PN Towers) I've dabbled in it for several years and have picked up some tricks along the way. My first tip is to use integers in your input as much as possible, as they are very easy to verify. For example if you have a bunch of users in a database, and each of them have a user Id as well as a name, use the id when referring to them rather than the name, e.g. # bad profile.php?user=Ben # good profile.php?id=1 In our PHP, we can then use the "intval" function to make sure the value can only be an integer: $userId = intval($_GET['id']); or in Perl: $userId =~ s/[^\d]//g; Perl also offers additional protection with it's "Taint" option. For any CGI perl scripts you should always invoke perl with this enabled, e.g.: #!/usr/bin/perl -T 2) Disable RegisterGlobals This is PHP specific, and on most platforms is disabled by default, however when our CGI platform was bought online we decided to enable it as so many customer scripts relied on it being there. Personally if I had my way it would be disabled for everyone as it introduces some significant security issues, however there are still many customers using old scripts that rely on it and they would all be really upset if I "broke" their scripts. The good news is that you can disable this on your site relatively simply, by adding the following to a file called "php.ini" in the directory your php scripts are in: register_globals = off The important thing with adding a php.ini file is that it is in all the directories php will be run from. A quick and fairly dirty way of doing this would be to run the following command, assuming you have added your php.ini file to your home directory: ~$ for i in $(find . -type d); do ln -s $PWD/php.ini $i; done This will add a symbolic link to the php.ini file in your home directory in each directory you have. A symbolic link is like a shortcut, now if you change the php.ini file in your home directory (or indeed any of the other directories) it will apply to all the directories. By disabling these global variables your scripts will be safer, however there is still potential for abuse. 3) Keep your scripts up to date A good deal of sites that I see compromised are running out of data third party software, the most common example is old versions of phpBB. If you are using third party software, sign up for their announcement mailing list of RSS feeds and make sure you update them when new releases are announced. Upgrading common things like wordpress and phpBB is usually painless and quick, so there's no excuse! 4) If you're not using something, remove/disable it. This is kind of in line with my previous tip. If you installed a forum months ago and never use it, then get rid or disable it. I've seen so many cases where old versions of forum software have been compromised/spammed to death and when we've contacted the customer who runs it they've said "Oh I don't use that any more, get rid of it". 5) Don't allow anonymous comments. Some time ago we had problems with one of the customer mysql servers, which was using a lot of traffic, well so much traffic that it's interface couldn't handle it all so connectivity to it was flaky. When I looked into it, I found this was caused by one page which allowed anyone to add comments without any verification. This had been caught on to by spam bots which were causing this phenomenal volume of traffic. Once we disabled the site, normal service was resumed. Something to be careful with is that some installations of mediawiki seem to allow anyone to comment on the "discuss" pages, even if articles need authentication to edit. In summary, the CGI server can be very powerful and can be used for a wide variety of things; this is a double edged sword as it can be used for evil as much as for good. It's great that people have it to play with and learn on but you need to be careful - or all sorts of badness can happen! This list is just a few things off the top of my head and is by no means exhaustive. If any of you out there can think of any more, that's what the comments bit below is for! Happy scripting and play safe!

[#2]

I object to the following assertion: # bad profile.php?user=Ben # good profile.php?id=1 In my eyes your "Good" option is no better than your "Bad" option. What you should be doing is: - properly escaping input data (Yes this is *easier to check* if you're expecting an INT rather than a string type - but expecting an INT is *no more secure* than expecting a string) - Once you've ascertained that the input is "safe" you should check that it's valid (Is it a real user ID belonging to a real user) - Check that the user requesting the information has the authority to access the data (ie - should I be able to see user ID 1's profile?)

[#3]

In retrospect prehaps "Good" and "Bad" weren't the right words to use. I agree that escaping input data is good, however if you are using integers then no escaping is required. Whether the value is valid should be down to the rest of the script but the risk of sql injection etc is not possible with an integer (as returned by "intval" in my example), and this document is intended as a brief starting point, and not a comprehensive design manifesto.

[#4]

There's a huge amount of SQL fast-fluxing injection happening at the moment across the net. The Asprox botnet is quickly spreading around. I know of several SQL based forums that have been compromised in the last couple of days. There's more info on Asprox : http://blogs.zdnet.com/security/?p=1122

[#5]

Loving that blog Ben. Nice one. Thanks.

[#6]

Never forget the mysql_real_escape_string() function in PHP. It will prevent every type of SQL injection attack for all value types. For file uploads is_uploaded_file() is a must, otherwise you risk local file inclusion exploits. > profile.php?id=1 Many search engines including Google will refuse to crawl pages with the "id" query string in them. profile.php?user=1 seems ideal.

[#7]

Good stuff Ben. The only problem with intval() is that it does more than validate input, it also filters input. This can lead to expected and undesired results. For example, intval('123abc'); // 123 intval(0123); // 83 It's safer to reject invalid input as filtering can lead to further security holes. One method I've seen more than once for preventing directory traversal is to removed '..' from file paths, $safe_filename = str_replace('..', '.', $_FILES['filename']); This filter is OK when $_FILE['filename'] is '../../../../etc/passwd', however it can be exploited with '.../.../.../.../etc/passwd'.