Posted by Andrew
Posted on 01-09-2008 under Development

Using good design and implementation practices can be the difference between your client’s site having many years of reliable and incident-free service, and catastrophe. That said, I would like to discuss over the next few weeks a few implementation practices that the Programming Department at Frye / Wiles either already follows on a regular basis, or is evaluating for future use.

Our lesson for today will be in protecting ourselves and our clients’ property from an unexpected server crash.

One of the greatest oversights as a programmer working with scripting languages, like PHP, is assuming that a website’s source code will always be invisible to outside users. Outside of overlooked errors (which, if error and warning reporting is not properly turned off, can display large chunks of information about a site’s architecture), and underlying code (SQL syntax errors, I’m looking at you), there is another major threat: a server or interpreter crash.

For whatever reason, be it buffer overflow or PHP’s process dying and then being unable to restart, instead of displaying a scripts expected output, the server will likely display the source code for the script itself.

This can be catastrophic, especially if things like database credentials or other sensitive data lives within your code, like the following example:


<?php
//Database connection configurations
//@author Guybrush Threepwood
$link = new PDO('mysql:host=localhost;dbname=social_security', 'root', 'weaksauce');
?>


Should the serve crash, this file could be viewable to anyone lucky enough to snooping around at the time. Potentially the person attempting to crash the server. Someone who can now has access to the database storing all of your company’s unencrypted social security numbers…

So the question, of course, is what can you do to prevent such things from happening? The easiest and most effective answer in this situation would be move as much scripting as possible, especially configuration scripts containing sensitive data, to a directory on your server that is not accessible to the outside world. This could be, for example, the directory above your site’s document root which is generally inaccessible to anyone but an administrator-type account on the server.

Of course this is not the be all end all, its but it is a step in the right direction. Over the next few months we will go over several security procedures everyone should follow or improve upon in order to ensure that their, and in many cases their clients, and their users properties remain safe.