Sumit Sharma wrote:

I am designing a php website for my client which interact with database.
This is my first project for any client (I hope he is not reading this mail
;-)  ). I am a bit more concerned with database security. Can somebody shed
some light on the security measurements, precautions, and functions related
to database security in general to make sure that the data is safely stored
updated and retried from database. I have already used htmlentities(),
strip_tags(), addhashes(), and some regular expressions to check security.
Looking for help beyond this.

Thanks in advance...

Use prepared statements.
If you are just starting out, I would recommend using a database abstraction layer, such as MDB2 from pear.

Doing it now is a LOT easier than porting an existing web application to use a database abstraction layer.

With prepared statement, sql injection is not an issue.

Example of prepared statement with MDB2:

$types = Array('integer','text','integer');
$q = 'SELECT somefield,someotherfield FROM sometable WHERE afield > ? AND bfield=? AND cfield < ? ORDER BY somefield';
$sql = $mdb2->prepare($q,$types,MDB2_PREPARE_RESULT);

$args  = Array($var1,$var2,$var3);
$rs = $sql->execute($args);

Prepared statements pretty much neuter any and all sql injection attempts, assuming the database supports prepared statements (otherwise the abstraction layer may emulate them which could possibly be prone to vulnerabilities).

While you do not need to use an abstraction layer to use prepared statements, the advantage of an abstraction layer is that your code will be much easier to port to a different database - advantageous to your client if they ever want to change databases, advantageous to you if you ever want to resuse you code for another client (assuming your contract does not give exclusive ownership of your code to your existing client).

The user the web server connects with should be as restricted as possible. It should only have permission to connect to the database from the host where the web server is running (localhost if running on same machine as the sql server) and should not be granted any permissions it does not absolutely need.

The file containing the database authentication credentials should end in .php and not .inc, and if at all possible, should be outside the web root (you can modify the include path to add a directory outside the web root that has includes - or include the file full path).

Make sure error reporting is turned off on the production web server (you can still read errors in the web server log).

If at all possible, run php compiled with the suhosin core patch and also run the suhosin loadable module.

You shouldn't need addslashes with prepared statements.
You should run user input through an existed tested input filter, such as rather than trying to re-invent the wheel and create your own. Script kiddies have scripts that test webapps for input vulnerabilities (both xss and sql injection), and some of them are rather tricky and browser specific.

A community driven project like HTMLPurifier is more likely to catch malicious input than something you cobble together.

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to