Obligatory ''Vista is not an upgrade from XP'' post ►

◄ The latest, greatest media technology: where next?

PHP isn't inherently any more insecure than many other programming languages, but does make it quite easy to do dumb things and harder to do the correct thing — particularly for those of us who are self-taught. This is my basic checklist...

(Our primary objective, in case you're unclear on the risks, is to make sure a malicious user can't send code to your PHP document or app that will be executed on your server — wiping or editing files, using it to send spam, etc.)

... Learn what magic_quotes, register_globals and allow_url_fopen are. Switch them off if possible. Read around the subjects of safe_mode and open_basedir. Don't use routines such as eval() unless you're an honest-to-god programming expert. If you're unable to switch off things like register_globals (which might be possible using .htaccess even if you don't have access to php.ini) be aware that you need to pay even more attention to security than you would otherwise.

... Data from $_POST, $_COOKIE, $_SESSION, $_REQUEST, etc. is no different to $_GET, and a malicious user can send anything to them from their browser client. Treat all external data as tainted.

... Sanitise data when you get it, i.e. as soon as you do something like $var=$_GET["var"] you should be sending $var off to your_own_sanitisation_routine(). Learn to love htmlentities() and regular expressions for, as an example, removing any characters from a string that aren't alphanumeric — that alone can stop people stuffing paths for other files into your variables.

... For added safety, when building routines to sanitise data, allow only the minimum... if your form only requests alphanumeric characters and you get others, send the data back to the user with a polite explanation and the data they submitted ready for correction. In other words, whitelist rather than blacklist. But don't just throw away data the user has submitted; help them to help you.

... This one's more about code layout and good habits: obtain external data (your $_POSTs, $_GETs, etc) at the beginning of a PHP document, if possible, so that you can easily keep track of what's being gathered.

... Never use include() [or include_once(), require(), require_once()] when file_get_contents() will do. Make a point of avoiding include() when it's being passed a variable that the user can potentially change — i.e. any time you write something like include($file), you'd better have a damn good routine verifying and/or sanitising $file.

... Whether a SELECT (or UPDATE, etc) action, don't use data in a MySQL query that hasn't been sanitised with mysql_real_escape_string — there are many ways to hide malicious code in variables. Neither addslashes() nor mysql_escape_string are sufficient.

... Don't use other people's code (such as wikis, forums, blogs and guestbooks) without carefully examining it, or at very least their track record and reputation with people who Know Stuff.

... Buy, read and absorb this book.

💬 Comments are off, but you can use the mail form to contact or see the about page for social media links.

BLOG  MORE  ABOUT  MAIL