• (cs) 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".

    Hey, I'm an elephant, you insensitive clod!
  • Ol' Bob (unregistered) in reply to Me

    Ummmm...because John is posing as a professional manager..? A true manager would have fired this developer on the spot, required the rest of the dev team to work weekends for the next year as punishment for allowing such an incompetent in the door, gotten the company legal staff hot on the trail of a bunch of H-1B slave-laborers, and THEN gone off on a three week all-expenses-paid-by-the-company outsourcing-and-recruiting tour of Thailand. Yeah, that's the ticket!

  • Manditory (unregistered)

    We really need more background - from the description given this could be a simple order checking utility for staff, that's not on any system accessible from the outside, and the username is simply needed so that staff can check orders they've entered into the system.

  • (cs)
    He interviewed many prospects, each more hopeful than the last.

    Something's really wrong with his interview process.

  • Skandranon (unregistered) in reply to chubertdev
    chubertdev:
    He interviewed many prospects, each more hopeful than the last.

    Something's really wrong with his interview process.

    Clearly, he managed to somehow pre-sort the interviews so he was always more pleasantly surprised by the next. Must make the interview process much more enjoyable.

  • (cs) in reply to ubersoldat
    ubersoldat:
    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.

    Oh man, I'm still laughing. That's a GREAT joke.

  • (cs) in reply to Skandranon
    Skandranon:
    chubertdev:
    He interviewed many prospects, each more hopeful than the last.

    Something's really wrong with his interview process.

    Clearly, he managed to somehow pre-sort the interviews so he was always more pleasantly surprised by the next. Must make the interview process much more enjoyable.

    SELECT MAX(Interviewee) FROM Interviewees
    

    Optimized.

  • (cs) in reply to QA
    QA:
    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 Billable Hours: 5

    FTFY

  • Skandranon (unregistered) in reply to chubertdev
    chubertdev:
    Skandranon:
    chubertdev:
    He interviewed many prospects, each more hopeful than the last.

    Something's really wrong with his interview process.

    Clearly, he managed to somehow pre-sort the interviews so he was always more pleasantly surprised by the next. Must make the interview process much more enjoyable.

    SELECT MAX(Interviewee) FROM Interviewees
    

    Optimized.

    I am interested in purchasing your optimization technology, I think there is a significant market demand for it.

  • (cs)

    It's open-source, it should be on SourceForge.

  • (cs)

    In my opinion, Jon C. is a lazy cunt.

  • luptatum (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.

    I'm actually surprised he and you are that forgiving. If I was Jon and if I saw this, they'd be some heads flying out of the building. I'm not gonna waste my time with idiots who don't understand basic stuff.

  • luptatum (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.

    I'm a C# guy and I despise VB probably just like you, but if I had to choose between VB.NET and PHP, I'd choose VB.NET.

    And, where did you get that PHP is simpler? When Visual Studio is used, editing almost any language is the simpliest coding there is. Show me one IDE that is better.

  • luptatum (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    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.

    Well, outsourcing generally means having no direct communication with the coder. You communicate with a salesman, who says "yes" to everything ("yes, we can do that, and we're the best out there"). Then the salesman hires coders from India or Pakistan.

    So, if Jon really wanted to outsource to save time, he possibly couldn't know what's he's signing up for at all.

  • (cs) in reply to luptatum
    luptatum:
    I'm a C# guy and I despise VB probably just like you, but if I had to choose between VB.NET and PHP, I'd choose VB.NET.

    And, where did you get that PHP is simpler? When Visual Studio is used, editing almost any language is the simpliest coding there is. Show me one IDE that is better.

    MSIL über alles

  • moving through space (unregistered)

    You are all looking at this from the wrong point of view. This is all about local developers and there is no WTF.

    1. Minimally learn easy to use language
    2. Don't learn about SQL injections
    3. ???
    4. Profit!
  • Jayne (unregistered)

    Dear Diary,

    Today I learned that the purpose of TDWTF is to afford developers the opportunity to bitch about everything about the stories.

    Simon.

  • AndyC (unregistered) in reply to henke37
    henke37:
    Even better, prepared statements prevents the data from ever touching the control logic. Data is treated as data.

    As long as you don't then do dynamic SQL using the passed in parameters, opening yourself up to SQL injection again....

  • Snoodles The Wonder Dog (unregistered)

    Holy crap balls -- I think the guy Jon hired was either a former boss or the guy I work with right now

  • (cs) in reply to Jayne
    Jayne:
    Dear Diary,

    Today I learned that the purpose of TDWTF is to afford developers the opportunity to bitch about everything about the stories.

    Simon.

    And the comments, too!

  • iWantToKeepAnon (unregistered) in reply to x
    x:
    Passes the filter nicely

    Bzzt, wrong.

    1. His test is single quoted and you injected a double quote ... no harm there.

    2. No need to obfuscate the attack, if his site (or browser via url) decodes your string then he would still elide a single quote. If his site doesn't decode your string then he'll be querying with the actual numbers which pose no harm.

    3. His solution isn't that bad and probably secures against most robot/crawler attacks. Looking at the code "upgrade" doesn't make it obvious how to inject into it now.

  • iWantToKeepAnon (unregistered) in reply to Johnny '; Drop TABLE Users; Drop TABLE mysql;
    Johnny '; Drop TABLE Users; Drop TABLE mysql;

    Nope, injection FAIL.

    tempUserName = textBoxUserName.Text.Replace("'", "")
    ...
    tempPassword = textBoxPassword.Text.Replace("'", "")
    

    You never escaped his single quote jail.

    Also, without having the code, you can't assume he has a Users table or that he's using mysql. We've seen the code but a run of the mill hacker will be blind, that's why when you look at webserver logs you see hundreds of fetches from the same attack. One works w/ mysql, one w/ postgresql, one w/ wordpress, one w/ rails, one w/ joomla, etc.... Hence the need to keep up with all security patches!

  • C-Derb (unregistered) in reply to iWantToKeepAnon
    iWantToKeepAnon:
    3) His solution isn't that bad and probably secures against most robot/crawler attacks. Looking at the code "upgrade" doesn't make it obvious how to inject into it now.
    At the risk of feeding a troll....

    Just. Stop. His solution certainly is "that bad".

    Look, I can forgive the initial code that contains a clear SQL Injection vulnerability, assuming lack of experience. But what is unforgivable is then going about solving the problem without learning more about it. Even if he still didn't know anything about the term "SQL Injection", an hour on Google surely would have led to copious examples of similarly flawed code with plenty of recommendations to implement parameterized queries, prepared statements, etc.

    Trying to scrub out nefarious SQL statements with text manipulation is just simply an inadequate solution. In other words, it is "that bad".

  • The elephant in the room (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 resent that remark, you insensitive clod!

  • lolatu (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.

    I wish I hired you just so I could say "you're fired".

  • Talis (unregistered)

    Now I know where those "You only typed in 6 characters. Minimum password length is 6" messages come from...

  • urza9814 (unregistered) in reply to QA
    QA:
    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

    I actually had this exact problem with my car recently. Shift cable came loose, so when you shifted to park it sometimes wouldn't actually go completely into park and therefore it wouldn't start. Took it to the shop (before I knew what the issue was -- the first time it happened I got stuck 500 miles from home at 8pm and had to get a tow), and of course it started right up for them....but, unlike your average IT tech, they kept looking at it and eventually figured it out.

  • urza9814 (unregistered) in reply to luptatum
    luptatum:
    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.

    I'm a C# guy and I despise VB probably just like you, but if I had to choose between VB.NET and PHP, I'd choose VB.NET.

    And, where did you get that PHP is simpler? When Visual Studio is used, editing almost any language is the simpliest coding there is. Show me one IDE that is better.

    Kate. If you can't code in Kate, you can't code.

  • Steve (unregistered) in reply to x

    your &#34 would need to be replaced with &#39

  • (cs) in reply to urza9814
    urza9814:
    Kate. If you can't code in Kate, you can't code.

    Reminds me of that scene in Swordfish where the guy is forced to hack a server at gunpoint.

  • (cs) in reply to x
    x:
    tempUserName= Frist" or "1==1 tempPassword= Frist" or "1==1

    Passes the filter nicely

    So what?

    tempUserName = tempUserName.Replace("&", "")
    tempUserName = tempUserName.Replace("#", "")
    tempPassword = tempPassword.Replace("&", "")
    tempPassword = tempPassword.Replace("#", "")

    ...and another contracting fee. No problem.

  • C-Derb (unregistered) in reply to Coyne
    Coyne:
    x:
    tempUserName= Frist" or "1==1 tempPassword= Frist" or "1==1

    Passes the filter nicely

    So what?

    tempUserName = tempUserName.Replace("&", "")
    tempUserName = tempUserName.Replace("#", "")
    tempPassword = tempPassword.Replace("&", "")
    tempPassword = tempPassword.Replace("#", "")

    ...and another contracting fee. No problem.

    Fail.

    You are continuing with the wrong solution. If you want to disallow special characters in the username an password, you shouldn't filter them out by replacing them with spaces. You should just reject them.

    Put it this way. Say you implement your suggested code. Now you are going to invoke a database call to see if a record exists that you already know doesn't exist (assuming you've implemented similar logic when storing the username/password). So someone who tries to actually submit the password above is going to have your code check for

    701141051151163432111114323449616149
    which won't match any record, unless that really is the person's password, in which case they won't be typing the &'s and #'s in the first place!!!

  • DoggaBoy (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 :)

    What Australian National Lottery? Oh.

  • DoggaBoy (unregistered) in reply to tharpa
    tharpa:
    "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

    Not sure what's worse....that survey or the comment uggesting at least one person was surprised by the result....

  • qiwgfu (unregistered) in reply to luptatum
    luptatum:
    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.

    I'm a C# guy and I despise VB probably just like you, but if I had to choose between VB.NET and PHP, I'd choose VB.NET.

    And, where did you get that PHP is simpler? When Visual Studio is used, editing almost any language is the simpliest coding there is. Show me one IDE that is better.

    CodeBlocks, Eclipse, BloodShe Dev++ . Actually, show me one that's worse than VS...(I'll admit I've only used VS2005,2008,2010 - other versions may not be that horrible).

    In all seriousness though IDE preference is largely down to personal preference and is probably affected by platform, taks and a whole host of other thigns too....

  • SeanC (unregistered)

    I can't log in...

    My password is Hello@Wor;d_

  • Vinny (unregistered) in reply to ubersoldat

    Why cars.

    Because they work when you get them new from the factory Software doesn't Thats why software developers need testers :P

  • (cs) in reply to Johnny '; Drop TABLE Users; Drop TABLE mysql;

    Shouldn't this be Bobby instead of Johnny? http://xkcd.com/327/

  • Your Name (unregistered) in reply to x

    That would be

    SELECT * From tblUsers Where UserName ='Frist" or "1==1' and UserPW = 'Frist" or "1==1'

    which is not going to work, make it

    &#70&#114&#105&#115&#116&#39&#32&#111&#114&#32&#39&#49&#61&#61&#49

    CAPTCHA: nulla

    I like nu(te)lla for breakfast.

  • Wut (unregistered) in reply to so
    so:
    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.

    PDO has prepared statements, and it's tons better than mysqli. Not sure if you're attacking PDO or the guy who clearly doesn't know how to properly use it.

  • Mike_Black (unregistered) in reply to x
    x:
    tempUserName= Frist" or "1==1 tempPassword= Frist" or "1==1

    Passes the filter nicely

    I like Googles Translator, at least for German their is a readable translation. ;-)

  • JenniP (unregistered) in reply to Andrew

    Stored procedures don't fix SQL injection issues either, I've seen plenty of stored procedures that build unsafe SQL internally then run it giving you exactly the same issue.

  • JenniP (unregistered) in reply to JenniP

    Forgot to add

    http://www.troyhunt.com/2012/12/stored-procedures-and-orms-wont-save.html

    So perhaps the real WTF is that even those who think they know how to avoid these things on the whole don't.

  • 50% Opacity (unregistered) in reply to Valczir
    Valczir:
    For that matter, all you php devs, mysql_real_escape_string doesn't solve anything.

    I would really like to hear a clarification to this statement. Why does it not solve anything? Can you demonstrate a problem with code using mysql_real_escape_string?

  • no (unregistered)

    Sounds like a job for little Johnny Tables.

  • (cs) in reply to x
    x:
    tempUserName= Frist" or "1==1 tempPassword= Frist" or "1==1

    Passes the filter nicely

    Sorry, but I'm struggling here - yes it would pass the filter, but it wouldn't do anything nasty.

    The resulting SQL would be

    SELECT * From tblUsers Where UserName ='&#70&#114&#105&#115&#116&#34&#32&#111&#114&#32&#34&#49&#61&#61&#49' and UserPW = '&#70&#114&#105&#115&#116&#34&#32&#111&#114&#32&#34&#49&#61&#61&#49'

    Which would just return nothing (probably).

    What 'magic' will make the DB server do HTML entity decoding?

    If the entity decoding works when the data is read from the query data into the variables, then the Replaces will 'fix' the data.

    I know everyone goes on about 'use prepared statements', but, in this WTF, how is there still an SQL injection attack possibility in the 'fixed' code? (I know there's the problem of magically disappearing characters, but that's not an injection attack)

  • (cs) in reply to 50% Opacity
    50% Opacity:
    Valczir:
    For that matter, all you php devs, mysql_real_escape_string doesn't solve anything.

    I would really like to hear a clarification to this statement. Why does it not solve anything? Can you demonstrate a problem with code using mysql_real_escape_string?

    There seems to be a lot of FUD here from 'prepared statement fanatics'.

    Yes, prepared statements are the 'way to go', but if you have legacy code, you can stop SQL injection attacks without totally rewriting your code.

    You can stop injection attacks if you are careful using mysql_real_escape_string and sprintf (or similar)

    I've spent a while Googling this (since people were saying 'Google it, and you'll find plenty of examples of people telling you to use prepared statements' - well, that's true, but no one has said that mysql_real_escape_string won't work, just that it's not the best solution.

    The reasons NOT to use mysql_real_escape_string AFAICS are:

    1. it relies on you catching all places where you need to use it
    2. if you are using it where the data is a number, then it won't help - only use it for escaping strings. Force number inputs to be numeric instead.

    eg for (2), if you have

    'SELECT * FROM users WHERE usernumber=' . mysql_real_escape_string($_REQUEST['usernumber']) . ';';

    then it won't help at all - because you are expecting $_REQUEST['usernumber'] to be a number, but it may be a string, so if it's: "3 OR 1=1", then the mysql_real_escape_string won't do a thing, but you've still got an injection attack.

    To get around this, you could use sprintf (with '%d') or some other way of coercing the parameter to a number before adding it into your query string.

    So, mysql_real_escape_string will work fine, as long as it is used everwhere, and properly, by someone who understands what they're doing. If you are writing new software, using prepared statements is probably the way to go (unless your web host's PHP doesn't support PDO), because you're less likely to make mistakes.

    I haven't seen anyone (except here) say that mysql_real_escape_string won't work IF USED PROPERLY.

  • Ken B (unregistered) in reply to Geoff
    Geoff:
    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".
    "Diagnosis: We were able to successfully start the car. Process was repeated 5 times without incident. Problem appears to have corrected itself. Invoice customer $150 diagnostics fee."
  • Ken B (unregistered) in reply to Anon
    Anon:
    That, and we can't quite figure out how to make programming analogies with beer.
    Well, "SQL injection" and "GHB injection" aren't quite the same things.
  • Ken B (unregistered) in reply to Ello
    Ello:
    I guess the passwords are either salted nor hashed oO
    The hash at restaurants are usually salted too much.

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

Log In or post as a guest

Replying to comment #410241:

« Return to Article