This is a great tip, but many PHP developers write code that will inevitably run on cheap shared hosting solutions in which no physical control over the server is possible. Taken a step further, configuration of these server is largely out of the developer's hands as well.

While this tip doesn't quite apply in such a scenario, it did get me thinking about shared hosting issues that could be minimized given a little time and thought.

One of these is the issue of shared database access. Most shared hosts provide each customer account with 1 or more MySQL or PostgreSQL databases for use on their sites. What are some ways to minimize the risk of sharing a database with other users, given that insecurities in their code could inadvertently compromise your data?

Cross-site request forgery. (I left off the F. That’s fixed now.)

=C=

Allot of these developers who write articles only consider one point of view... Their own.

You do not have to sacrifice a server to the DMZ God, it can happily sit behind a firewall of its own & when properly configured, that firewall will not stop the server from receiving incoming connections.

Many of these "Authors" professing to provide ultimate knowledge on beefing up security that they automatically assume that they are the Gurus on that particular subject, maybe, maybe not, but do they ever consider the humble developer using hosting? Never! Why? Because they are so blinkered and myopic in their single minded view that they forget their humble beginnings and start talking out their backends.

OK, so you want to protect your hosting space and the database that services it...

ANY page that you develop MUST have a simple test to check where it is running from, if it is not in the expected domain space or in the expected user path, kill the script.

SESSIONS and using them in a secure way, a simple token & checking system on all out facing consoles, blogs, forms etc to ensure that the page had been requested from your server and use checking to ensure that it had originated from your domain. You cannot rely on the referrer value as this can be easily spoofed, you can use a token like:-

<?php
session_start();
$token = md5(uniqid(rand(), true));
$_SESSION['token'] = $token;
$_SESSION['rip'] = $_SERVER['REMOTE_ADDR'];
?>

and in your form's HTML a hidden field

<input type="hidden" value="<?php echo $token; ?>" name="token">

Then when the form is submitted, you check that the receiving form token is present & a match for the token in the SESSION as well as the remote IP address matches the stored IP address in the token, and then you have verified that the form originated from your domain and the sending user is the same user and not a sideways attempt at hacking your system or flooding with multiple posts to expose other exploits. You then you can begin cleaning the inputs.

CLEAN all the data inputs, simply to assume that your data submit and checking client-side will produce a clean data set is pretty naive and open to exploit, only when you check and ensure that you neuter all possible exploits will you ensure that your application is safe to use. It however is always good to try to limit the data that can be sent, if you only expect to have 20 characters in an input field, limit it to 20 characters, leaving the limit open allows malicious exploits to happen by the posting of more data than requires, this data could be a simple script to crack your server. Use client-sided to limit other aspects of input data but back this up server-side, never assume that the client is trustworthy or has fully secured the data accepted, most scripts can be bypassed.

On the server... Keep an array of what is expected in the processing script that deals with the form data submits and ignore everything else, use an array that will contain all the elements that you have sanitised so that you can be sure that the data contained is or has been treated, only use that data from that source within the rest of your script or you open yourself up to security problems, using $_GET or $_POST or the other variants beyond your security wall you impose will open you to the multiple post security exploits.

If you must accept HTML, encode the page and remove any dangers like embedded PHP or other server-side code, if your not accepting HTML in your posts strip any tags, depending on what you need from your data, stripping slashes or adding them as well as escaping them with the PHP/MySql functions is always a good thing and store as a base64 encode for example.

ULTRA security is obtained by removing all vulnerable data into "Include" files that are stored in a folder that you keep separate from your accessible site code and again, applying the same checking to ensure that the scripts are being run from the location in which they are meant to exist is paramount in securing your hosting space.

DATABASE connectors and the data that you accept & store MUST BE CLEAN and checked and rechecked if you have to, any exposure to the outside world will cause you problems with security on your database. Keeping the URL and username and password secure is important. I have just implemented a system where the "Sensitive" data is stored as a set of hashes that are either decodable or a one way hash depending on if the data is to be compared or used later and the connectors exist in an encoded format that has code to verify where it is running. This is an overhead but a justifiable one.

Assuming that your host has basic level security in place, your scripts should be safe from exploits, if not, move host theirs plenty of them to choose from and to suit your pocket.

IF your data is that sensitive in the first place... What are you doing putting it out on the internet? Why are you networking your sensitive data to a system that has an outside world connection? You should only store data that is needed to keep your system functional, apply security checks TO ALL your PHP pages, even the non secure or public access ones as this can lead to problems and give the hacker a peek in to the structure of your site.

LOGGING URL requests and harvesting IP addresses can help you in identifying potential hackers, Zombie groups, vulnerable URLs and provide you with the evidence you need to present to the owners of those IP addresses or ISP's behind the IP addresses.

Having run many public servers, I always issue a warning that if unheeded will result in action being taken. To date I have only had to report Two cases to their ISP's and one of those was Czechoslovakian and another German. Both never troubled me again.

You should now be able to stop losing sleep over your site code, as long as you do not skimp on coding, checking and securing, never assume or presume something is safe, always sanitise it and you will be safeguarding your development.