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:

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.

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 wrote:

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 wrote:

Oh, and I'd like to thank you and your avatar for making this site significantly less work safe.    :)

All i can say is thank goodness for adblock.

UncleMidriff wrote:

Oh, and I'd like to thank you and your avatar for making this site significantly less work safe.    :)

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 wrote:

Savior wrote: 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_ wrote:

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.

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 ?

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.
http://www.unixwiz.net/techtips/sql-injection.html

UncleMidriff wrote:

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 wrote:

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 WHERE i.suppress='n' 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 foo' OR 'x'='x you will end up with WHERE i.suppress='foo' OR 'x'='x' and you've nicely injected some code that will return all fields.

Now you can start guessing field names by injecting foo' OR auth=NULL -- which becomes WHERE i.suppress='foo' OR auth=NULL --'
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 wrote:

The code that goes WHERE i.suppress='n' 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 <span id="PostFlatView">fs.category_id = ? you could inject 1 OR 1=1 -- to end up with </span><span id="PostFlatView">fs.category_id = 1 OR 1=1 -- 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.

boot boot bnoot