[PHP] SQL Injection
Dear List - I am aware of a long email trail on this subject, but there does not seem to be a resolution. Is it possible to have a meeting of the minds to come up with (an) appropriate method(s)? Thanks. Ethan Rosenberg -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection
On Fri, Jun 8, 2012 at 12:37 PM, Ethan Rosenberg eth...@earthlink.net wrote: Is it possible to have a meeting of the minds to come up with (an) appropriate method(s)? Minds, meet prepared statements :) Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] SQL Injection
-Original Message- From: Adam Richardson [mailto:simples...@gmail.com] Sent: Friday, June 08, 2012 11:50 AM To: PHP-General Subject: Re: [PHP] SQL Injection On Fri, Jun 8, 2012 at 12:37 PM, Ethan Rosenberg eth...@earthlink.net wrote: Is it possible to have a meeting of the minds to come up with (an) appropriate method(s)? Minds, meet prepared statements :) Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php PDO is the way to go :D Jen -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection
Is it possible to have a meeting of the minds to come up with (an) appropriate method(s)? Minds, meet prepared statements :) PDO is the way to go :D Not to refute the above advice one bit (not to mention oppose the arguments against escaping in general) ... but just curious - can anyone demo a hack that effectively injects past mysqli_real_escape_string(), while using utf-8 ? It may just be a matter of time (or already?) before mysqli_real_escape_string is *proven* ineffective (w/utf-8) ... but here I am just attempting to gather facts. Thanks -Govinda -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection
On 06/08/2012 10:31 AM, Govinda wrote: Is it possible to have a meeting of the minds to come up with (an) appropriate method(s)? Minds, meet prepared statements :) PDO is the way to go :D Not to refute the above advice one bit (not to mention oppose the arguments against escaping in general) ... but just curious - can anyone demo a hack that effectively injects past mysqli_real_escape_string(), while using utf-8 ? It may just be a matter of time (or already?) before mysqli_real_escape_string is *proven* ineffective (w/utf-8) ... but here I am just attempting to gather facts. Thanks -Govinda Ah, but what if I use sqlite or postgres? IMHO, the discussion needs to be a the best way to prevent SQL injection across all possible DB types. Not just mysql. -- Jim Lucas http://www.cmsws.com/ http://www.cmsws.com/examples/ http://www.bendsource.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection
Jim Lucas wrote: Not to refute the above advice one bit (not to mention oppose the arguments against escaping in general) ... but just curious - can anyone demo a hack that effectively injects past mysqli_real_escape_string(), while using utf-8 ? It may just be a matter of time (or already?) before mysqli_real_escape_string is *proven* ineffective (w/utf-8) ... but here I am just attempting to gather facts. Ah, but what if I use sqlite or postgres? Or Firebird ;) IMHO, the discussion needs to be a the best way to prevent SQL injection across all possible DB types. Not just mysql. The main thing to avoid is building queries from elements that are directly loaded from the form inputs. While it is difficult to build sort elements for queries that use parameters, having a mechanism like ADOdb's datadict where one can filter SQL based on the identified field names does make life easier. While the problems of dealing with student names such as 'Delete from student' are easily solved by only using them in parameter arrays. A few simple basics cover the vast majority of traditional SQL injection problems? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection
Ah, but what if I use sqlite or postgres? Or Firebird ;) good point. IMHO, the discussion needs to be a the best way to prevent SQL injection across all possible DB types. Not just mysql. The main thing to avoid is building queries from elements that are directly loaded from the form inputs. While it is difficult to build sort elements for queries that use parameters, having a mechanism like ADOdb's datadict where one can filter SQL based on the identified field names does make life easier. While the problems of dealing with student names such as 'Delete from student' are easily solved by only using them in parameter arrays. A few simple basics cover the vast majority of traditional SQL injection problems? Yes, apparently. Part of why I even asked is to get a sense of the shelf life on legacy code (that relies on escaping) which I am not keen to have to re-write, for free, until I really must. -Govinda -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection
Govinda govinda.webdnat...@gmail.com wrote: Ah, but what if I use sqlite or postgres? Or Firebird ;) good point. IMHO, the discussion needs to be a the best way to prevent SQL injection across all possible DB types. Not just mysql. The main thing to avoid is building queries from elements that are directly loaded from the form inputs. While it is difficult to build sort elements for queries that use parameters, having a mechanism like ADOdb's datadict where one can filter SQL based on the identified field names does make life easier. While the problems of dealing with student names such as 'Delete from student' are easily solved by only using them in parameter arrays. A few simple basics cover the vast majority of traditional SQL injection problems? Yes, apparently. Part of why I even asked is to get a sense of the shelf life on legacy code (that relies on escaping) which I am not keen to have to re-write, for free, until I really must. -Govinda -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php I think you can happily sanitise data where it makes sense, and use bound parameters elsewise. So when you expect a number, its easy to check for and force a sensible default. Likewise for things like dates, or names of articles (probably a popular need with a CMS) you can check and enforce particular characters. Outside of that, without bound params you run a potential risk (even if only slight). You can do stuff like base64 encode values, but then you lose a lot of the ability to search through your DB after. Thanks, Ash http://ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection
I think you can happily sanitise data where it makes sense, and use bound parameters elsewise. So when you expect a number, its easy to check for and force a sensible default. Likewise for things like dates, or names of articles (probably a popular need with a CMS) you can check and enforce particular characters. Outside of that, without bound params you run a potential risk (even if only slight). You can do stuff like base64 encode values, but then you lose a lot of the ability to search through your DB after. What would you say in the case of having used CodeIgniter (w/it's modified 'Active Record Class', before PDO was an (easy/built-in) option in CodeIgniter) to develop an app that serves content in dozen(s) of languages through a custom international CMS... and now they want a search box so end users can search all the pages (db data) of the site for that country (in that country's main language)? IOW form input that I cannot just force/sanitize to e.g. (english) alphanumeric (+ spaces), and I cannot just switch to using PDO without rewriting all the code in all the model files. Thanks -Govinda -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sql injection protection
This is an interesting conversation, so I'm glad it got brought up,but I find myself curious: Are you actually trying to avoid PDO, or just trying to learn how the security actually works? Well, It's a learning process. my point is this... If I can make it safe and sound without the PDO, then I really got to the bottom of it. Because once you reach there and I would be in a much better shape cause at the end, I will still use PDO level. PDO is not safe. I should say, it is not SAFE ENOUGH. You are still vulnerable with PDO as well. Cause PDO still requires you to validate your input. If you don't do a good job at it, then you are using PDO as a drug. You have to go down to bottom of it and that's validating the darn user input. Well, if you validate your input well, then one can turn the question around and ask, then why use PDO? It's not going to make it any safer! It was already so. The danger with the PDO articles... Using/or Recommending PDO without the nitty/gritty details of how important it is to validate your input is unfortunately leading people ( unexp. dev ) into thinking that it's a safer method, therefore they can go relax at certain things and PDO will cover them. I think one should try to make his data secure, first and foremost - without *relying* PDO to take care of things. Therefore, we should learn the crux of the matter. By that, I mean all that multibyte and GPK Greek and some other weird char sets that one should be aware of and what to do to really safe guard the databases against all kinds of user data. Only then and only then, one should START thinking about using PDO. http://stackoverflow.com/questions/134099/are-pdo-prepared-statements-sufficient-to-prevent-sql-injection That's why I started this thread. On Tue, Jan 17, 2012 at 4:39 AM, Andy McKenzie amckenz...@gmail.com wrote: On Mon, Jan 16, 2012 at 10:34 PM, Haluk Karamete halukkaram...@gmail.com wrote: I understand some ways are better than others in this one, and it looks like the PDO based implementations shine the most as far as SQL Injection. But would not the following be good enough - without implementing a PDO solution? This is an interesting conversation, so I'm glad it got brought up, but I find myself curious: Are you actually trying to avoid PDO, or just trying to learn how the security actually works? Personally, my decision was that I could spend a lot of time learning all the ins and outs, or I could just use PDO and some basic input validation, and be more-or-less secure. I'm sure there are cases where that's not sensible, but it's always worked for me. -Andy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] sql injection protection
I understand some ways are better than others in this one, and it looks like the PDO based implementations shine the most as far as SQL Injection. But would not the following be good enough - without implementing a PDO solution? 1- get the user input 2- for each input, deliberately enforce a data type ( that is date/string/integer ) and validate it. 3- for each input, deliberately enforce a data length ( for strings data length and for integer a valid range for example ) 4- check the magic_quotes_gpc and do the stripslashes and then the mysqli_real_escape_string() and the htmlentities. 5- and on top pf all this, I also check for the specific occurrences of these following words; if any exist, I just do not execute that SQL query. and that list is sysobjects, syscolumns, systypes, EXEC(@, CHAR(, exec%20, DECLARE%20@, wscript. CAST( CONVERT( 6- I also count the number of 0x occurrences, if the user input contains more than 2 of 0x, again I do not execute that command. With all these in place, I don't know of a way that a userinput can still make it thru. These may raise a false negative on some valid user input that's coming from a textarea where the data type is string, and an accepted char length is big enough to create some havoc in the db, so be it, I reject that input. My question even after all these are there still ways to break in? All the aboce can be easily tucked in a function which does a data validation something like VallidateUserInput ( $_GET['first_name'], varchar(100),Please supply a first name that is less than 100 characters); VallidateUserInput ( $_GET['age'], smallint,Please supply an age that is between 1-20) Your insight is greatly appreciated on this. I also read somewhere that mysql does NOT allow statement chaining. So, that's even better. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] SQL Injection - Solution
Hi folks,
Someone know how i can improve this function to protect my envairounment
vars of sql injection attacks.
that is the function i use to do this, but, some people think is not enough:
* @uses $_REQUEST= _antiSqlInjection($_REQUEST);
* @uses $_POST = _antiSqlInjection($_POST);
* @uses $_GET = _antiSqlInjection($_GET);
*
* @author Igor Escobar
* @email blog [at] igorescobar [dot] com
*
*/
function _antiSqlInjection($Target){
$sanitizeRules =
array('OR','FROM,'SELECT','INSERT','DELETE','WHERE','DROP TABLE','SHOW
TABLES','*','--','=');
foreach($Target as $key = $value):
if(is_array($value)): $arraSanitized[$key] =
_antiSqlInjection($value);
else:
$arraSanitized[$key] =
addslashes(strip_tags(trim(str_replace($sanitizeRules,,$value;
endif;
endforeach;
return $arraSanitized;
}
You can help me to improve them?
Regards,
Igor Escobar
Systems Analyst Interface Designer
--
Personal Blog
~ blog.igorescobar.com
Online Portifolio
~ www.igorescobar.com
Twitter
~ @igorescobar
Re: [PHP] SQL Injection - Solution
Hi there!
2009/5/6 Igor Escobar titiolin...@gmail.com
Hi folks,
Someone know how i can improve this function to protect my envairounment
vars of sql injection attacks.
that is the function i use to do this, but, some people think is not enough:
* @uses $_REQUEST= _antiSqlInjection($_REQUEST);
* @uses $_POST = _antiSqlInjection($_POST);
* @uses $_GET = _antiSqlInjection($_GET);
*
* @author Igor Escobar
* @email blog [at] igorescobar [dot] com
*
*/
function _antiSqlInjection($Target){
$sanitizeRules =
array('OR','FROM,'SELECT','INSERT','DELETE','WHERE','DROP TABLE','SHOW
TABLES','*','--','=');
foreach($Target as $key = $value):
if(is_array($value)): $arraSanitized[$key] =
_antiSqlInjection($value);
else:
$arraSanitized[$key] =
addslashes(strip_tags(trim(str_replace($sanitizeRules,,$value;
endif;
endforeach;
return $arraSanitized;
}
You can help me to improve them?
What if someone posts, in any form of your app, a message containing
or, from or where? Those are very common words, and eliminate
them is not the best solution, IMO.
Use mysql_real_escape_string() like Shawn said, possibly something
like this would do the trick (from
http://br2.php.net/manual/en/function.mysql-query.php):
$query = sprintf(SELECT firstname, lastname, address, age FROM
friends WHERE firstname='%s' AND lastname='%s',
mysql_real_escape_string($firstname),
mysql_real_escape_string($lastname));
Cheers,
Bruno.
Regards,
Igor Escobar
Systems Analyst Interface Designer
--
Personal Blog
~ blog.igorescobar.com
Online Portifolio
~ www.igorescobar.com
Twitter
~ @igorescobar
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection - Solution
On Wed, May 6, 2009 at 12:06 PM, Bruno Fajardo bsfaja...@gmail.com wrote:
Hi there!
2009/5/6 Igor Escobar titiolin...@gmail.com
Hi folks,
Someone know how i can improve this function to protect my envairounment
vars of sql injection attacks.
that is the function i use to do this, but, some people think is not enough:
* @uses $_REQUEST= _antiSqlInjection($_REQUEST);
* @uses $_POST = _antiSqlInjection($_POST);
* @uses $_GET = _antiSqlInjection($_GET);
*
* @author Igor Escobar
* @email blog [at] igorescobar [dot] com
*
*/
function _antiSqlInjection($Target){
$sanitizeRules =
array('OR','FROM,'SELECT','INSERT','DELETE','WHERE','DROP TABLE','SHOW
TABLES','*','--','=');
foreach($Target as $key = $value):
if(is_array($value)): $arraSanitized[$key] =
_antiSqlInjection($value);
else:
$arraSanitized[$key] =
addslashes(strip_tags(trim(str_replace($sanitizeRules,,$value;
endif;
endforeach;
return $arraSanitized;
}
You can help me to improve them?
What if someone posts, in any form of your app, a message containing
or, from or where? Those are very common words, and eliminate
them is not the best solution, IMO.
Use mysql_real_escape_string() like Shawn said, possibly something
like this would do the trick (from
http://br2.php.net/manual/en/function.mysql-query.php):
$query = sprintf(SELECT firstname, lastname, address, age FROM
friends WHERE firstname='%s' AND lastname='%s',
mysql_real_escape_string($firstname),
mysql_real_escape_string($lastname));
Cheers,
Bruno.
+1
I would stick with parameterized queries if available, or just use
mysql_real_escape_string() for these and a few more reasons:
1) You'll find lots of posts in the archives explaining why
mysql_real_escape_string() is preferred over addslashes() for this
purpose.
2) strip_tags has absolutely nothing to do with SQL injection. Neither
does trim(). There are cases where you would not want to use either of
those functions on input, but you would still need to guard against
injection.
3) DROP TABLE will work no matter how many white-space characters
appeared between the words. For that matter, I am pretty sure that
'DROP /* some bogus SQL comment to make it past your filter */ TABLE'
will work also.
Andrew
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection - Solution
I know that use the mysql_real_escape_string to do de job is better but you
should consider that the this function don't have any access to the data
base, to objective of this function is sanitize the string.
And please, see my second answer, i make some updates in the function that
possibly is relevant.
Regards,
Igor Escobar
Systems Analyst Interface Designer
--
Personal Blog
~ blog.igorescobar.com
Online Portifolio
~ www.igorescobar.com
Twitter
~ @igorescobar
On Wed, May 6, 2009 at 1:14 PM, Andrew Ballard aball...@gmail.com wrote:
On Wed, May 6, 2009 at 12:06 PM, Bruno Fajardo bsfaja...@gmail.com
wrote:
Hi there!
2009/5/6 Igor Escobar titiolin...@gmail.com
Hi folks,
Someone know how i can improve this function to protect my envairounment
vars of sql injection attacks.
that is the function i use to do this, but, some people think is not
enough:
* @uses $_REQUEST= _antiSqlInjection($_REQUEST);
* @uses $_POST = _antiSqlInjection($_POST);
* @uses $_GET = _antiSqlInjection($_GET);
*
* @author Igor Escobar
* @email blog [at] igorescobar [dot] com
*
*/
function _antiSqlInjection($Target){
$sanitizeRules =
array('OR','FROM,'SELECT','INSERT','DELETE','WHERE','DROP TABLE','SHOW
TABLES','*','--','=');
foreach($Target as $key = $value):
if(is_array($value)): $arraSanitized[$key] =
_antiSqlInjection($value);
else:
$arraSanitized[$key] =
addslashes(strip_tags(trim(str_replace($sanitizeRules,,$value;
endif;
endforeach;
return $arraSanitized;
}
You can help me to improve them?
What if someone posts, in any form of your app, a message containing
or, from or where? Those are very common words, and eliminate
them is not the best solution, IMO.
Use mysql_real_escape_string() like Shawn said, possibly something
like this would do the trick (from
http://br2.php.net/manual/en/function.mysql-query.php):
$query = sprintf(SELECT firstname, lastname, address, age FROM
friends WHERE firstname='%s' AND lastname='%s',
mysql_real_escape_string($firstname),
mysql_real_escape_string($lastname));
Cheers,
Bruno.
+1
I would stick with parameterized queries if available, or just use
mysql_real_escape_string() for these and a few more reasons:
1) You'll find lots of posts in the archives explaining why
mysql_real_escape_string() is preferred over addslashes() for this
purpose.
2) strip_tags has absolutely nothing to do with SQL injection. Neither
does trim(). There are cases where you would not want to use either of
those functions on input, but you would still need to guard against
injection.
3) DROP TABLE will work no matter how many white-space characters
appeared between the words. For that matter, I am pretty sure that
'DROP /* some bogus SQL comment to make it past your filter */ TABLE'
will work also.
Andrew
Re: [PHP] SQL Injection - Solution
mysql_escape_string can be used instead. You just lose the ability to
have it match coallation. I still think there should be the
mysql_escape_string or real one and allow it to pass the coallation
without a database handle -or- just make a unicode/utf8 one and be
done with it.
On May 6, 2009, at 9:40 AM, Igor Escobar titiolin...@gmail.com wrote:
I know that use the mysql_real_escape_string to do de job is better
but you
should consider that the this function don't have any access to the
data
base, to objective of this function is sanitize the string.
And please, see my second answer, i make some updates in the
function that
possibly is relevant.
Regards,
Igor Escobar
Systems Analyst Interface Designer
--
Personal Blog
~ blog.igorescobar.com
Online Portifolio
~ www.igorescobar.com
Twitter
~ @igorescobar
On Wed, May 6, 2009 at 1:14 PM, Andrew Ballard aball...@gmail.com
wrote:
On Wed, May 6, 2009 at 12:06 PM, Bruno Fajardo bsfaja...@gmail.com
wrote:
Hi there!
2009/5/6 Igor Escobar titiolin...@gmail.com
Hi folks,
Someone know how i can improve this function to protect my
envairounment
vars of sql injection attacks.
that is the function i use to do this, but, some people think is
not
enough:
* @uses $_REQUEST= _antiSqlInjection($_REQUEST);
* @uses $_POST = _antiSqlInjection($_POST);
* @uses $_GET = _antiSqlInjection($_GET);
*
* @author Igor Escobar
* @email blog [at] igorescobar [dot] com
*
*/
function _antiSqlInjection($Target){
$sanitizeRules =
array('OR','FROM,'SELECT','INSERT','DELETE','WHERE','DROP
TABLE','SHOW
TABLES','*','--','=');
foreach($Target as $key = $value):
if(is_array($value)): $arraSanitized[$key] =
_antiSqlInjection($value);
else:
$arraSanitized[$key] =
addslashes(strip_tags(trim(str_replace($sanitizeRules,,
$value;
endif;
endforeach;
return $arraSanitized;
}
You can help me to improve them?
What if someone posts, in any form of your app, a message containing
or, from or where? Those are very common words, and eliminate
them is not the best solution, IMO.
Use mysql_real_escape_string() like Shawn said, possibly something
like this would do the trick (from
http://br2.php.net/manual/en/function.mysql-query.php):
$query = sprintf(SELECT firstname, lastname, address, age FROM
friends WHERE firstname='%s' AND lastname='%s',
mysql_real_escape_string($firstname),
mysql_real_escape_string($lastname));
Cheers,
Bruno.
+1
I would stick with parameterized queries if available, or just use
mysql_real_escape_string() for these and a few more reasons:
1) You'll find lots of posts in the archives explaining why
mysql_real_escape_string() is preferred over addslashes() for this
purpose.
2) strip_tags has absolutely nothing to do with SQL injection.
Neither
does trim(). There are cases where you would not want to use either
of
those functions on input, but you would still need to guard against
injection.
3) DROP TABLE will work no matter how many white-space characters
appeared between the words. For that matter, I am pretty sure that
'DROP /* some bogus SQL comment to make it past your filter */ TABLE'
will work also.
Andrew
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] sql injection
i have implemented a way to avoid sql injection from the php website from
this url
http://in.php.net/mysql_real_escape_string from the Example #3 A Best
Practice query section of this page
following are the steps i have followed after the form values are submitted
to a php file.
step 1.
if(get_magic_quotes_gpc())
{
$username = stripslashes($_POST[username]);
.
}
else
{
$username = $_POST[username];
.
}
step 2.
$conn = mysql_connect($hostname, $user, $password);
step 3.
$insertquery = sprintf(INSERT INTO table (`username`, ...) VALUES ('%s',
...), mysql_real_escape_string($username, $conn), ...);
step 4.
if(!$conn)
{
header(Location: http://website/dberror.html;);
exit;
}
else
{
mysql_select_db($database, $conn);
$insertqueryresult = mysql_query($insertquery);
if(!$insertqueryresult) {
header(Location: http://website/error.html;);
exit; }
}
with the above method i am able to insert values into the table even with if
i enter the ' special character which can cause problems.
i have also used a simple sql insert query like
$insertquery = INSERT INTO table(username, ...) VALUES ('$username', ...);
when i used this simple insert query and if i entered ' in the form and
submitted the form the php file is unable to process the information entered
because of the ' character and as per the code error.html file is being
displayed where as if i use
$insertquery = sprintf(INSERT INTO table (`username`, ...) VALUES ('%s',
...), mysql_real_escape_string($username, $conn), ...);
even if i enter any number of ' characters in more than 1 form field data is
being inserted into the table
a)
so i am thinking that the steps i have taken from the php site is correct
and the right way to avoid sql injection though there are several ways to
avoid sql injection.
b)
for example if i enter data in the form as = abc'''def for name, the data in
the table for the name field is being written as abc'''def
based on how i have written the steps to avoid sql injection is this the
right way for the data to be stored with ' characters along with the data
example as i mentioned = abc'''def
please answer the questions a) and b) if there is something else i need to
do please suggest what needs to be done exactly and at which step.
any help will be greatly appreciated.
thanks.
Re: [PHP] sql injection
YOU can write (') characters in the database.. that fine..
mysql_real_escape_string avoid injections doing that: escaping characters
then when you put in a form
abc'''def
the query will be
INSERT . (name.) VALUES ( 'abc\'\'\'def'
each ' = \'
for me the steps are right
saludos
On Thu, May 29, 2008 at 4:10 PM, Sudhakar [EMAIL PROTECTED] wrote:
i have implemented a way to avoid sql injection from the php website from
this url
http://in.php.net/mysql_real_escape_string from the Example #3 A Best
Practice query section of this page
following are the steps i have followed after the form values are submitted
to a php file.
step 1.
if(get_magic_quotes_gpc())
{
$username = stripslashes($_POST[username]);
.
}
else
{
$username = $_POST[username];
.
}
step 2.
$conn = mysql_connect($hostname, $user, $password);
step 3.
$insertquery = sprintf(INSERT INTO table (`username`, ...) VALUES ('%s',
...), mysql_real_escape_string($username, $conn), ...);
step 4.
if(!$conn)
{
header(Location: http://website/dberror.html;);
exit;
}
else
{
mysql_select_db($database, $conn);
$insertqueryresult = mysql_query($insertquery);
if(!$insertqueryresult) {
header(Location: http://website/error.html;);
exit; }
}
with the above method i am able to insert values into the table even with if
i enter the ' special character which can cause problems.
i have also used a simple sql insert query like
$insertquery = INSERT INTO table(username, ...) VALUES ('$username', ...);
when i used this simple insert query and if i entered ' in the form and
submitted the form the php file is unable to process the information entered
because of the ' character and as per the code error.html file is being
displayed where as if i use
$insertquery = sprintf(INSERT INTO table (`username`, ...) VALUES ('%s',
...), mysql_real_escape_string($username, $conn), ...);
even if i enter any number of ' characters in more than 1 form field data is
being inserted into the table
a)
so i am thinking that the steps i have taken from the php site is correct
and the right way to avoid sql injection though there are several ways to
avoid sql injection.
b)
for example if i enter data in the form as = abc'''def for name, the data in
the table for the name field is being written as abc'''def
based on how i have written the steps to avoid sql injection is this the
right way for the data to be stored with ' characters along with the data
example as i mentioned = abc'''def
please answer the questions a) and b) if there is something else i need to
do please suggest what needs to be done exactly and at which step.
any help will be greatly appreciated.
thanks.
--
Los sabios buscan la sabiduría; los necios creen haberla encontrado.
Gabriel Sosa
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] SQL Injection protection
Hi Everyone, I have a application that I am writing for managing addresses on- line, I will have a fancy login system using sessions to help store the info, and to provide security for logging in. What I am wondering now, is if someone is willing to try and do some sql injection's on my database? Nothing that will kill the database, just basically try to insert something into it and to see if it lets you? I have tried with a article I found on phpsec.org and couldn't make it work, but I just want to double check with someone who has more experience. If you are interested, and knowledgeable, e-mail me off list so I can point you to the right place to try it. Thanks for looking! -- Jason Pruim Raoset Inc. Technology Manager MQC Specialist 3251 132nd ave Holland, MI, 49424 www.raoset.com [EMAIL PROTECTED]
Re: [PHP] SQL injection
Peter Lauri wrote: Thank you all for your replies; it has been interesting to read. I am just waiting for the webmaster to reply to me with his thoughts. My intentions for this were to help, not to break, so I do indeed hope that they will not take legal action for it. A friend of mine hoped that they would use the law against me, it would just increase the publicity for me, and that might increase the value of my services. And he was also sure that they would never win the case. I was for a while thinking about using my private yahoo email to not disclose my name, however, that felt like hiding for something you did not do. One at the forum sent me an message off the list and said: You got bigger balls than me. :-), what did he mean with that? he meant you have guts (more than him) to do what you did given the current sue-you-if-you-help attitude in IT land. (plenty of IT 'manager' types, the police, the FBI, you-name-it can't smell the difference between a whitehat and a blackhat - so they throw everyone on the blackhat pile) I did not know that the php list also shows the web cam at the same time. I better watch out... Best regards, Peter Lauri -Original Message- From: Peter Lauri [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 02, 2006 11:17 PM To: php-general@lists.php.net Subject: [PHP] SQL injection Hi all, I saw some strange error messages from a site when I was surfing it, and it was in form of SQL. I did some testing of the security of the SQL injection protection of that site, and it showed it was not that protected against SQL injections. To show this to them, I deleted my own record in their database after finding out the table name of the entity in the database. I also found out a lot of other that I think is important table names. What I did to them was to report this to them, and inform them about the damage I created, and what could have been done. (I did DELETE FROM tablename WHERE id=1234, what if I did DELETE FROM tablename, destruction if no backup). This is a large athletic site in Sweden, with more then 100,000 daily visitors. What I am a little bit worried about is the legal part of this; can I be accused of breaking some laws? I was just doing it to check if they were protected, and I informed them about my process etc. I only deleted my record, no one else's. In Sweden it might have been called computer break-in, but I am not sure. Anyone with experience of a similar thing? Best regards, Peter Lauri -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL injection
On 02/08/06, Jochem Maas [EMAIL PROTECTED] wrote: Russell Jones wrote: In real life terms, if you walked into the store and saw that the cash register was slightly broken and slightly opened, and reached in and pulled out a dollar to show the cashier what was wrong, you would not get in trouble. It may be bold, but it is not a crime. technically removing the dollar is a crime regardless of your intention. Even that depends where you are - in England Wales you wouldn't be guilty of theft as defined by the 1968 Theft Act: a person is guilty of theft if: he dishonestly appropriates property belonging to another with the intention of permanently depriving the other of it. So in that case the intent is very relevant. -robin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] SQL injection - Again
Hi, Is there anyone in this group that has a simple script to check for SQL injection attacks? In the theory I was thinking about to check $_POST and $_GET if they contain specific substrings that could be used in an attempt. Maybe to loop thru all set values and see if they contain DELETE FROM or TRUNCATE or similar. I am aware of that I can create different db-users to restrict this, but in some hosting cases I only have access to one db-user. I also always use sprintf() so make sure integers etc are used where I expect integers. /Peter
Re: [PHP] SQL injection - Again
On Thu, August 3, 2006 2:32 am, Peter Lauri wrote: Is there anyone in this group that has a simple script to check for SQL injection attacks? http://php.net/mysql_real_escape_string should cover this, no? Another option is to use a query mechanism based on prepared statements rather than raw queries, because then MySQL *knows* what is data and what is not data. In the theory I was thinking about to check $_POST and $_GET if they contain specific substrings that could be used in an attempt. Maybe to loop thru all set values and see if they contain DELETE FROM or TRUNCATE or similar. This is a Bad Idea because you could never possibly compose a complete list of all such substrings. I am aware of that I can create different db-users to restrict this, but in some hosting cases I only have access to one db-user. I also always use sprintf() so make sure integers etc are used where I expect integers. sprintf() to force an int is wasteful... $foo = (int) $_REQUEST['foo']; -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] SQL injection
Hi all, I saw some strange error messages from a site when I was surfing it, and it was in form of SQL. I did some testing of the security of the SQL injection protection of that site, and it showed it was not that protected against SQL injections. To show this to them, I deleted my own record in their database after finding out the table name of the entity in the database. I also found out a lot of other that I think is important table names. What I did to them was to report this to them, and inform them about the damage I created, and what could have been done. (I did DELETE FROM tablename WHERE id=1234, what if I did DELETE FROM tablename, destruction if no backup). This is a large athletic site in Sweden, with more then 100,000 daily visitors. What I am a little bit worried about is the legal part of this; can I be accused of breaking some laws? I was just doing it to check if they were protected, and I informed them about my process etc. I only deleted my record, no one else's. In Sweden it might have been called computer break-in, but I am not sure. Anyone with experience of a similar thing? Best regards, Peter Lauri
Re: [PHP] SQL injection
This is a good question and it, by and large, has not been considered. In this particular instance, their programming is not protected by any kind of encryption laws that would prevent decryption (such as developing and deploying the decryption of Adobe Ebooks format). Furthermore, because you reported the flaw directly to the webmaster and did not publish it, there is no way that you caused any meaningful damage, nor were you acting maliciously. I have exposed XSS errors before on Google via my blog, even wrote a program for April Fools that let you use XSS to post fake articles to real news sites, and never got in trouble for it. You did not even announce the error to the community, so you should be completely safe. In real life terms, if you walked into the store and saw that the cash register was slightly broken and slightly opened, and reached in and pulled out a dollar to show the cashier what was wrong, you would not get in trouble. It may be bold, but it is not a crime. On 8/2/06, Peter Lauri [EMAIL PROTECTED] wrote: Hi all, I saw some strange error messages from a site when I was surfing it, and it was in form of SQL. I did some testing of the security of the SQL injection protection of that site, and it showed it was not that protected against SQL injections. To show this to them, I deleted my own record in their database after finding out the table name of the entity in the database. I also found out a lot of other that I think is important table names. What I did to them was to report this to them, and inform them about the damage I created, and what could have been done. (I did DELETE FROM tablename WHERE id=1234, what if I did DELETE FROM tablename, destruction if no backup). This is a large athletic site in Sweden, with more then 100,000 daily visitors. What I am a little bit worried about is the legal part of this; can I be accused of breaking some laws? I was just doing it to check if they were protected, and I informed them about my process etc. I only deleted my record, no one else's. In Sweden it might have been called computer break-in, but I am not sure. Anyone with experience of a similar thing? Best regards, Peter Lauri
Re: [PHP] SQL injection
Russell Jones wrote: This is a good question and it, by and large, has not been considered. In this particular instance, their programming is not protected by any kind of encryption laws that would prevent decryption (such as developing and deploying the decryption of Adobe Ebooks format). Furthermore, because you reported the flaw directly to the webmaster and did not publish it, there is no way that you caused any meaningful damage, nor were you acting maliciously. I have exposed XSS errors before on Google via my blog, even wrote a program for April Fools that let you use XSS to post fake articles to real news sites, and never got in trouble for it. You did not even announce the error to the community, so you should be completely safe. In real life terms, if you walked into the store and saw that the cash register was slightly broken and slightly opened, and reached in and pulled out a dollar to show the cashier what was wrong, you would not get in trouble. It may be bold, but it is not a crime. technically removing the dollar is a crime regardless of your intention. with regard to find vulnerabilities you are, in the US atleast, technically at the mercy of the site owner as to whether legal action could be taken against you. read the following for at least 2 examples: http://www.securityfocus.com/news/11389/ one would hope sweden has less idiotic laws, and smarter IT managers. you did the site a service, and hopefully they are smart enough to see it that way. I would though in future, if you enjoy this kind of research, ask permission to examine a site's security from the owners to be safe. my personal opinion is that vulnerability research is a great game for nice people who are looking to get shafted in a big way. which is a sad state of affairs alround, but there you have it. On 8/2/06, Peter Lauri [EMAIL PROTECTED] wrote: Hi all, I saw some strange error messages from a site when I was surfing it, and it was in form of SQL. I did some testing of the security of the SQL injection protection of that site, and it showed it was not that protected against SQL injections. To show this to them, I deleted my own record in their database after finding out the table name of the entity in the database. I also found out a lot of other that I think is important table names. What I did to them was to report this to them, and inform them about the damage I created, and what could have been done. (I did DELETE FROM tablename WHERE id=1234, what if I did DELETE FROM tablename, destruction if no backup). This is a large athletic site in Sweden, with more then 100,000 daily visitors. What I am a little bit worried about is the legal part of this; can I be accused of breaking some laws? I was just doing it to check if they were protected, and I informed them about my process etc. I only deleted my record, no one else's. In Sweden it might have been called computer break-in, but I am not sure. Anyone with experience of a similar thing? Best regards, Peter Lauri -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL injection
Peter Lauri wrote: Hi all, I saw some strange error messages from a site when I was surfing it, and it was in form of SQL. I did some testing of the security of the SQL injection protection of that site, and it showed it was not that protected against SQL injections. To show this to them, I deleted my own record in their database after finding out the table name of the entity in the database. I also found out a lot of other that I think is important table names. What I did to them was to report this to them, and inform them about the damage I created, and what could have been done. (I did DELETE FROM tablename WHERE id=1234, what if I did DELETE FROM tablename, destruction if no backup). This is a large athletic site in Sweden, with more then 100,000 daily visitors. What I am a little bit worried about is the legal part of this; can I be accused of breaking some laws? I was just doing it to check if they were protected, and I informed them about my process etc. I only deleted my record, no one else's. In Sweden it might have been called computer break-in, but I am not sure. Anyone with experience of a similar thing? Best regards, Peter Lauri read http://shiflett.org/archive/236 -- life is a game... so have fun. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] SQL injection
Thank you all for your replies; it has been interesting to read. I am just waiting for the webmaster to reply to me with his thoughts. My intentions for this were to help, not to break, so I do indeed hope that they will not take legal action for it. A friend of mine hoped that they would use the law against me, it would just increase the publicity for me, and that might increase the value of my services. And he was also sure that they would never win the case. I was for a while thinking about using my private yahoo email to not disclose my name, however, that felt like hiding for something you did not do. One at the forum sent me an message off the list and said: You got bigger balls than me. :-), what did he mean with that? I did not know that the php list also shows the web cam at the same time. I better watch out... Best regards, Peter Lauri -Original Message- From: Peter Lauri [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 02, 2006 11:17 PM To: php-general@lists.php.net Subject: [PHP] SQL injection Hi all, I saw some strange error messages from a site when I was surfing it, and it was in form of SQL. I did some testing of the security of the SQL injection protection of that site, and it showed it was not that protected against SQL injections. To show this to them, I deleted my own record in their database after finding out the table name of the entity in the database. I also found out a lot of other that I think is important table names. What I did to them was to report this to them, and inform them about the damage I created, and what could have been done. (I did DELETE FROM tablename WHERE id=1234, what if I did DELETE FROM tablename, destruction if no backup). This is a large athletic site in Sweden, with more then 100,000 daily visitors. What I am a little bit worried about is the legal part of this; can I be accused of breaking some laws? I was just doing it to check if they were protected, and I informed them about my process etc. I only deleted my record, no one else's. In Sweden it might have been called computer break-in, but I am not sure. Anyone with experience of a similar thing? Best regards, Peter Lauri -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] SQL-Injection, XSS and Hijacking
Hello Mark, Where can I find these articles that you talk? do you have a URL for those articles? Thank you :) = ?Acaso se olvidara la mujer de su bebe, y dejara de compadecerse del hijo de su vientre? Aunque ellas se olviden, yo no me olvidare de ti Isa 40:27 = Atte Pedro Iran Mendez Perez -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Enviado el: Miercoles, 03 de Noviembre de 2004 04:25 p.m. Para: [EMAIL PROTECTED] Asunto: [PHP] SQL-Injection, XSS and Hijacking Hi, I read now quite a lot of articles about SQL-Injection, XSS and session hijacking in a hopefully appropriate way. As I understand the function addslashes(),quote_meta() and mysql_real_escape_string() are to avoid SQL Injection e.g. in order to use page_sliding with entered POST data over forms with $_REQUEST parameters, while strip_tags(), htmlentities() and utf8_decode() is useful to have a clean output within the browser by not having arbitrary code within. For a session authentication PEAR::Auth is used. I just wanted to ask if there's more to take care of. -- Best Regards, Mark -- 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
Re: [PHP] SQL-Injection, XSS and Hijacking
On Wed, 3 Nov 2004 19:02:22 -0800 (PST), Chris Shiflett [EMAIL PROTECTED] wrote: There is a lot more. I highlight some of the things I think are of principal concern for PHP developers in something I call the PHP Security Workbook: http://shiflett.org/php-security.pdf That doesn't cover everything, of course, but it covers those things I have chosen as most important when I only have three hours to talk about security concerns. :-) Chris, Many thanks for this link to your workbook. Really is a valuable read as it puts together the main security concerns. It helped me to see another point of view in some things. Just have to ask: Which method for data filtering you think is best for a modular site? the dispatch method (page 8) or the include method (page 10)? I specially like the dispatch method as I use my own private server (VPS) and have all modules outside the document root. This way, all scripts must be called by the dispatcher wich provides al security checks. As scripts are outside the document root, you cannot run them directly bypassing the dispatcher, and the security checks ... In my document root, the dispatcher is the only available script. Regards, Jordi. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL-Injection, XSS and Hijacking
--- Jordi Canals [EMAIL PROTECTED] wrote: I highlight some of the things I think are of principal concern for PHP developers in something I call the PHP Security Workbook: http://shiflett.org/php-security.pdf That doesn't cover everything, of course, but it covers those things I have chosen as most important when I only have three hours to talk about security concerns. :-) Chris, Many thanks for this link to your workbook. Really is a valuable read as it puts together the main security concerns. Thanks. :-) Which method for data filtering you think is best for a modular site? the dispatch method (page 8) or the include method (page 10)? First, let me point out that those aren't the only two choices. A lot of people avoid discussing software design with strangers, because many people are very passionate about their like or dislike of a particular approach. However, I risk it in my talks, because I think it's helpful for people to at least see a couple of brief overviews of some popular methods, in case there are characteristics that they like from either one. I think it's similar to how no one thinks XP is all great, but most people who study XP end up finding a few characteristics that they like (test-driven design perhaps). Personally, of those two that I mention in the PHP Security Workbook, I prefer the Dispatch Method. It does two things I like: 1. Completely removes the possibility of data being exposed via URL. The entry point to your application is very defined, and there is no other way in. 2. Makes it very easy for a developer to see the control flow of the entire application. You can't do this when looking through hundreds of lines of code. On the largest applications I have created (which consist of hundreds of thousands of lines of code), the dispatch.php script (or whatever you call it) is still rarely more than a hundred lines long. It is the overview - the blueprint. I think these characteristics help me as a developer to be mindful of security (it's easy to keep up with data flow as well), and I think these characteristics help me as a manager to be sure that my developers' mistakes are limited in the damage they can do. I specially like the dispatch method as I use my own private server (VPS) and have all modules outside the document root. This way, all scripts must be called by the dispatcher wich provides al security checks. As scripts are outside the document root, you cannot run them directly bypassing the dispatcher, and the security checks ... In my document root, the dispatcher is the only available script. Yeah, that's basically the first reason I mentioned. :-) I think the other reason is equally as strong. Hope that helps. Thanks for appreciating my work. Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly HTTP Developer's Handbook - Sams Coming February 2005http://httphandbook.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] SQL-Injection, XSS and Hijacking
Hi, I read now quite a lot of articles about SQL-Injection, XSS and session hijacking in a hopefully appropriate way. As I understand the function addslashes(),quote_meta() and mysql_real_escape_string() are to avoid SQL Injection e.g. in order to use page_sliding with entered POST data over forms with $_REQUEST parameters, while strip_tags(), htmlentities() and utf8_decode() is useful to have a clean output within the browser by not having arbitrary code within. For a session authentication PEAR::Auth is used. I just wanted to ask if there's more to take care of. -- Best Regards, Mark -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] SQL-Injection, XSS and Hijacking
Hi, look for escapeshellcmd(). It is another good function to minimize the security risks. http://in2.php.net/escapeshellcmd Zaeeef ahmed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, November 04, 2004 3:55 AM To: [EMAIL PROTECTED] Subject: [PHP] SQL-Injection, XSS and Hijacking Hi, I read now quite a lot of articles about SQL-Injection, XSS and session hijacking in a hopefully appropriate way. As I understand the function addslashes(),quote_meta() and mysql_real_escape_string() are to avoid SQL Injection e.g. in order to use page_sliding with entered POST data over forms with $_REQUEST parameters, while strip_tags(), htmlentities() and utf8_decode() is useful to have a clean output within the browser by not having arbitrary code within. For a session authentication PEAR::Auth is used. I just wanted to ask if there's more to take care of. -- Best Regards, Mark -- Zareef Ahmed :: A PHP develoepr in Delhi ( India ) Homepage :: http://www.zasaifi.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL-Injection, XSS and Hijacking
--- [EMAIL PROTECTED] wrote: I read now quite a lot of articles about SQL-Injection, XSS, and session hijacking in a hopefully appropriate way. As I understand the function addslashes(), quote_meta(), and mysql_real_escape_string() are to avoid SQL Injection The database-specific escaping functions are best. The addslashes() function should be considered a last resort if your database of choice has no escaping function particular to it. e.g. in order to use page_sliding with entered POST data over forms with $_REQUEST parameters I highly recommend not using $_REQUEST. Use $_GET and $_POST instead. strip_tags(), htmlentities() and utf8_decode() is useful to have a clean output within the browser by not having arbitrary code within. Yes, but the impotrant thing about all of these functions that you have mentioned is knowing when, how, and why to use them. For a session authentication PEAR::Auth is used. I need to review this sometime. I just wanted to ask if there's more to take care of. There is a lot more. I highlight some of the things I think are of principal concern for PHP developers in something I call the PHP Security Workbook: http://shiflett.org/php-security.pdf That doesn't cover everything, of course, but it covers those things I have chosen as most important when I only have three hours to talk about security concerns. :-) Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly HTTP Developer's Handbook - Sams Coming January 2005 http://httphandbook.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] SQL Injection check (mysql)
On Tue, 23 Mar 2004 12:05:17 -0800, Pablo Gosse wrote: I think you have misunderstod the concepts of making queries based on user input. It is not the users who should create the query, all to should do is provide the input to narrow down the queries. I have not misunderstood the concepts of making queries based on user input. I was here refering to my definition and not in general terms. It was not ment to offend anybody:-) 1) Hard coding a query into an application is good, if the situation permits it; True. 2) Letting a user select (or enter) a value(s) to be used in a query is good, as long as you validate the hell out of said value(s); Also true. 3) Letting a user arbitrarily enter unvalidated value(s) to be used in a query is very very stupid and very very bad, and done far too often. Again, true. In a broader scope I would here consider to be user input ANY input which is not hard coded into the application, and any input which is not hard coded should be thoroughly examined before being used. I agree. -- Hilsen/Regards Michael Rasmussen -- Kiss me, Kate, we will be married o' Sunday. -- William Shakespeare, The Taming of the Shrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] SQL Injection check (mysql)
snip The idea is exactly not to do any queries dynamically generated based on user input! In the rare cases where this is needed you should not allow any unparsed input. /snip A RARE case, in the world of web applications??? Hardly! I agree that in an optimal situation queries will not be based on user input, but in the world of the web this is a pipe dream. In 99.99% of the cases there will be some dynamic element to a query. The only safeguard is to validate the hell out of the data. P. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] SQL Injection check (mysql)
--- Michael Rasmussen [EMAIL PROTECTED] wrote: The idea is exactly not to do any queries dynamically generated based on user input! This argument still makes no sense to me. Originally, you stated that a better option to filtering and escaping data was to use a prepared statement. Some of us have decided that you are referring to stored procedures. You still have yet to defend your original statement in my mind. If there is no foreign data of any kind in a query, it doesn't really matter how the query is processed. For every other case (not as rare as you seem to think), data filtering is a must. Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly Coming Fall 2004 HTTP Developer's Handbook - Sams http://httphandbook.org/ PHP Community Site http://phpcommunity.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] SQL Injection check (mysql)
On Tue, 23 Mar 2004 08:25:32 -0800, Pablo Gosse wrote: A RARE case, in the world of web applications??? Hardly! I agree that in an optimal situation queries will not be based on user input, but in the world of the web this is a pipe dream. In 99.99% of the cases there will be some dynamic element to a query. The only safeguard is to validate the hell out of the data. I don't know which web applications you develop, but the ones I have be developing the last 10 years all user interaction was done thrue forms where users where asked specific question, and the input to these specific questions where used as input in prepared statements. Eg. select tuple1.table1, tuple1.table2, tuple3.table1 from table1, table2 where tuple1.table1 = tuple1.table2 and tuple1.table1=? and tuple3.table3? and so forth. In any case the users input where to be used in queries defined by the design of the application! I think you have misunderstod the concepts of making queries based on user input. It is not the users who should create the query, all to should do is provide the input to narrow down the queries. -- Hilsen/Regards Michael Rasmussen -- Beauty and harmony are as necessary to you as the very breath of life. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] SQL Injection check (mysql)
On Tue, 23 Mar 2004 09:27:29 -0800, Chris Shiflett wrote: This argument still makes no sense to me. Originally, you stated that a better option to filtering and escaping data was to use a prepared statement. Some of us have decided that you are referring to stored procedures. You still have yet to defend your original statement in my mind. If there is no foreign data of any kind in a query, it doesn't really matter how the query is processed. For every other case (not as rare as you seem to think), data filtering is a must. See my reply to Pablo Gosse. -- Hilsen/Regards Michael Rasmussen -- It was all so different before everything changed. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] SQL Injection check (mysql)
--- Michael Rasmussen [EMAIL PROTECTED] wrote: I think you have misunderstod the concepts of making queries based on user input. It is not the users who should create the query, all to should do is provide the input to narrow down the queries. To be honest, I think Pablo understands the concepts quite well, and you seem to have the misunderstanding. I'm happy to be wrong about this, but you'll need to explain yourself more instead of making these types of vague statements. As it is, I just don't buy your argument at all. How can user input only narrow down queries? Are you telling me that you've never had to write an application that had to store data originating from a foreign source? If so, that's fine, but don't use your inexperience to try to convince others that data filtering is unnecessary. If you're only talking about SELECT statements, that's also fine, but it's also rather irrelevant to the topic at hand (which might explain the confusion). Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly Coming Fall 2004 HTTP Developer's Handbook - Sams http://httphandbook.org/ PHP Community Site http://phpcommunity.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] SQL Injection check (mysql)
snip PG A RARE case, in the world of web applications??? Hardly! PG PG I agree that in an optimal situation queries will not be based on PG user input, but in the world of the web this is a pipe dream. In PG 99.99% of the cases there will be some dynamic element to a query. PG The only safeguard is to validate the hell out of the data. I don't know which web applications you develop, but the ones I have be developing the last 10 years all user interaction was done thrue forms where users where asked specific question, and the input to these specific questions where used as input in prepared statements. Eg. select tuple1.table1, tuple1.table2, tuple3.table1 from table1, table2 where tuple1.table1 = tuple1.table2 and tuple1.table1=? and tuple3.table3? and so forth. In any case the users input where to be used in queries defined by the design of the application! I think you have misunderstod the concepts of making queries based on user input. It is not the users who should create the query, all to should do is provide the input to narrow down the queries. /snip I have not misunderstood the concepts of making queries based on user input. I think the issue here is we all need to clarify what we're referring to as user input, because ultimately we are all saying the same thing. 1) Hard coding a query into an application is good, if the situation permits it; 2) Letting a user select (or enter) a value(s) to be used in a query is good, as long as you validate the hell out of said value(s); 3) Letting a user arbitrarily enter unvalidated value(s) to be used in a query is very very stupid and very very bad, and done far too often. In a broader scope I would here consider to be user input ANY input which is not hard coded into the application, and any input which is not hard coded should be thoroughly examined before being used. I've not misunderstood the concept, we're all saying the same thing, just in different ways. Cheers, Pablo -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection check (mysql)
On Sunday 21 March 2004 06:39 pm, Chris Shiflett wrote: --- Michael Rasmussen [EMAIL PROTECTED] wrote: To be clear: make sure the data that the user submitted only contains the characters you think are valid (don't bother trying to guess malicious characters - you're sure to miss one) and is a valid length. Once you've done this, and your design helps you to make sure that this step can't be bypassed by the user, you're protected against SQL injection. Or even better: Use only prepared statements. Can you explain that (and defend it)? Maybe he's talking about stored procedures? Banks, for instance, use stored procedures for all common operations. This provides a consistent and secure environment, and procedures can ensure that each operation is properly logged. In such a setup, applications and users would not get any access to the database tables directly, but may only execute specific stored procedures. - http://www.mysql.com/doc/en/Stored_Procedures.html Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly Coming mid-2004 HTTP Developer's Handbook - Sams http://httphandbook.org/ PHP Community Site http://phpcommunity.org/ -- Evan Nemerson [EMAIL PROTECTED] http://coeusgroup.com/en -- To achieve adjustment and sanity and the conditions that follow from them, we must study the structural characteristics of this world first and, then only, build languages of similar structure, instead of habitually ascribing to the world the primitive structure of our language. -Alfred Korzybski -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection check (mysql)
On 21 Mar 2004 Chris Shiflett wrote: I would never argue that something is an absolute defense, but I would characterize my recommendation as a best practice. Fair enough. I agree with you that checking for valid characters is safer than checking for malicious characters, but even the former is not absolute. Not absolute in what sense? Making sure something is valid is pretty absolute; Yes, agreed. It just that validation against input criteria doesn't guarantee that it's not an attack. the only possible flaws are flaws in making sure something is valid. For example, I feel confident that no one can show me a string that I would consider a valid first name that is also an SQL injection attack. I'm sure that's correct. However I'm not sure the algorithm to definitively decide which is which is so obvious. http://phundamentals.nyphp.org/PH_storingretrieving.php FYI, this site seems to be down. I've tried it several times over the last few days and it always times out. This doesn't work for everyone. I can think of several examples where users would be submitting HTML and/or PHP code. I wouldn't want to delete some of their data. Of course. I was only referring to my specific case, where that's not an issue. I applaud your efforts in data filtering, because almost all PHP vulnerabilities that I read about are a result of the author completely failing to perform any data filtering at all (which is inexcusable). However, might I suggest that you take a slightly different approach. Verify that the data is exactly what you expect it to be, and then escape and/or encode it when necessary. Just to clarify ... are you saying that you feel it's better to specifically validate and encode each field according to its own requirements rather than use a global algorithm? I can understand that ... right now I do both, global checks first followed by field-specific validation and encoding / escaping. For unvalidated data, do nothing with it until you have validated it with your data filtering logic. A good software architecture should make it easy for the developer to keep up with this (naming conventions are also very helpful for this). Good point on the naming conventions. I tend to keep the raw data in _POST and the validated data inside an array of control objects within my data entry form object, so the differentiation is structural rather than by name. This actually sounds like a strong approach to me. I assume that you surround all data in an SQL statement with single quotes (not just integer values). In fact, this is almost exactly what I am suggesting. I do not think you have an SQL injection vulnerability, unless what your code does strays from this description somehow. Yes, I use single quotes on everything. I was doing it only for strings and dates, but after reading some of the MySQL security info I added single quotes to the numeric values as well. Also, if your applications never allow the user to submit HTML or PHP, stripping tags is fine. But, you might be interested in letting your regular expression catch this, so that you can log attacks. Attackers certainly profile your applications - why not profile their attacks? It can potentially help us all. Good point ... but then I am vulnerable to errors in my own algorithm, I figured the folks writing PHP were likely to have more experience with it than I did. However it would be fairly easy to check if strip_tags did anything by comparing string lengths, and log the change if there was one. I also haven't looked at what this does to nested attacks of various kinds and whether there is a way to use multiple iterations or escapes in the input data to bypass the filtering (pointers to articles which discuss this would be welcome). The point of escaping or encoding would be lost if it didn't work for all possible data. I know of no articles for this, nor can I think of anyone who would bother writing one. :-) That's true, but as there is no mention in the documentation, I have no idea whether functions like mysql_escape_string properly handle things like strings which have already been escaped, whether strip_tags will take care of something like ttagag, and so on. stripslashes is specifically documented as handling only one round of backslashes -- do I need to call it in a loop? Thinking through whether this matters is tricky. In other words I can imagine classes of problems that the existing tools may or may not solve, and it's a bit of a chore to investigate so I was hoping someone else had already done so :-). Thanks for all of the comments. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection check (mysql)
On Sun, 21 Mar 2004 18:39:39 -0800, Chris Shiflett wrote:
Can you explain that (and defend it)?
The reason is security. A prepared statement cannot comprimize the
security of our database because all sql-statements are precompiled in the
DBMS. An example using pear:
$res = DB:connect('mysql://someuser:[EMAIL PROTECTED]/thedb');
$sth = $res-prepare('select * from sometable where id ?');
$sth-execute(10);
As the example demonstrates the request is hardcoded which means it cannot
be manipulated by any user supplied input. A beneficial side effect is
that all characters which need exscaping is automatically handled by the
DBMS. E.g the string O'leary would not cause any problems.
Another argument is, that it theoretically should run faster.
--
Hilsen/Regards
Michael Rasmussen
--
Be careful! Is it classified?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] SQL Injection check (mysql)
snip
The reason is security. A prepared statement cannot comprimize the
security of our database because all sql-statements are precompiled
in the DBMS. An example using pear:
$res = DB:connect('mysql://someuser:[EMAIL PROTECTED]/thedb');
$sth = $res-prepare('select * from sometable where id ?');
$sth-execute(10);
As the example demonstrates the request is hardcoded which means it
cannot be manipulated by any user supplied input. A beneficial side
effect is that all characters which need exscaping is automatically
handled by the DBMS. E.g the string O'leary would not cause any
problems.
/snip
Huh? How does this accommodate for a dynamically generated query which
is based upon user input?
For example,
$query = 'select p.name, a.location, p.editable ';
$query .= 'from cms_pages p, cms_areas a ';
$query .= 'where p.p_id = '.$p_id.' and p.a_id = a.a_id';
In this query the value against which p_id is tested would have to be
supplied by the user and as such would not be hard coded as in your
example above.
It is validated and its type set before it is inserted into the query,
so how does what you state above deal with this?
Cheers and TIA.
Pablo
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] SQL Injection check (mysql)
On Mon, 22 Mar 2004 14:36:44 -0800, Pablo Gosse wrote: Huh? How does this accommodate for a dynamically generated query which is based upon user input? Have you read my arguments? A prepared statement cannot be dynamically generated! It is validated and its type set before it is inserted into the query, so how does what you state above deal with this? The idea is exactly not to do any queries dynamically generated based on user input! In the rare cases where this is needed you should not allow any unparsed input. -- Hilsen/Regards Michael Rasmussen -- You have a will that can be influenced by all with whom you come in contact. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] SQL Injection check (mysql)
On 23 Mar 2004 Michael Rasmussen wrote: The idea is exactly not to do any queries dynamically generated based on user input! In the rare cases where this is needed you should not allow any unparsed input. There are some applications for which queries based on typed user input are rare. But there are others for which those queries are the basis of the whole application! Almost any kind of site where users are creating accounts and other data records (or their equivalents) will be like this, and that's a very common kind of web application. I agree that in these cases the input should be validated, I think that was the original topic of the thread. But I don't think you can call this rare as a general rule. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] SQL Injection check (mysql)
Hi I'm looking for a function To check SQL Injection in Mysql RDBMS please tell me if anyone know good function or solution thank's
Re: [PHP] SQL Injection check (mysql)
--- Ali Ashrafzadeh [EMAIL PROTECTED] wrote: I'm looking for a function To check SQL Injection in Mysql RDBMS please tell me if anyone know good function or solution In my opinion, this is the wrong approach. SQL injection vulnerabilities exist when you use data that the user gave you to create your SQL statement. So, anytime that this happens, simply make absolutely sure that the data you are using from the user fits a very specific format that you are expecting. To be clear: make sure the data that the user submitted only contains the characters you think are valid (don't bother trying to guess malicious characters - you're sure to miss one) and is a valid length. Once you've done this, and your design helps you to make sure that this step can't be bypassed by the user, you're protected against SQL injection. There is also a rather handy document available from NYPHP: http://phundamentals.nyphp.org/PH_storingretrieving.php This is good for describing magic_quotes and mysql_escape_string(). Hope that helps. Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly Coming mid-2004 HTTP Developer's Handbook - Sams http://httphandbook.org/ PHP Community Site http://phpcommunity.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection check (mysql)
On Sun, 21 Mar 2004 13:49:22 -0800, Chris Shiflett wrote: To be clear: make sure the data that the user submitted only contains the characters you think are valid (don't bother trying to guess malicious characters - you're sure to miss one) and is a valid length. Once you've done this, and your design helps you to make sure that this step can't be bypassed by the user, you're protected against SQL injection. Or even better: Use only prepared statements. -- Hilsen/Regards Michael Rasmussen -- Be cheerful while you are alive. -- Phathotep, 24th Century B.C. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection check (mysql)
--- Michael Rasmussen [EMAIL PROTECTED] wrote: To be clear: make sure the data that the user submitted only contains the characters you think are valid (don't bother trying to guess malicious characters - you're sure to miss one) and is a valid length. Once you've done this, and your design helps you to make sure that this step can't be bypassed by the user, you're protected against SQL injection. Or even better: Use only prepared statements. Can you explain that (and defend it)? Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly Coming mid-2004 HTTP Developer's Handbook - Sams http://httphandbook.org/ PHP Community Site http://phpcommunity.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection check (mysql)
On 21 Mar 2004 Chris Shiflett wrote: SQL injection vulnerabilities exist when you use data that the user gave you to create your SQL statement. So, anytime that this happens, simply make absolutely sure that the data you are using from the user fits a very specific format that you are expecting. To be clear: make sure the data that the user submitted only contains the characters you think are valid (don't bother trying to guess malicious characters - you're sure to miss one) and is a valid length. Once you've done this, and your design helps you to make sure that this step can't be bypassed by the user, you're protected against SQL injection. Recently I've been in the middle of trying to build defenses against SQL injection on a site I'm working on (proactively, we haven't had a problem). While this principle seems exactly right, I find it's not as easy to implement as it sounds, and I'd argue that the results aren't as absolute as you suggest, though you certainly have more experience with it than I do so perhaps I'm missing something. Here's how I'm looking at it. Pretty much any useful site tied to a database will use user data in SQL statements, either in WHERE clauses or SET clauses or both. This means all input must be checked for maliciousness, and the primary kinds of malicious input seem to be SQL injection, or on another front HTML injection / XSS. The problem is that there are some well-defined attacks with protections against them that can be logically defended. But there is no list of all possible attacks, so I'm not sure it's really possible to say you're protected against SQL injection at some point. Do you feel differently? If so I'd be interested to hear why. I agree with you that checking for valid characters is safer than checking for malicious characters, but even the former is not absolute. Also it is not possible to make the set of characters with syntactic significance have no overlap with the set of valid input characters -- a single quote used as an apostrophe is the obvious example, so checking for valid characters may still leave characters in the data that could also be part of an attack. As for specifics, at the moment I am simply forcing every element of _POST to be truncated to a known maximum length, then run through strip_tags, stripslashes, and htmlspecialchars (in that order) before I use it. Then every input form element is validated against an appropriate regexp depending on the type of input expected. I also use mysql_real_escape_string on all strings prior to writing them to the database, and I use single quotes around all integer values. If you're game, I'm curious if you see any flaws in this approach. I am still contemplating whether there is any value to running input through htmlspecialchars, or whether I should instead simply be using htmlentities on output. I also haven't looked at what this does to nested attacks of various kinds and whether there is a way to use multiple iterations or escapes in the input data to bypass the filtering (pointers to articles which discuss this would be welcome). Thanks, -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection check (mysql)
--- [EMAIL PROTECTED] wrote: Recently I've been in the middle of trying to build defenses against SQL injection on a site I'm working on (proactively, we haven't had a problem). While this principle seems exactly right, I find it's not as easy to implement as it sounds, and I'd argue that the results aren't as absolute as you suggest, though you certainly have more experience with it than I do so perhaps I'm missing something. I would never argue that something is an absolute defense, but I would characterize my recommendation as a best practice. The problem is that there are some well-defined attacks with protections against them that can be logically defended. But there is no list of all possible attacks, so I'm not sure it's really possible to say you're protected against SQL injection at some point. Do you feel differently? If so I'd be interested to hear why. The reason why is the difference in approach. If any approach depends on exhaustive knowledge of all possible attacks, the approach is fundamentally flawed and could never be considered secure. There is only one you, and there are an unlimited number of potential attackers. You cannot hope to second guess every single one of them. I agree with you that checking for valid characters is safer than checking for malicious characters, but even the former is not absolute. Not absolute in what sense? Making sure something is valid is pretty absolute; the only possible flaws are flaws in making sure something is valid. For example, I feel confident that no one can show me a string that I would consider a valid first name that is also an SQL injection attack. Also it is not possible to make the set of characters with syntactic significance have no overlap with the set of valid input characters -- a single quote used as an apostrophe is the obvious example, so checking for valid characters may still leave characters in the data that could also be part of an attack. I would never suggest that you should not escape data properly according to your database of choice. In fact, I included a very helpful link that addresses this, and I will include it again: http://phundamentals.nyphp.org/PH_storingretrieving.php If you are using MySQL, there is a nice function that escapes your data for you: http://www.php.net/mysql_escape_string If you make sure data is valid and then properly escape it for use in an SQL statement, you're adhering to what I am suggesting is a best practice against SQL injection. This is under the assumption that you surround all literal values with single quotes. As for specifics, at the moment I am simply forcing every element of _POST to be truncated to a known maximum length, then run through strip_tags, stripslashes, and htmlspecialchars (in that order) before I use it. This doesn't work for everyone. I can think of several examples where users would be submitting HTML and/or PHP code. I wouldn't want to delete some of their data. I applaud your efforts in data filtering, because almost all PHP vulnerabilities that I read about are a result of the author completely failing to perform any data filtering at all (which is inexcusable). However, might I suggest that you take a slightly different approach. Verify that the data is exactly what you expect it to be, and then escape and/or encode it when necessary. For example, for storing valid data, use mysql_escape_string() or an equivalent function for your database of choice. For displaying valid data, use htmlentities(). If you want some user-submitted tags interpreted, you can use str_replace() to convert those HTML entities back (this makes sure that only specific uses of specific tags are interpreted). For unvalidated data, do nothing with it until you have validated it with your data filtering logic. A good software architecture should make it easy for the developer to keep up with this (naming conventions are also very helpful for this). Then every input form element is validated against an appropriate regexp depending on the type of input expected. I also use mysql_real_escape_string on all strings prior to writing them to the database, and I use single quotes around all integer values. If you're game, I'm curious if you see any flaws in this approach. I'm always game. :-) This actually sounds like a strong approach to me. I assume that you surround all data in an SQL statement with single quotes (not just integer values). In fact, this is almost exactly what I am suggesting. I do not think you have an SQL injection vulnerability, unless what your code does strays from this description somehow. Also, if your applications never allow the user to submit HTML or PHP, stripping tags is fine. But, you might be interested in letting your regular expression catch this, so that you can log attacks. Attackers certainly profile your applications - why not profile their attacks? It can potentially help us all. I am still contemplating
Re: [PHP] SQL injection
Hi i read many thing on sql injection but i just cant sumarize all the information. Most site (PHPadvisory.com, phpsecure.info, other found on google) dont talk to mutch on how to prevent SQL injection. One of the things I tend to do to limit any damage is tell the backend SQL server to not let the web user execute things like drop table. Ie, limit the allowed commands to select, insert, update, delete. Yes, data can be messed with, but it's just another layer of protection. Combined with proper quoting of input, and making sure that numeric input is numeric etc, life is reasonably sane. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] SQL injection
Hi i read many thing on sql injection but i just cant sumarize all the information. Most site (PHPadvisory.com, phpsecure.info, other found on google) dont talk to mutch on how to prevent SQL injection. At some place, they mentionned having a badword list, but really in a product description we can have about anyword (select, insert, update, ...) SO the badword liste is not really the solution i believe. I did the fallowing single quoted all the queries, parameters (even if numerical), did a mysql_real_eascape_string on all parameters befor they are passed to mysql. Also my Queries are always fairly long and no queries and by a parameter (at least i try not too) Do you guys have any other tips ? Thanks Yann -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL injection
Yann Larrivee wrote: Hi i read many thing on sql injection but i just cant sumarize all the information. Most site (PHPadvisory.com, phpsecure.info, other found on google) dont talk to mutch on how to prevent SQL injection. At some place, they mentionned having a badword list, but really in a product description we can have about anyword (select, insert, update, ...) SO the badword liste is not really the solution i believe. I did the fallowing single quoted all the queries, parameters (even if numerical), did a mysql_real_eascape_string on all parameters befor they are passed to mysql. This is pretty easy to prevent. You only need to be aware of two things, which I think you've already got. 1. You need to escape quotes in strings you pass to SQL queries. That means if you're passing a string delimited by single quotes, then single quotes must be escaped within that string (by whichever method is required by your database). $query = UPDATE Table SET column = '$value'; Since column is being passed a string delimited by single quotes (within the SQL, not within PHP!), all single quotes within $value must be escaped. addslashes() or mysql_real_escape_string() are two methods for accomplishing this. 2. If you're passing a value that is not within quotes, you must ensure the value is actually a number. This is most easily done by casting the value to an (int) or (float). $query = UPDATE Table SET column = . (int)$value; Using (int) or (float) will ensure value is a number and cannot contain any SQL injection attacks. Of course, you'll want to do this conversion, escaping, etc, in your validation functions. :) -- ---John Holmes... Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/ php|architect: The Magazine for PHP Professionals www.phparch.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL injection
On Mon, 23 Jun 2003 08:59:56 +0300, you wrote: Is there any way, doc, article, example, idea, suggestion to how to prevent sql injection on php sites... It's really not that hard to do. Rule 1: Never trust the client This means validating all data that comes from the client - make sure that integers are really integers, dates are really dates and in the correct range, etc etc. Never rely on Javascript alone to do this. But this is just good practice - you should be doing this kind of server-side validation already. Most importantly, escape any client-generated data before passing to your database. Eg use mysql_real_escape_string() for MySQL. In addition, your PHP scripts should be connecting to the database as a user with minimal permissions - eg they shouldn't have permission to delete data, drop tables, etc. unless they really need it. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] SQL injection
Hi, Is there any way, doc, article, example, idea, suggestion to how to prevent sql injection on php sites... http://www.nextgenss.com/papers/advanced_sql_injection.pdf http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf Kirk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] SQL injection
Hi, Is there any way, doc, article, example, idea, suggestion to how to prevent sql injection on php sites... Thanks -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] SQL Injection/Data Balidation
Please CC me as I'm on digest:
--
Are there any libraries for data validation available? If one reads
papers like these:
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf
It becomes apparent that sites using databases are incredibly open to
attack because of the ingenuity of the attackers. I think there should
be a PHPGuardLib or something. After reading those articles, I plan on
filtering ALL input for semi-cololons and 'chr(' character strings. In
the cases where I want to accept apostrophes, I'm going to be very
careful.
Also, are there any attacks to email programs on linux that can be done
through input forms?
PS, for those who think escaping user input only on apostrophes, THINK
AGAIN! And read the aticles above.
--
If You want to buy computer parts, see the reviews at:
http://www.cnet.com/
**OR EVEN BETTER COMPILATIONS**!!
http://sysopt.earthweb.com/userreviews/products/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection/Data Balidation
Yeah, I'm scared...
Please excuse me but may I say that it seems like you've sent some wrong
info to the wrong mailing list?
I use PHP NOT ASP, I use MySQL or PostgreSQL or Oracle but NOT M$ SQL
Server. And IIS? Of course, some people use it (perhaps) because of some
unavoidable circumstances but I don't--I use Apache NOT IIS.
Of course, there's nothing bad about being cautious... However, please send
some links (or documents) that are more relevant...
Thanks anyway, now *I* have something to scare my friends... ;)
- E
Please CC me as I'm on digest:
--
Are there any libraries for data validation available? If one reads
papers like these:
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf
It becomes apparent that sites using databases are incredibly open to
attack because of the ingenuity of the attackers. I think there should
be a PHPGuardLib or something. After reading those articles, I plan on
filtering ALL input for semi-cololons and 'chr(' character strings. In
the cases where I want to accept apostrophes, I'm going to be very
careful.
Also, are there any attacks to email programs on linux that can be done
through input forms?
PS, for those who think escaping user input only on apostrophes, THINK
AGAIN! And read the aticles above.
--
If You want to buy computer parts, see the reviews at:
http://www.cnet.com/
**OR EVEN BETTER COMPILATIONS**!!
http://sysopt.earthweb.com/userreviews/products/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
_
MSN Hotmail è il provider email più grande al mondo
cosa aspetti a farti un
account? http://www.hotmail.it
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection/Data Balidation
I didn't see that, what a waste of paper
Randy
- Original Message -
From: Edwin @ [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, August 16, 2002 1:14 PM
Subject: Re: [PHP] SQL Injection/Data Balidation
Yeah, I'm scared...
Please excuse me but may I say that it seems like you've sent some wrong
info to the wrong mailing list?
I use PHP NOT ASP, I use MySQL or PostgreSQL or Oracle but NOT M$ SQL
Server. And IIS? Of course, some people use it (perhaps) because of some
unavoidable circumstances but I don't--I use Apache NOT IIS.
Of course, there's nothing bad about being cautious... However, please
send
some links (or documents) that are more relevant...
Thanks anyway, now *I* have something to scare my friends... ;)
- E
Please CC me as I'm on digest:
--
Are there any libraries for data validation available? If one reads
papers like these:
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf
It becomes apparent that sites using databases are incredibly open to
attack because of the ingenuity of the attackers. I think there should
be a PHPGuardLib or something. After reading those articles, I plan on
filtering ALL input for semi-cololons and 'chr(' character strings. In
the cases where I want to accept apostrophes, I'm going to be very
careful.
Also, are there any attacks to email programs on linux that can be done
through input forms?
PS, for those who think escaping user input only on apostrophes, THINK
AGAIN! And read the aticles above.
--
If You want to buy computer parts, see the reviews at:
http://www.cnet.com/
**OR EVEN BETTER COMPILATIONS**!!
http://sysopt.earthweb.com/userreviews/products/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
_
MSN Hotmail è il provider email più grande al mondo. cosa aspetti a farti
un
account? http://www.hotmail.it
--
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
Re: [PHP] SQL Injection/Data Balidation
Actually, I DID read the articles before I replied. If you read it again, the basic problem is not about any extended SQLServer functionality--it's about how ASP works AND how the database server was configured AND how Window$ works. Sorry, but the attacks mentioned CANNOT be done on any of the database servers that I've used. And with PHP, Apache, Linux combination, they just don't apply. Hey, don't get me wrong. I really appreciate any security info but personally I don't think they apply here... - E HINT: PHP doesn't use another ' (single quote) character to escape another single quote character--it's just basically stupid to do so. HINT 2: Configure your database server to have, for example, (1) a database username/password that can only SELECT -- enough for dynamically generated pages (2) a username/password that can only do INSERT or UPDATE, etc. Why would I make a username/password for my web pages that can delete important table or the entire database itself? If you'll thoroughly read the articles, most of those attacks that don't involve the use of extended SQLServer functionality, CAN be done on other RDBMS's. And if nothing else, you'll see the ingenuity of the attackers. Hey, take what you liked, and leave the rest lay. -- If You want to buy computer parts, see the reviews at: http://www.cnet.com/ **OR EVEN BETTER COMPILATIONS**!! http://sysopt.earthweb.com/userreviews/products/ _ Charle con sus amigos online usando MSN Messenger: http://messenger.msn.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection/Data Balidation
Oops! Sorry! I meant to say apostrophe and not single quotes... And sorry 'bout this additional post... Regards, - E Actually, I DID read the articles before I replied. If you read it again, the basic problem is not about any extended SQLServer functionality--it's about how ASP works AND how the database server was configured AND how Window$ works. Sorry, but the attacks mentioned CANNOT be done on any of the database servers that I've used. And with PHP, Apache, Linux combination, they just don't apply. Hey, don't get me wrong. I really appreciate any security info but personally I don't think they apply here... - E HINT: PHP doesn't use another ' (single quote) character to escape another single quote character--it's just basically stupid to do so. HINT 2: Configure your database server to have, for example, (1) a database username/password that can only SELECT -- enough for dynamically generated pages (2) a username/password that can only do INSERT or UPDATE, etc. Why would I make a username/password for my web pages that can delete important table or the entire database itself? If you'll thoroughly read the articles, most of those attacks that don't involve the use of extended SQLServer functionality, CAN be done on other RDBMS's. And if nothing else, you'll see the ingenuity of the attackers. Hey, take what you liked, and leave the rest lay. -- If You want to buy computer parts, see the reviews at: http://www.cnet.com/ **OR EVEN BETTER COMPILATIONS**!! http://sysopt.earthweb.com/userreviews/products/ _ Charle con sus amigos online usando MSN Messenger: http://messenger.msn.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php _ Charle con sus amigos online usando MSN Messenger: http://messenger.msn.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
