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
On Fri, May 22, 2009 at 6:35 AM, Andrew Williams wrote: > WHY IS php-general@lists.php.net PUBLISHING USER EMAIL ON THE INTERNET: > > http://www.google.co.uk/search?q=sumitphp5%40gmail.com&sourceid=navclient-ff&ie=UTF-8&rlz=1B3GGGL_enGB303GB303&aq=t > > On Fri, May 22, 2009 at 11:28 AM, Sumit Sharma 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 >> Date: Fri, May 22, 2009 at 4:50 AM >> Subject: Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE >> To: Eddie Drapkin >> 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
WHY IS php-general@lists.php.net PUBLISHING USER EMAIL ON THE INTERNET: http://www.google.co.uk/search?q=sumitphp5%40gmail.com&sourceid=navclient-ff&ie=UTF-8&rlz=1B3GGGL_enGB303GB303&aq=t On Fri, May 22, 2009 at 11:28 AM, Sumit Sharma 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 > Date: Fri, May 22, 2009 at 4:50 AM > Subject: Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE > To: Eddie Drapkin > 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
Fwd: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
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 Date: Fri, May 22, 2009 at 4:50 AM Subject: Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE To: Eddie Drapkin 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
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
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
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 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
>>
>>
>
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
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: Fwd: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
On Thu, 2009-05-21 at 19:17 +0530, Sumit Sharma wrote: > One more thing, should I use @ for security purpose or not so that the use > can reply me with the errors so that I can troubleshoot the problem more > effectively. > > > Sumit > > -- Forwarded message -- > From: Ashley Sheridan > Date: Thu, May 21, 2009 at 6:36 PM > Subject: Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE > To: Sumit Sharma > Cc: php-general@lists.php.net > > > On Thu, 2009-05-21 at 18:22 +0530, 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 > > I'd advise using something like mysql_real_escape_string() (assuming you > are using a MySQL database that is) on each variable of data before you > insert it into the database. You could go further and validate specific > data, so check that a field which you expect a number only contains a > number, etc. > > > Ash > www.ashleysheridan.co.uk I'd avoid using @ in favour of turning the errors off in your php.ini or .htaccess, as there's no chance of you missing a statement here or there. It's generally accepted practice to have errors and warnings turned off on a live server, and to only use them on development servers. Ash www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Fwd: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
One more thing, should I use @ for security purpose or not so that the use can reply me with the errors so that I can troubleshoot the problem more effectively. Sumit -- Forwarded message -- From: Ashley Sheridan Date: Thu, May 21, 2009 at 6:36 PM Subject: Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE To: Sumit Sharma Cc: php-general@lists.php.net On Thu, 2009-05-21 at 18:22 +0530, 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 I'd advise using something like mysql_real_escape_string() (assuming you are using a MySQL database that is) on each variable of data before you insert it into the database. You could go further and validate specific data, so check that a field which you expect a number only contains a number, etc. Ash www.ashleysheridan.co.uk
Re: [PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
On Thu, 2009-05-21 at 18:22 +0530, 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 I'd advise using something like mysql_real_escape_string() (assuming you are using a MySQL database that is) on each variable of data before you insert it into the database. You could go further and validate specific data, so check that a field which you expect a number only contains a number, etc. Ash www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] SECURITY PRECAUTION BEFORE SUBMITTING DATA IN DATABASE
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
