Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
WHY IS php-general@lists.php.net PUBLISHING USER EMAIL ON THE INTERNET: http://www.google.co.uk/search?q=sumitphp5%40gmail.comsourceid=navclient-ffie=UTF-8rlz=1B3GGGL_enGB303GB303aq=t On Fri, May 22, 2009 at 11:28 AM, Sumit Sharma sumitp...@gmail.com wrote: Thanks to [0] = Ashley, [1] =Bruce, [2] = Michael, [3] = Shawn, [4] = Eddie and php-general list for all your support from bottom of my heart. Now it seems as if I will be able to design my project more secured than before. If you get any other idea please suggest me. Thanks, Sumit. -- Forwarded message -- From: Michael A. Peters mpet...@mac.com Date: Fri, May 22, 2009 at 4:50 AM Subject: Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE To: Eddie Drapkin oorza...@gmail.com Cc: php-general@lists.php.net Eddie Drapkin wrote: Suhosin is completely not-related to SQL, though, I don't know why you'd bring it up... I brought it up because suhosin catches many exploits that otherwise get through, including exploits that allow inclusion of remote files that can then be used to run arbitrary commands on the server, send include files (such as the db authentication script) as plain text, all kinds of nasty can result. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Best Wishes A Williams
Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
On Fri, May 22, 2009 at 6:35 AM, Andrew Williams andrew4willi...@gmail.com wrote: WHY IS php-general@lists.php.net PUBLISHING USER EMAIL ON THE INTERNET: http://www.google.co.uk/search?q=sumitphp5%40gmail.comsourceid=navclient-ffie=UTF-8rlz=1B3GGGL_enGB303GB303aq=t On Fri, May 22, 2009 at 11:28 AM, Sumit Sharma sumitp...@gmail.com wrote: Thanks to [0] = Ashley, [1] =Bruce, [2] = Michael, [3] = Shawn, [4] = Eddie and php-general list for all your support from bottom of my heart. Now it seems as if I will be able to design my project more secured than before. If you get any other idea please suggest me. Thanks, Sumit. -- Forwarded message -- From: Michael A. Peters mpet...@mac.com Date: Fri, May 22, 2009 at 4:50 AM Subject: Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE To: Eddie Drapkin oorza...@gmail.com Cc: php-general@lists.php.net Eddie Drapkin wrote: Suhosin is completely not-related to SQL, though, I don't know why you'd bring it up... I brought it up because suhosin catches many exploits that otherwise get through, including exploits that allow inclusion of remote files that can then be used to run arbitrary commands on the server, send include files (such as the db authentication script) as plain text, all kinds of nasty can result. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Best Wishes A Williams Because the lists are archived by several sites, and those archives are indexed by search engines. Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
not related to SQl but u may want to look at http://php-ids.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
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.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
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
Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
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 nos...@mckenzies.netwrote:
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
Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
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
Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
Eddie Drapkin wrote: Suhosin is completely not-related to SQL, though, I don't know why you'd bring it up... I brought it up because suhosin catches many exploits that otherwise get through, including exploits that allow inclusion of remote files that can then be used to run arbitrary commands on the server, send include files (such as the db authentication script) as plain text, all kinds of nasty can result. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
