Eddie Drapkin wrote:
> Suhosin is completely not-related to SQL, though, I don't know why you'd
> bring it up...

Well, because the post that I was replying to brought it up and I happen
to agree that it's a good idea even though it has nothing to do with SQL :-)

>>> Michael A. Peters wrote:
>>>> 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


PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to