Forum Moderators: coopster
GET * name : \' or 1=1
GET * name : \" or 1=1--
GET * name : \' or \'a\'=\'a
GET * name : \" or \"a\"=\"a
GET * startrow : \' or 1=1
GET * startrow : \" or 1=1--
GET * name : \') or (\'a\'=\'a
GET * startrow : \" or \"a\"=\"a
GET * startrow : \') or (\'a\'=\'a
GET * req : \' or 1=1
GET * req : \" or 1=1--
GET * lid : \" or 1=1--
GET * lid : \') or (\'a\'=\'a
GET * sid : \' or 1=1
GET * sid : \" or 1=1--
GET * topic : \" or 1=1--
GET * op : \" or 1=1--
GET * topic : \" or \"a\"=\"a
GET * module : \') or (\'a\'=\'a
You know, after looking at these after I pasted them here, they look awfully like sql injection attempts. what do you guys think?
> sql injection attempts
Definitely. Worth re-reading every so often, the php manual section on sql injection attacks [us2.php.net].
Any other attack attempts? They try to sneak in any <script> elements?
GET * module : </title><ScRiPt
>alert(40546,9847403009);</ScRiPt>
GET * func : search
GET * tplview : default
GET * viewtype : day
GET * Date : 20080205000000
GET * pc_username : 111-222-1933email@address.com
GET * pc_category : 111-222-1933email@address.com
GET * pc_topic : 111-222-1933email@address.com
GET * print : 1
------------------------------------------------
and heres another.
GET * name : <DIV
STYLE=\"width:expression(alert(40497,9839767708));\">
GET * action : search
GET * active_stories : 1
GET * stories_author :
111-222-1933email@address.com
GET * stories_cat%5B%5D :
111-222-1933email@address.com
GET * stories_topics%5B%5D :
111-222-1933email@address.com
GET * bool : AND
GET * q : 111-222-1933email@address.com
GET * startnum : 11
GET * total : 80
---------------------
they even tampered with the COOKIE!
COOKIE * POSTNUKESID : </textarea><ScRiPt
>alert(40409,9832515856);</ScRiPt>
When I started coding I had always thought that the \ was the correct escape character, however it appears that I am wrong for the generic SQL standards. The generic SQL says that quotes should be escaped by doubling them up, so ' becomes '' and " becomes "". While that is not so interesting the reason for not using \ as the escape character is quite interesting.
This problem with all multibyte characters was reported in postgresql a while ago. However the problem has also been reported in mysql and in theory resides in every sql complaint database.
There are loads of links but the only one I could quickly find that I can post on the forum was -
[postgresql.org...]
Have a read of it as it is quite interesting that people may well be able to break into a database simply by using a multibyte character.
Both mysql and postgresql have been updated so that this problem is lessened. Although this is a good reason for using prepaired statements and mysql_real_escape_string (or the appropriate database specific escape_string function).
For those that are not as successful at stopping attacks have a look at the Improved mysql functions [us3.php.net].
//bad objects
$search = array('¦</?\s*SCRIPT.*?>¦si',
'¦</?\s*FRAME.*?>¦si',
'¦</?\s*OBJECT.*?>¦si',
'¦</?\s*META.*?>¦si',
'¦</?\s*APPLET.*?>¦si',
'¦</?\s*LINK.*?>¦si',
'¦</?\s*IFRAME.*?>¦si',
'¦STYLE\s*=\s*"[^"]*"¦si',
'¦cc:¦si',
'¦bcc:¦si',
'¦to:¦si',
'¦content-type:¦si',
'¦mime-version¦si',
'¦multipart/mixed¦si',
'¦content-transfer-encoding:¦si',
'¦\.exe¦si');
$replace = array(''); //replace with empty string
$var = preg_replace($search, $replace, $var); //removing bad objects
return $var;
}