Who needs input validation anyway
-
When you go to bootbarn and select 12-size wide men's boots here
http://www.bootbarn.com/multiview/men/bootsshoes/view/view/0/48/popular/All?size=12.0&width=Wides
you get this output:
<FONT face="Courier New" color=#ff0000>DBD::mysql::st execute failed: You have an error in your SQL syntax near 'AND i.item_id = ix.item_id AND (ix.stock_avail = 'X' OR ix.stock_avail > 0) ' at line 13 at /www/bootbarn.com/htdocs/libraries/multiview-tags.psp line 227.</FONT>
Viewing the source, however, reveals something even SCARIER than that snippet in production output:
--><!--QUERY
SELECT DISTINCT
i.item_id,
i.local_id,
i.description,
i.price,
i.thumbnail_img,
i.detail_page_img,
i.sale_status_id
FROM inventory_items i, inventory_status ix , families f, families_to_styles fs
WHERE i.suppress = 'n'
AND f.family_id = i.family_id AND f.family_id = fs.family_id AND fs.category_id = ? AND ( ix.size = ? ) AND ( ix.width = ? OR
AND i.item_id = ix.item_id
AND (ix.stock_avail = 'X' OR ix.stock_avail > 0)
ORDER BY i.best_seller_sum DESC, i.last_updated
-
Awesome!
Drop database, anyone?
-
Good Lord!
-
@Savior said:
Awesome!
Drop database, anyone?
While I understand that this gives us way more information than we
should have about the structure of their database, how exactly would
one use this to actually execute a malicious bit of SQL?
-
Oh, and I'd like to thank you and your avatar for making this site significantly less work safe. </sarcasm> :)
-
@UncleMidriff said:
Oh, and I'd like to thank you and your
All i can say is thank goodness for adblock.
avatar for making this site significantly less work safe.
:)
-
@UncleMidriff said:
Oh, and I'd like to thank you and your avatar for making this site significantly less work safe. </SARCASM> :)
Hopefully emptyset will stop to use his mother's connection to the internet and completely drop this site. After that I'll vanish into the darkness...
Of course, after Richard Nixon does the same as emptyset... [*-)]
-
@UncleMidriff said:
@Savior said:
Awesome!
Drop database, anyone?
While I understand that this gives us way more information than we
should have about the structure of their database, how exactly would
one use this to actually execute a malicious bit of SQL?
That's relatively easy; all you have to do is upload a new file
containing malicious SQL statements to their server which you can then
request with your average garden-variety browser and thereby cause the
web server to execute your 'drop database' statement.
-
Thanks for backing me up.
I really think this forum software should show all the messages on a thread while replying, so you don't have to put multiple replies to multiple posts.
-
@Joost_ said:
Forgive me for being pedantic but if i can upload stuff cant i just call mysql_list_dbs() with mysql_list_tables() and work our way from there droping the tables ?
That's relatively easy; all you have to do is upload a new file
containing malicious SQL statements to their server which you can then
request with your average garden-variety browser and thereby cause the
web server to execute your 'drop database' statement.
-
Possible forgotten leftover SQL bugzapping.
Hm.
Adjective Verbadjective Adjective Noun Gerund
It's a sentence.
Quite.
-
How to use it to execute a malicious bit of SQL?
I'll leave that for SQL Injection Attacks by Example to answer.
-
@UncleMidriff said:
how exactly would
one use this to actually execute a malicious bit of SQL?
I think someone else gave you a link. I didn't click it but in
case that didn't explain it, SQL statements are separated by
semicolons. If the programmer was dumb enough to just take
whatever input you give him, and use it in a SQL statement without any
kind of validation, without escaping things like quotes and semicolons,
then you can drop a semicolon in there (most likely after a closing
quote) and follow it with whatever SQL you want - - - and the server
will happily execute it.
Where I work, we get probably 50 or 60 such attacks a day. Most
of them are from automated hacking scripts apparently because they come
in really fast, one right after the other. What really cracks me
up when I'm looking at the logs is when I see one with an actual
error. I mean, the guy is trying to hack me and he's not even
sending valid SQL! I know, he's probably just a script kiddie and
he doesn't understand the code he's using. It's still funny.
-
Thanks for the explaination and to the previous poster for the link.
I understand how SQL injection works, but that wasn't my question. What I'm curious about is how a malicious person could use the information given in the error message and in the page source to actually execute a SQL injection attack. Certainly, the error message and the commented-out SQL statement in the page source give the malicious person a whole lot of information that he shouldn't have, but it still doesn't provide him with a mechanism to execute his own SQL statement, does it?
-
Well, the question marks in the SQL are the places were the input
params are plugged in. One thing I failed to mention in my post
above is that the whole statement, that is, both the original and the
injected SQL, has to be a valid statement. Here's an example that
doesn't use SQL - because I don't want to be accused of showing someone
how to hack a particular site.
Let's say you have some code that builds up a sentence instead of a SQL statement. The sentence is:
George Bush is a _____ president.
The user is then shown an html form where they get to select "good" or
"bad" from a dropdown list. So, when they submit the form, you
the programmer are expecting to get back either the string "good" or
the string "bad." And being a lazy SOB, you just copy that into
the sentence without checking it at all.
sentence = "George Bush is a " + inputparam + " president."
So what the evil hacker does is to edit the form so that instead of
sending "good" or "bad" it sends, "Delete all posts on thedailywtf.com!"
The problem, you see, is that the new hacked sentence isn't valid
grammatically. And the problem for a real world hacker is that
the new SQL isn't going to be valid syntactically. The hacked
sentence is:
George Bush is a Delete all posts on thedailywtf.com! president.
So, if you're the hacker, how do you make that sentence grammatically
valid? The answer is, you need more info about the target.
If you could somehow see the source code, then you would know exactly
what you need to do. In this case, you need to make the form
send, "loser. Delete all posts on thedailywtf.com! Cheney is"
Understand? See, now the completed sentence is:
George Bush is a loser. Delete all posts on thedailywtf.com! Cheney is president.
That is grammatically correct. That is a complete SQL injection attack.
Where I work, we never ever ever show a SQL error to the user.
(we also check our inputs, but sometimes things are going to slip
through) Most of the time, when I see an attack in the logs, the
hacker was trying to insert something like "user is not null"
just to see if they can get away with it. That's never going to
work because I don't have any columns anywhere that are named
user. But the hacker doesn't know that because he can't see my
queries (knock on wood). In the case mentioned in the original
post, a hacker can now see the query and can design an attack that will
work - assuming there is no input validation.
-
@UncleMidriff said:
What I'm curious about is how a malicious
person could use the information given in the error message and in the
page source to actually execute a SQL injection attack.
That's a good question, which I'll try to give a good answer to.
The code that goes [code]WHERE i.suppress='n'[/code] can accept
anything in to the quotes. If what is being accepted isn't checked for
problems, then even more single quotes marks can go in there.
As an example, when someone enters [code]foo' OR 'x'='x[/code] you will
end up with [code]WHERE i.suppress='foo' OR 'x'='x'[/code] and you've
nicely injected some code that will return all fields.
Now you can start guessing field names by injecting [code]foo' OR
auth=NULL --[/code] which becomes [code]WHERE i.suppress='foo' OR
auth=NULL --'[/code]
The double dashes turns anything following it into a comment, getting around potential parsing errors.
If the auth field doesn't exist you will get an error page. Anything else means that you have the field name right.
The http://www.unixwiz.net/techtips/sql-injection.html page takes you
step by step through this whole process, and demonstrates how to really
use this.
-
@pmw57 said:
The code that goes [code]WHERE i.suppress='n'[/code] can accept
anything in to the quotes.
Yes and I'm a gimp, for it's only where the questionmarks appear that get replaced with the injection code. So for [code]fs.category_id = ?[/code] you could inject [code]1 OR 1=1 --[/code] to end up with [code]fs.category_id = 1 OR 1=1 -- [/code] and then move on from there.
I'll shut up now.
-
or, get this right, we could give it VALID data, and get back info on a pair of size 12 shoes!!!
SCORE!!!!!!!
-
and the server
will happily execute it.
Unless, and by far the safest options, you grant the databse user that the script uses few priviliges.
If you allow an SQL injection attack, that's one thing.
If you allow an SQL injection attack that allows for dropping of databases and tables, then you need smack your DB admin.
Me and my hosting is something of a grey area, I think. I only have 1
DB user, which, necessarily, has full priviliges. Someone could easily
screw up my database just by adding some SQL to the querystring. I
therefore validate by checking whether the ID inserted into the SQL is
actually a number and nothing but a number.
I fail it silently if the ID passed via QS isn't a number, providing no
information to anyone. It's simple enough to warrant silent failure.
Perhaps I'll make an exception for invalid IDs.
-
I crave post editing.