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
