Michael A. Peters wrote: > 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.
PDO is another good option. You shouldn't have to worry about escaping or SQL injections, though suhosin is a great idea. http://php.net/manual/book.pdo.php -- Thanks! -Shawn http://www.spidean.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php