Suhosin is completely not-related to SQL, though, I don't know why you'd
bring it up...
>
>
>
> On Thu, May 21, 2009 at 3:42 PM, Shawn McKenzie <nospam@xxxxxxxxxxxxx>wrote:
>
>> 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
>>
>>
>
