• (cs)

    600 Frist comment!

  • Iggy (unregistered)

    stop; declare FRIST;

  • Pippo (unregistered)

    So, why wasn't there a “Hey, don’t do this!” message, or at least a 500? I feel fristed.

  • (cs)

    OK. I AM WITHIN A TENT.

  • (cs)

    So rather than just properly escape the strings, it was a better idea just to look for some SQL keywords?

  • Wody (unregistered)

    Why on earth a 404?

    Because you don't want to give bots/crackers more information than you have to. Now they will think there is no database if they just try to hack the front end. Ofcourse if people have access already then all bets are off, like being able to see what Michael was able to see. I'm not saying Michael is a cracker, or that this is the right way. But giving proper information to bad people, can hurt you.

  • (cs)

    A 500 would be as wrong as a 404. In this case you HAVE to return a 400 because the problem is in the client request.

  • (cs) in reply to Wody
    Wody:
    Why on earth a 404?

    Because you don't want to give bots/crackers more information than you have to. Now they will think there is no database if they just try to hack the front end. Ofcourse if people have access already then all bets are off, like being able to see what Michael was able to see. I'm not saying Michael is a cracker, or that this is the right way. But giving proper information to bad people, can hurt you.

    Security by obscurity and a PITA to debug. Thanks but try again.

  • (cs)

    I love SQL injection prevention code that not only works by checking for SQL keywords, but checks for them in uppercase only. (Or is instr() not case sensitive? Otherwise the sentence in the article shouldn't have triggered it. Hmm.)

  • Balu (unregistered) in reply to lolwtf
    lolwtf:
    Otherwise the sentence in the article shouldn't have triggered it. Hmm.

    Shouldn'r have anyway, because the detection code looks for ";DECLARE", but in the sentence it's "; DECLARE".

    CAPTCHA: minim - al effort should go into proof-reading the articles...

  • wat (unregistered) in reply to Wody
    Wody:
    Why on earth a 404?

    Because you don't want to give bots/crackers more information than you have to. Now they will think there is no database if they just try to hack the front end.

    Better yet, don't respond at all and maybe the baddies will think your company doesn't exist.

  • Anon (unregistered) in reply to Balu

    Guess you missed the initial lines that stripped spaces from the text?

  • Tired dev (unregistered) in reply to Balu

    Yes, but above that was a replacement code, so all spaces were gone...

  • (cs)

    Anyone remember phpNuke? It would look for SQL keywords like this - "union" was the one that I usually stumbled into - and if you tried to post a message with that word in it, it would throw you back to the site's main page, without explanation. It was frustrating as hell - you'd type out a long post, forget about using that word, and you'd lose everything you typed. That was the best solution they could come up with? Union is used in plenty of other contexts, like town names, plumbing, Civil War discussions, mathematics, etc.

  • (cs) in reply to rmarquet
    rmarquet:
    That was the best solution they could come up with?

    This is not a solution to SQL Injection in any way, so for future readers, this is the most stupid and error prone way to target this problem, which shouldn't exist if your application is well designed in the first place.

  • (cs)

    Right or wrong, this is the way that SQL injection protection was done back then...

  • Simon (unregistered) in reply to rmarquet
    rmarquet:
    Anyone remember phpNuke?

    What do you expect from something with the word 'nuke' in its name?

  • (cs) in reply to ubersoldat
    ubersoldat:
    Wody:
    Why on earth a 404?

    Because you don't want to give bots/crackers more information than you have to. Now they will think there is no database if they just try to hack the front end. Ofcourse if people have access already then all bets are off, like being able to see what Michael was able to see. I'm not saying Michael is a cracker, or that this is the right way. But giving proper information to bad people, can hurt you.

    Security by obscurity and a PITA to debug. Thanks but try again.

    This is absolutely the correct way to deal with a security attack.

    It's analogous to why you don't tell a user if it is their username or password was wrong (or whether the username even exists). It's enough information to let a hacker take the next step.

    What you put into your logs at the back-end is a different story of course.

  • jimbobmcgee (unregistered)

    Yeah, bad SQL keyword searching is bad.

    But I've got a pricy, commercial "web application firewall" (re: glorified proxy server) - foisted on us by a client, of course - that does exactly this, out of the box. With the added "bonus" of undecipherable regexes to boot.

    Postdata matches regex? ...404 Querystring matches regex? ...404 URL path matches regex? ...404 Session cookie matches regex? ...404 Server throws a 500 error? ...404

    Fishy buggers.

  • Josh Ribakoff (unregistered) in reply to LoztInSpace

    But it wasn't an attack.

    And lots of websites do this. For example if I use the wrong password too much at my bank, they tell me so, and tell me to call my banker, they don't serve me a 404.

  • (cs) in reply to Hmmmm

    Yes, but it works so poorly. That's how the President's daughter became ill.

  • (cs) in reply to wat
    wat:
    Better yet, don't respond at all and maybe the baddies will think your company doesn't exist.

    Not sure if you're joking.

    You do realize that the server has to have made some connection to the client for the request to get received, so it has already let the client know about its existence before it's in a position to make any kind of judgement call about the request itself.... right?

  • some pony (unregistered) in reply to eViLegion

    at OHM2013 already?

  • Volker (unregistered) in reply to ubersoldat

    400 is a "Syntax error", thus I'd choose 422 (Unprocessable) according to RfC 4918, or maybe 403 (forbidden).

  • (cs) in reply to some pony
    some pony:
    at OHM2013 already?

    Unfortunately not; that would be awesome.

  • Kev (unregistered) in reply to ubersoldat
    ubersoldat:
    rmarquet:
    That was the best solution they could come up with?

    This is not a solution to SQL Injection in any way, so for future readers, this is the most stupid and error prone way to target this problem, which shouldn't exist if your application is well designed in the first place.

    Surely that's why this is a WTF in the first place? The 404 thing is a bit lame, but the whole approach is daft

  • Kev (unregistered) in reply to Kev

    I've got an apostrophe in my surname, and the number of sites that block it is amazing. Not just small sites, either

  • (cs) 
    ;Select Case CommentBody
; Case "Frist"
;  Bad = True
;End Select

    Damn, why does the server reject my commented-out VB code?

  • faoileag (unregistered) in reply to ubersoldat
    ubersoldat:
    A 500 would be as wrong as a 404. In this case you HAVE to return a 400 because the problem is in the client request.
    Nope. If you read the specs for HTTP Status codes, you will find that "403 / Forbidden" is what you should return, since "The server understood the request, but is refusing to fulfill it."

    http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html then goes on to say that "If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead".

    So the 404 is completely correct, and while the SQL Injection handling is clearly a wtf, dealing with any attempt by returning a 404 is definitely not.

  • Mike (unregistered) in reply to Hmmmm
    Hmmmm:
    Right or wrong, this is the way that SQL injection protection was done back then...
    This was never "right". You like looking at SQL queries like they are objects don't you? Pervert!
  • Mike (unregistered) in reply to Hmmmm
    Hmmmm:
    Right or wrong, this is the way that SQL injection protection was done back then...
    This was never "right". You like looking at SQL queries like they are objects don't you? Pervert!
  • Simon (unregistered) in reply to LoztInSpace
    LoztInSpace:
    This is absolutely the correct way to deal with a security attack.

    It's analogous to why you don't tell a user if it is their username or password was wrong (or whether the username even exists). It's enough information to let a hacker take the next step.

    I love those login forms, where you are not told what went wrong, especially if it is some site I don't visit regularly. Did I use the wrong username? Or was it just a typo in my password? Oh, the website doesn't know either, now I try every combination of usernames and passwords I think I could have used on that site... and if the site is really bad, it completely clears the login form everytime and eventually locks my account after a few failed login attempts (which even allows for a nice DoS attack, but I think might be ok for a banking site, to be fair).

    I know, you should try to reduce the amount of information you give to criminals, but I don't know if giving unclear error messages in login forms really helps that much. I'd guess a criminal could easily get a list of valid usernames in some other way on most sites (e.g. trying to send a message to a user or use a password reset form [oh, and if you don't tell me I entered a wrong username there, I really hate you...]).

    Of course, I could have entered a valid username of someone else, so "user exists" does not always imply I did not enter the wrong username, so after a few failed attempts, the site could give me a hint that I might have entered the wrong username.

  • faoileag (unregistered) in reply to ubersoldat
    ubersoldat:
    Wody:
    Why on earth a 404? Because you don't want to give bots/crackers more information than you have to.
    Security by obscurity and a PITA to debug. Thanks but try again.
    Obscurity adds to security and as a rule you should never impart any information as to exactly why you refuse access, if your interface is prone to attacks.

    If you receive a user id and a password, and the password is wrong, you don't say "wrong password, try again", as this would give an attacker the information that the user id does indeed exist. Instead you say something like "login failed, please check your user id and password".

  • Dave (unregistered) in reply to eViLegion
    eViLegion:
    wat:
    Better yet, don't respond at all and maybe the baddies will think your company doesn't exist.

    Not sure if you're joking.

    You do realize that the server has to have made some connection to the client for the request to get received, so it has already let the client know about its existence before it's in a position to make any kind of judgement call about the request itself.... right?

    Protip: he was joking. Clearly.

  • Nick (unregistered) in reply to Balu

    It will look for ';DECLARE' as well as '; DECLARE' because spaces ave already been stripped.

    TRWTF is having to go to great lengths to protect against SQL injection anyway. Why not just use parameterised queries? Or does that mickey-mouse language not have them?

  • Jan (unregistered) in reply to ubersoldat
    ubersoldat:
    A 500 would be as wrong as a 404. In this case you HAVE to return a 400 because the problem is in the client request.

    This is arguable. In fact, the server is rejecting a perfectly valid user input, the sole reason being the developer couldn't come up with any better solution to prevent SQL injection attacks than deliberately rejecting some suspect-looking input strings.

    That's an issue with the server, not with the request, so a 500 would be perfectly appropriate, IMHO.

  • Anonymous Croward (unregistered) in reply to LoztInSpace
    LoztInSpace:
    It's analogous to why you don't tell a user if it is their username or password was wrong (or whether the username even exists).
    Bullshit. Microsoft does that (tell you whether your password or username was wrong) and I applaud them. Good to know there are decent companies that don't listen to "good security practices" like this one.
  • (cs) in reply to Simon
    Simon:
    eventually locks my account after a few failed login attempts (which even allows for a nice DoS attack, but I think might be ok for a banking site, to be fair).

    I once wrote a login system for a company that kept changing their mind what they wanted. Initially it was to be hosted within their network so we blocked ip addresses after x too many failed login attempts. But then they decided to host outside their network, which of course is NAT. Didn't take long for everyone to be locked out and for the ip address based check to be removed!

  • Kasper (unregistered) in reply to ubersoldat
    ubersoldat:
    A 500 would be as wrong as a 404. In this case you HAVE to return a 400 because the problem is in the client request.
    A 4xx code would have been appropriate if it had been a problem with the client request. But it isn't. The client was sending a perfectly valid request, the server was lacking the proper escaping code to handle it. Since it is a server side problem a 5xx code is the only appropriate error code for this sort of situation.

    There is nothing new in this sort of stupidity. I have seen the same on a Computeworld website. Which I BTW ran into a few months after I had reported an SQL injection bug on said website, which they saw no reason to fix, because they had a firewall.

  • Rob (unregistered)

    I don't see why they just don't return a 418.

  • Papa Gujio (unregistered)

    TRWTF is not using PHP. AMIRITE?

  • faoileag (unregistered) in reply to Anonymous Croward
    Anonymous Croward:
    LoztInSpace:
    It's analogous to why you don't tell a user if it is their username or password was wrong (or whether the username even exists).
    Bullshit. Microsoft does that (tell you whether your password or username was wrong) and I applaud them. Good to know there are decent companies that don't listen to "good security practices" like this one.
    Although this post would be perfect to start a flame war with, I restrain myself to the following two remarks:

    It is ok to give precise information when logging in to a desktop computer via a physical keyboard attached to a physical pc. If you sit in front of a pc, you probably know the users name anyway.

    It is not ok to do so in a web environment, and Microsoft doesn't do it either. At least not when logging in at Office.com.

  • faoileag (unregistered) in reply to Kasper
    Kasper:
    Since it is a server side problem a 5xx code is the only appropriate error code for this sort of situation.
    No, it isn't. Does nobody read any specs these days? Look at http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html and see why your are in error.

    500 would be the only response status of the 5xx range that one could consider appropriate, but the definition goes "500 Internal Server Error: The server encountered an unexpected condition which prevented it from fulfilling the request." (highlighting by me).

    Unexpected condition? This is clearly not the case since the SQL Injection was clearly expected - the conditions are stated in the code.

    So again: in this case 403 or 404 are the status to use.

  • ZoomST (unregistered) in reply to faoileag
    faoileag:
    Kasper:
    Since it is a server side problem a 5xx code is the only appropriate error code for this sort of situation.
    No, it isn't. Does nobody read any specs these days? Look at http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html and see why your are in error.

    500 would be the only response status of the 5xx range that one could consider appropriate, but the definition goes "500 Internal Server Error: The server encountered an unexpected condition which prevented it from fulfilling the request." (highlighting by me).

    Unexpected condition? This is clearly not the case since the SQL Injection was clearly expected - the conditions are stated in the code.

    So again: in this case 403 or 404 are the status to use.

    Not again please: The error is in the Server side since the SQL injection protection code is utter crap (highlighting by me). The argument comes as: was this failure unexpected by the original coder (happy one), or expected (forced by management)? Then maybe we need a new 6xx range to express WTF-side errors.

  • (cs) in reply to rmarquet
    rmarquet:
    Anyone remember phpNuke? It would look for SQL keywords like this - "union" was the one that I usually stumbled into - and if you tried to post a message with that word in it, it would throw you back to the site's main page, without explanation.
    The classic Cargo Cult solution, if there ever was one. Why the fuck do people not get that SQL has syntax, and pasting random strings together doesn't guarantee that the splice points delineate elements of the AST (never mind the right elements)?! I tend to think that all those "I'm a self taught web developer, never read any CS books no no hurr durr." people are to blame. The PFY boy from Deep C is the perfect example of who I'm talking about.
  • Just passing by (unregistered) in reply to ubersoldat
    ubersoldat:
    Wody:
    Why on earth a 404?

    Because you don't want to give bots/crackers more information than you have to. Now they will think there is no database if they just try to hack the front end. Ofcourse if people have access already then all bets are off, like being able to see what Michael was able to see. I'm not saying Michael is a cracker, or that this is the right way. But giving proper information to bad people, can hurt you.

    Security by obscurity and a PITA to debug. Thanks but try again.

    Giving the right answer can be used as an oracle to crack the system. There's a known attack (CBC padding oracle attack) that can be succesful by having the server NOT implementing the trick described in the article, and the attacker can crack the system depending on getting 403 or 404 error to different requests. Check: http://www.iacr.org/archive/eurocrypt2002/23320530/cbc02_e02d.pdf

  • Anon (unregistered)

    How about a 406 (Unacceptable) error instead?

  • ZoomST (unregistered) in reply to Just passing by
    Just passing by:
    I am the only one that by reading the beginning of the 4th page reads O'rly instead of O(r|y) = 0?? HACKER - I'm hacking your server successfully with a Last Word Oracle attack! I't super-effective! ADMIN - O RLY???
  • Mike_Black (unregistered) in reply to Hmmmm
    Hmmmm:
    Right or wrong, this is the way that SQL injection protection was done back then...

    You are so evil. ;-)

  • faoileag (unregistered) in reply to ZoomST
    ZoomST:
    since the SQL injection protection code is utter crap (highlighting by me).
    That is certainly true, but at least the programmer did think about SQL Injections. Hey, this is vb code! Have a heart.
    ZoomST:
    The argument comes as: was this failure unexpected by the original coder (happy one), or expected (forced by management)?
    I dare say the failure was unexpected; obviously the coder could not think of "normal" occurences of the SQL commands, like "wally was sad; dropping a ming vase was considered expensive behaviour in these circles".
    ZoomST:
    Then maybe we need a new 6xx range to express WTF-side errors.
    For managment failues? Are you sure 600 - 699 will be a sufficient range for that?

    613: no spec - should be returned by the server when a problem is encountered for which the server can not make a decision due to a missing spec.

    654: time machine required - to be returned for all functionality that could not be implemented in time.

Leave a comment on “SQL Injection Not Found”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article