Jump to content

Odd...or not?


avenged

Recommended Posts

ok, so I am trying to write a function that gets the string from POST vars and checks to see whether it is an SQL injection...anyways. So i'm testing it, and i'm using sample SQL injection queries, going as far as to hard code the SQL injection queries into my code. Then, and only then, is it actually working (the SQL injection). I could not figure out why my POST vars weren't giving the right comand...until I echoed them out, directly from input. It's strange (or not), that I found that they are automatically escaped? Meaning, if I wanted to input a query ' OR 1=1 -- ' It would echo out the POST variable (straight from input) all escaped and everything. Can anyone explain to me why this is happening? I checked my php.ini, and i'm not sure, but does this have anything to do with magic_quotes_gpc? I looked in there, changed almost every value of magic_quotes to Off, yet it still is automatically escaping POST vars. How is it doing this, as I thought SQL injection was a very important thing to catch, or is this just a feature of PHP 5?
Link to comment
Share on other sites

this is not odd at all, and in fact is the norm since PHP whatever.version.they.changed.it.at.

the setting that controls this activity is in php.ini, and is called magic_quotes_gpc. if it is set to 1 (or on), it automatically escapes "dangerous" characters in the GET, POST and COOKIE data sent to the server (also known as the REQUEST data).

in order to detect the current magic_quotes_gpc setting, use get_magic_quotes_gpc() function. this should tell you whether or not your data is already escaped and consequently what to do from there. check the manual for return values.
Link to comment
Share on other sites

[!--quoteo(post=361833:date=Apr 4 2006, 11:02 PM:name=cunoodle2)--][div class=\'quotetop\']QUOTE(cunoodle2 @ Apr 4 2006, 11:02 PM) [snapback]361833[/snapback][/div][div class=\'quotemain\'][!--quotec--]
Please post your code on here so we can take a look at it.
[/quote]

lol, i said it was just a basic echoing of POST vars straight from input, meaning echoing $_POST vars from a form....but if you need code for that, here...
[code]
<?php
if(isset($_POST['login_test']))
{
   echo $_POST['username'] ."<br>";
   echo $_POST['password'] ."<br>";

}
echo "
<br>
<form action=\"$self\" method=\"post\">
username
<input type=\"text\" name=\"username\">
<br>
password
<input type=\"text\" name=\"password\">
<br>
<input type=\"submit\" name=\"login_test\">
</form>
";
?>
[/code]

and to akitchin, then what is the point of validating input, in regards to SQL injection, if values in POST vars are already escaped? it would mean that, basicly, SQL injection isn't possible....right?
Link to comment
Share on other sites

in my experience, the automatic escaping is sufficient to avoid injection attacks. however, some security nuts will attest that it isn't (likely due to some special unescaped characters?). i couldn't tell you why it isn't sufficient, you'd have to look that up yourself if you're interested.

what i do know is that you cannot take this setting for granted - it will not always be on. in the interest of good development, i would make your own escaping function that either adds slashes if magic_quotes_gpc is not on, or leaves it as is if the setting is on.
Link to comment
Share on other sites

[!--quoteo(post=361846:date=Apr 4 2006, 11:16 PM:name=akitchin)--][div class=\'quotetop\']QUOTE(akitchin @ Apr 4 2006, 11:16 PM) [snapback]361846[/snapback][/div][div class=\'quotemain\'][!--quotec--]
in my experience, the automatic escaping is sufficient to avoid injection attacks. however, some security nuts will attest that it isn't (likely due to some special unescaped characters?). i couldn't tell you why it isn't sufficient, you'd have to look that up yourself if you're interested.

what i do know is that you cannot take this setting for granted - it will not always be on. in the interest of good development, i would make your own escaping function that either adds slashes if magic_quotes_gpc is not on, or leaves it as is if the setting is on.
[/quote]

i do have a function that does just that. but what I also find weird is the SQL injection detection function (uses regex) finds an SQL injection attack. heres the function:
[code]
      function checkInput($str)
      {
         $str = strtolower($str);
         //pattern for SQL injection type 'OR 1=1
         $pattern = "/^ *(\'|\")? *(or|and) *\'|\"? *[a-z0-9]* *\'|\"? *(=|<|>|<>) *\'|\"? *[a-z0-9]* *\'|\"? *-*/";
         if(preg_match($pattern, $str))
         {
            //.......log it
         }      
      }
[/code]
now, if im not mistaken, shouldnt the function not return the preg_match if the POST vars are already escaped??? whats weird is it IS returning a preg_match if I insert it correctly. This is how I use the function:
[code]
$text = checkInput($_POST['username']);
[/code]

Shouldn't this not even return a valid preg_match, if everything is already escaped?? my regex doesnt check for escaped characters, yet it still returns true....how?
Link to comment
Share on other sites

well it's been a little while since i've used regex, but when you're using double quote delimiters, php doesn't actually consider \' as escaping. it treats them both as literals, since ' doesn't need escaping in a double-quote delimited file.

can't remember how preg_match() would deal with the backslash, so i couldn't tell you for sure. maybe try sending it with double quotes (ie. "OR 1=1) and see if it still logs.
Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.