• Zog (unregistered)

    !TSRIF

  • Zog (unregistered)

    !DNOCES

  • Apostle (unregistered)

    TRWTF is that Jon didn't explain how to fix the problem, he just explained what the problem was.

  • x (unregistered)

    tempUserName= &#70&#114&#105&#115&#116&#34&#32&#111&#114&#32&#34&#49&#61&#61&#49 tempPassword= &#70&#114&#105&#115&#116&#34&#32&#111&#114&#32&#34&#49&#61&#61&#49

    Passes the filter nicely

  • RandomGuy (unregistered)

    Well we really can't tell anything about code provided to us because maybe they used addslashes() on username and password even before putting it to sql query.

  • Me (unregistered) in reply to Apostle

    Why should John explain how to fix something as common as SQL injection to somebody who poses as professional programmer?

  • Johnny '; Drop TABLE Users; Drop TABLE mysql; (unregistered)

    :-)

  • (cs)

    WHOOSH! The concept of SQL Injection goes sailing overhead, presumably along with a myriad of other concepts of potential attacks and problems.

  • Zappes (unregistered)

    I think that using unhashed passwords in the database adds a nice touch to the matter.

  • (cs) in reply to Zappes
    Zappes:
    I think that using unhashed passwords in the database adds a nice touch to the matter.
    Technically, it is possible the password was hashed client-side before posting it.

    I mean, given the evident lack of concern for security that is about as likely as me winning the Australian national lottery, but still :)

  • Gore (unregistered) in reply to FragFrog
    FragFrog:
    Zappes:
    I think that using unhashed passwords in the database adds a nice touch to the matter.
    Technically, it is possible the password was hashed client-side before posting it.

    I mean, given the evident lack of concern for security that is about as likely as me winning the Australian national lottery, but still :)

    Client side? Burn him!

  • Mattmon (unregistered)

    If a user actually has any of those characters in their username or password, then they won't be able to log in.

  • Geoff (unregistered) in reply to Apostle
    Apostle:
    TRWTF is that Jon didn't explain how to fix the problem, he just explained what the problem was.

    So Jon should pay good money to have work done for him; and then still do it himself? Sorry no; Jon was provided with a defective product and the provider should make it right.

    If you bought a new car and discovered it only starts 7 in 10 times you turn the key; you would not do a complete tear down diagnose the problem and then take it back to the dealer with a proposed repair in mind. No you'd just take it back to the dealer show them problem and say "fix it".

  • (cs) in reply to Geoff

    Why every reference to software always ends up with a car analogy? Software projects, factories, workers, repairs, maintenance, etc. I mean, people today deal with more problems with computers than with cars. And really, car building isn't something to take as a innovative industry to begin with.

    Oh well, since I can't think of a better suited set of analogies right now, you may carry on.

    Finally, John is TRWTF in this story for commissioning any thing to be built with VisualBasic, and specially a web site. None of the other candidates used something simple like, hmmm, PHP? Not that this would mean he wouldn't be obtaining a WTF riddled product... so... I'm hungry.

  • (cs)

    The real WTF is Jon's process for hiring a contractor.

    He interviewed many prospects
    But obviously he didn't ask security related questions. A simple printout with some code that facilitates sql injection like the one from today's article, together with a question like "Does this code work? Do you see any problems with this code? Could it be improved?" should do the trick.
    each more hopeful than the last
    Yes. Just like in a sequence from 1 to 10, 1.1 is higher than 1, but it is still a long way from 10.
    He viewed samples of the websites they had built, and picked the one he liked the best
    Ok, this sentence has some inherent ambiguity, but my first thought was: "Oh, that website's great! It has unicorns!!" (no offence meant).

    You pick the developer that best fits your job description and meets the quality criteria you have set before you started looking for a contractors, not the one you "like" best.

    The developer proposed the following fix: "Dim tempPassword As String"
    Erm, perhaps it's an unfounded bias, but I wouldn't hire a contractor who suggests Visual Basic as the implementation language for a web application. Not even for a "very simple order tracking system".

    Ah well. Making mistakes is ok, especially if you do things the first time and the possible damage is more like a nuisance than a desaster. Just make sure that for the "slightly more complex order tracking system" your hiring process has improved substantially.

  • (cs) in reply to Geoff
    Geoff:
    So Jon should pay good money to have work done for him; and then still do it himself? ... If you bought a new car and discovered it only starts 7 in 10 times you turn the key; you would not do a complete tear down diagnose the problem and then take it back to the dealer with a proposed repair in mind. No you'd just take it back to the dealer show them problem and say "fix it".
    Unfortunately, that approach might land you with a hefty garage bill and a car that, after a while, again only starts 7 times out of ten.

    So far I've experienced this with products as diversive as a tape deck, a home computer and, yes, also a car.

    Sometimes it really pays off diagnosing the cause yourself and then just telling the repairshop what to do.

  • Luke Alexander (unregistered) in reply to Mattmon

    Depends if he used the same method to "" escape "" the creation of users as well!

  • InjectThePoison (unregistered)
    Jon C.:
    He viewed samples of the websites they had built, and picked the one he liked the best.
    And by this he means, "picked the lowest bidder".

    I have no sympathy. After all as the saying goes, "If you pay peanuts, you get monkeys".

  • Leo (unregistered)

    SQL injection in a VB application? Did this story just fall through a wormhole from 2004?

  • (cs)
    The Article:
    That night, Jon learned a lesson about tech'ing out and hiring developers.
    Yes, he learned that when hiring you have to interview properly, and that he didn't do so, or possibly that he was incapable of interviewing properly.
  • Cristian (unregistered) in reply to Leo

    That's VB.NET, part of the ASP.NET framework to build web applications

  • EatenByAGrue (unregistered) in reply to ubersoldat
    ubersoldat:
    Why every reference to software always ends up with a car analogy?

    Well, you see, it's a bit like driving down the highway and seeing a sign telling you where something is, which is easier to find than the actual place because the place is hidden behind the trees. So we use car analogies to hint at the real meanings of things, because some of the complete morons out there can't see those meanings.

  • Icarium (unregistered)

    I'm still not sure what the WTF is here. Those replacements seem to fix the SQL injection possibility.

  • Anon (unregistered) in reply to EatenByAGrue

    That, and we can't quite figure out how to make programming analogies with beer.

  • Colin (unregistered) in reply to Geoff

    Clearly you've never dealt with SAP technical support for bugs in Crystal Reports.

  • Colin (unregistered) in reply to Geoff
    Geoff:
    Apostle:
    TRWTF is that Jon didn't explain how to fix the problem, he just explained what the problem was.

    So Jon should pay good money to have work done for him; and then still do it himself? Sorry no; Jon was provided with a defective product and the provider should make it right.

    If you bought a new car and discovered it only starts 7 in 10 times you turn the key; you would not do a complete tear down diagnose the problem and then take it back to the dealer with a proposed repair in mind. No you'd just take it back to the dealer show them problem and say "fix it".

    Clearly you've never dealt with SAP technical support for bugs in Crystal Reports.

  • (cs) in reply to Icarium
    Icarium:
    I'm still not sure what the WTF is here. Those replacements seem to fix the SQL injection possibility.
    WTF No. 1 is that the SQL injection possibility existed in the first place.

    WTF No. 2 is that the proposed fix does not address the fundamental problem (you simply don't build sql command strings like this in a web environment) but instead shows that the contractor does not understand the problem domain. As others have pointed out: a) people can't use the characters-to-be-replaced in their passwords any more, so people who already have passwords like that can't log in any more and b) the fix can be circumvented with unicode sequences, so it does not fix the problem.

  • Anon (unregistered) in reply to ubersoldat
    ubersoldat:
    Why every reference to software always ends up with a car analogy? Software projects, factories, workers, repairs, maintenance, etc. I mean, people today deal with more problems with computers than with cars. And really, car building isn't something to take as a innovative industry to begin with.

    Oh well, since I can't think of a better suited set of analogies right now, you may carry on.

    Finally, John is TRWTF in this story for commissioning any thing to be built with VisualBasic, and specially a web site. None of the other candidates used something simple like, hmmm, PHP? Not that this would mean he wouldn't be obtaining a WTF riddled product... so... I'm hungry.

    Well, you see, developers (and techs) are like car mechanics: They think they should be paid equally no matter the quality of their work, and you often can't tell when they're screwing you over because their work is hidden behind a dozen layers of tacked-on parts. When something breaks, they claim it isn't their responsibility, since you must have done something to it after you left the shop.

  • (cs) in reply to Anon
    Anon:
    Well, you see, developers (and techs) are like car mechanics: They think they should be paid equally no matter the quality of their work, and you often can't tell when they're screwing you over because their work is hidden behind a dozen layers of tacked-on parts. When something breaks, they claim it isn't their responsibility, since you must have done something to it after you left the shop.

    Pfffft... speak for yourself dude. What you said only applies to most of them.

  • Albert_dH (unregistered) in reply to InjectThePoison
    InjectThePoison:
    Jon C.:
    He viewed samples of the websites they had built, and picked the one he liked the best.
    And by this he means, "picked the lowest bidder".

    I have no sympathy. After all as the saying goes, "If you pay peanuts, you get monkeys".

    I find monkeys are too smart for that, they want bananas.

    "If you pay peanuts, you get squirrels". Squirrels know nuts (vis. 'Charlie and the Chocolate Factory') and what to do with bad nuts.

  • Valczir (unregistered) in reply to RandomGuy
    RandomGuy:
    Well we really can't tell anything about code provided to us because maybe they used addslashes() on username and password even before putting it to sql query.

    addslashes() doesn't solve anything. For that matter, all you php devs, mysql_real_escape_string doesn't solve anything. The proper solution is simple: prepared statements. Use them whenever there is user input being used in a query. They allow the database engine, itself, to take care of any escaping that may need to be done in the variable(s).

  • (cs)

    Even better, prepared statements prevents the data from ever touching the control logic. Data is treated as data.

  • (cs) in reply to Johnny '; Drop TABLE Users; Drop TABLE mysql;
    Johnny '; Drop TABLE Users; Drop TABLE mysql;:
    :-)
    Woah, watch out Bobby Tables… HEEEERREEESSSS JOHNNY!!
  • ¯\(°_o)/¯ I DUNNO LOL (unregistered) in reply to Johnny '; Drop TABLE Users; Drop TABLE mysql;
    Johnny '; Drop TABLE Users; Drop TABLE mysql;:
    :-)
    Are you related to that Bobby guy?
  • moving through space (unregistered)

    You lost my interest at DIM.

  • so (unregistered) in reply to Valczir
    Valczir:
    The proper solution is simple: prepared statements.

    Nope. I remember a freelancer who insisted in using his beloved fancy php framework's pdo classes cause they were sooo much better and secure compared to the existing db abstraction classes. In the end he put some variables into the prepare statement like

    $db->prepare('SELECT * FROM t WHERE foo=:bar LIMIT ' . $_REQUEST['limit'] )

    PDO can help preventing injections but neither it's its intention nor the solution.

  • Ello (unregistered)

    I guess the passwords are either salted nor hashed oO

  • Mike (unregistered) in reply to InjectThePoison
    InjectThePoison:
    Jon C.:
    He viewed samples of the websites they had built, and picked the one he liked the best.
    And by this he means, "picked the lowest bidder".

    I have no sympathy. After all as the saying goes, "If you pay peanuts, you get monkeys".

    If I'm paying with peanuts, I better damn well get elephants.
  • (cs)

    "He interviewed many prospects, each more hopeful than the last."

    That is the correct way. Schedule your interviews in ascending order of their optimism. Test them on their pessimism beforehand. http://www.learnmyself.com/personality.asp?p=Quick_Test&i=LOT

  • C-Derb (unregistered) in reply to Ello
    Ello:
    I guess the passwords are either salted nor hashed oO
    +1 for storing passwords in plain text.
  • QA (unregistered) in reply to Geoff
    Geoff:
    Apostle:
    TRWTF is that Jon didn't explain how to fix the problem, he just explained what the problem was.

    So Jon should pay good money to have work done for him; and then still do it himself? Sorry no; Jon was provided with a defective product and the provider should make it right.

    If you bought a new car and discovered it only starts 7 in 10 times you turn the key; you would not do a complete tear down diagnose the problem and then take it back to the dealer with a proposed repair in mind. No you'd just take it back to the dealer show them problem and say "fix it".

    Turn key, car started. Unable to reproduce. Resolution: Fixed

  • (cs)

    Why bother? If a "programmer" shows me that, I throw him out of the window.

    But really, if you let anyone this dumb past your evaluation, you are half-guilt.

  • Will A (unregistered) in reply to faoileag

    +1

    Was surprise it took that long for me to scroll down before someone mentioned that the fix itself is a WTF

  • Anonymous Cowherd (unregistered) in reply to EatenByAGrue
    EatenByAGrue:
    ubersoldat:
    Why every reference to software always ends up with a car analogy?

    Well, you see, it's a bit like driving down the highway and seeing a sign telling you where something is, which is easier to find than the actual place because the place is hidden behind the trees. So we use car analogies to hint at the real meanings of things, because some of the complete morons out there can't see those meanings.

    Because the meanings are hidden behind... trees? Would those be B-trees or B*-trees? Or maybe tries?

  • (cs) in reply to ubersoldat
    ubersoldat:
    Why every reference to software always ends up with a car analogy? <<snip>>
    "Car analogies are the Rolls Royces of analogies."
  • Andrew (unregistered)

    The real WTF is not using stored procedures. I would have thought that would be a given for anything .NET.

    Captcha: commoveo... I hope I keep my hair so I never have a commoveo.

  • stew (unregistered)
    Apostle:
    TRWTF is that Jon didn't explain how to fix the problem.
    ubersoldat:
    John is TRWTF
    faoileag:
    The real WTF is Jon's process

    Total agreement here, I must say. Anybody wanting to hire a software programmer to do anything useful (without at least already knowing how to do it better themselves) is totally TRWTF.

  • corroded (unregistered) in reply to RandomGuy
    RandomGuy:
    Well we really can't tell anything about code provided to us because maybe they used addslashes() on username and password even before putting it to sql query.

    Yeah, cos addslashes is proper secure like. Fail.

  • (cs) in reply to faoileag
    faoileag:
    but instead shows that the contractor does not understand the problem domain.
    The contractor might or might not understand the problem domain, but he definitely doesn't understand the solution domain.

    The problem domain speaks of orders, tracking, customer details, product codes and the like. The solution domain speaks of databases, queries, web forms, and so on, all the way down to how to construct (parameterised) queries.

  • Ol' Bob (unregistered)

    But...but...but...this guy's websites were, like, WAY cool!!!

Leave a comment on “SQL Injection: What's That?”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article