Comments on: CGI Do's and Don'ts

By: Simon Westcott

Simon Westcott — Wed, 21 May 2008 17:01:31 +0000

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

By: A.

A. — Wed, 21 May 2008 06:12:55 +0000

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.

By: Mark

Mark — Tue, 20 May 2008 21:30:40 +0000

Loving that blog Ben.

Nice one. Thanks.

By: James Mitchell

James Mitchell — Tue, 20 May 2008 16:18:15 +0000

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

By: Ben Brown

Ben Brown — Tue, 20 May 2008 13:26:01 +0000

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.

By: Anonymous

Anonymous — Tue, 20 May 2008 12:26:50 +0000

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?)