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
    avatar for making this site significantly less work safe.   
    :)
    All i can say is thank goodness for adblock.



  • @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:


    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.



  • @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.


Log in to reply