Sumit Sharma wrote:
Hi,
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...
Sumit
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 http://htmlpurifier.org/ 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 (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
