Re: SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
>>>
>>>
> 


-- 
Thanks!
-Shawn
http://www.spidean.com

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


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux