• jEDI (unregistered) in reply to faoileag
    faoileag:

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

    Being prepared doesn't necessarily lead to you expecting it. I never expect to get slapped.

    If being prepared precluded being unexpected then my supermarket wouldn't be telling me there was an unexpected item in the bagging area, as clearly they are expecting me to do just that with their comment. This happens less often [fewer often?] now that I've been trained by the machines.

  • Anonymous (unregistered) in reply to Anon

    No, that's only for when the Accept header does not have a content type the server knows how to produce.

  • boredAtWork (unregistered) in reply to ubersoldat

    I would argue the problem is server side. The fix is on the server so why wouldn't it be server side?

  • faoileag (unregistered)

    BTW: the real WTF is an instr (index, indexOf...) function that is not case sensitive.

    Or has the otherwise necessary str = str.ToUpper() line accidentally been omitted from the code?

  • Bring Back TopCod3r (unregistered) in reply to Hmmmm
    Hmmmm:
    Right or wrong, this is the way that SQL injection protection was done back then...

    How dare you suggest that this was ever the right way to do it. I am grossly offended by this. Parameterised queries FTW.

  • Bring Back TopCod3r (unregistered) in reply to Kev
    Kev:
    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

    Whilst true, searching for specific strings in input to prevent SQL injection is all too familiar to be a WTF. 404ing as a response is hopefully new to most of us.

  • (cs) in reply to Hmmmm
    Hmmmm: Right or wrong, this is the way that SQL injection protection was done back then...

    I see what you did there.

  • (cs) in reply to Dave
    Dave:
    Protip: he was joking. Clearly.

    Protip: 'Clearly' requires clarity.

    What with a lot of people being incredibly stupid, it's entirely possible that an random unregistered person here could be that stupid.

    In addition, typically, someone who's clearly joking manages to be funny.

  • faoileag (unregistered) in reply to jEDI
    jEDI:
    If being prepared precluded being unexpected then my supermarket wouldn't be telling me there was an unexpected item in the bagging area
    Nice metapher, but slightly wrong. If the serlf-service till at the supermarket would behave like that code, it would tell you "unexpected item in the bagging area" for a handful of items (say, a 14 oz bag of Skittles) although it knows perfectly well that it is a bag of Skittles you just tried to smuggle into your bag, while for other items (say, a six-pack of beer) it wouldn't say anything because it simply doesn't know that that item should not be in your bag.

    "unexpected" for the coder would be a new sql command like ";NUKEALLMYDBS"; for the common variety the coder was prepared and he expected them. If he didn't, he wouldn't need the code: "no need for ;TRUNCATE nobody uses that".

  • Someone (unregistered) in reply to ubersoldat

    No, it should be a 500.

    There is no problem with the client, but some stupid code on the server side. The client request is fine.

  • superpatty (unregistered) in reply to ubersoldat

    No, the request was valid.

    It would be a 500 since the server had an error while processing the properly submitted data. A text field should be able to accept any properly formatted string, including special characters.

  • Anonymous Croward (unregistered) in reply to faoileag
    faoileag:
    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.

    They do when logging into login.live.com, which is the login page for Microsoft accounts (Outlook, SkyDrive, etc.)

    Entering a random email address and password you get "That Microsoft account doesn't exist. Enter a different email address or get a new account.". Entering a valid email with the wrong password you get "That password is incorrect. Be sure you're using the password for your Microsoft account.".

  • faoileag (unregistered) in reply to Anonymous Croward
    Anonymous Croward:
    faoileag:
    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.
    They do when logging into login.live.com, which is the login page for Microsoft accounts (Outlook, SkyDrive, etc.)
    Hmmm, not when I try it (using the link you supplied). I get "The email address or password is incorrect. Please try again."
  • (cs) in reply to faoileag
    faoileag:
    BTW: the real WTF is an instr (index, indexOf...) function that is not case sensitive.

    Or has the otherwise necessary str = str.ToUpper() line accidentally been omitted from the code?

    Instr is default case-sensitive; the fourth argument to the function (the second 1 in instr(1, str,";DECLARE", 1)) makes it case-insensitive. (The developer could also have used Option Compare Text to make it globally case-insensitive by default in the module/page, but that has less "visible intent" than setting the compare type locally to the call.)

  • No name (unregistered)

    So many misguided statements regarding security here.

    Take two systems A and B. If the inner workings of A and B are identical, but system A obscures it, will system A be harder to hack? Yes. Does it matter? Not really. If system A and B are secure, it doesn't matter. If system A and B are insecure, it takes a hacker minutes to hours longer to hack the system. Is that worth it? That's the million dollar question.

    In this particular case, the answer is a resounding NO! A hacker will figure out that messages with SQL key-words are being dropped quite quickly. An honest user will not. So it hardly has any positive security effects, but huge negative usability effects.

    And if you're not sure what the answer to the million dollar question is in your instance; it's almost certainly no. Inform the user.

    Now, as to the obviously wrong comparison to revealing whether the username or password is wrong. Revealing which one is wrong has nothing to do with obscurity. It's about reducing entropy. And the security of passwords relies on entropy. Revealing things about values in a database is radically different from revealing things about the shape of a database. Anyone that can't see that difference should not be here.

    Now, as a conclusion, let's look at the specific example of revealing whether the username is wrong or just the password. Does this compromise security? We've seen that it reduces entropy. But if there is an alternative method of reducing entropy in the same way, it doesn't matter. So, if your system either allows you to search or list users, it's pointless. Even if you allow users to register unlimited usernames, it's pointless (rather than entering the user names in the login box, a hacker enters them in the registration box). So usually even this is not necessary.

  • (cs) in reply to faoileag

    Nope, that's VB. You had to pass a special flag to make searches case sensitive.

  • Little Bobby Tables (unregistered) in reply to ubersoldat

    The client request is valid, it's the application that is poorly written, so it should send a 500 back. Not my fault bad developers target the innocent with unfortunate names.

  • ZoomST (unregistered) in reply to faoileag
    faoileag:
    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".
    I was referring to the typical situation when you are coding something as closely instructed by [micro-]management but really knowing is wrong... and you feel dirty. Then the failure is expected by the coder, but not by the manager.
    faoileag:
    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?
    Is not enough for sure!
    faoileag:
    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.

    This is genius.

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

    Agreed. As always TRWTF is people thinking these are all problems that they're on their own to solve.

  • Ken B (unregistered) in reply to Balu
    Balu:
    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".
    str = replace(str," ","")
  • Ken B (unregistered) 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. 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.
    Not to mention the joke about how to tell the difference between a plumber and a chemist.

    (Ask them to pronounce "unionized".)

  • Paul Neumann (unregistered) in reply to lucidfox
    lucidfox:
    ;Select Case CommentBody
; Case "Frist"
;  Bad = True
;End Select

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

    'Select Case CommentBody
'  Case "Frist":
'    Bad = True
'  Default:
'    Bad = Bad
'End Select
    It's only because your 'commented' VB isn't syntactically valid.

  • Alnitak (unregistered)

    IMHO, the only correct response codes (if it had actually been a SQL injection attack) are 400 "Bad Request" or 404 "Not Found".

    403 "Forbidden" is not correct (IMHO) because that is used when a resource exists but will not be served, whether authorised or not. This could be used for path-type resources, but I don't think it's an appropriate error for unacceptable CGI-style GET or POST parameters.

    406 "Not Acceptable" is not correct because that represents a mismatch in the HTTP "Accept" headers.

    422 "Unprocessable" is not correct because that's only for use with WebDAV.

    500 "Internal Server Error" is not correct because it is not an "unexpected server side error", or at least wouldn't have been if the injection detector worked properly.

    FWIW, as far as I cam see there actually isn't an HTTP status code specifically for "this request was properly formed, but some of the parameters in it are not acceptable".

    In my own code, I use 400 if user supplied input generates a runtime exception, and a 500 for any other exception.

    (FWIW, I'm an IETF protocol nerd and will be attending my 18th IETF meeting on the 27th)

  • Paul Neumann (unregistered) in reply to ZoomST
    ZoomST:
    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.
    Server error indicates the problem is with the server, therefore as a user you can only alert the admin and try again later. This is not the case. The request is triggering a filter to deny the request. 403 (or more generically 400, as the parent category of 403) is the proper response.

  • (cs) in reply to Alnitak
    Alnitak:
    IMHO, the only correct response codes (if it had actually been a SQL injection attack) are 400 "Bad Request" or 404 "Not Found".
    403 is also OK. 404 is a “I don't know the resource you're asking this of”, 403 is a “Computer says No”, and 400 is best thought of as “Wut?” (and should only be used where a more specific result code is not suitable). It should definitely not be a 5?? though; they're the ones that ought to spew something (e.g., an exception trace) into the main log, and tend to be brought to the attention of the server administrator rather than the content owners.

    FWIW, we've got a big poster with all the standard result codes on it at work. It's remarkably useful, better than just hitting Google all the time. No idea where one of my colleagues found it (but the fonts look like Computer Modern…)

  • Paul Neumann (unregistered) in reply to Alnitak
    Alnitak:
    [1]403 "Forbidden" is not correct (IMHO) because that is used when a resource exists but will not be served, whether authorised or not. This could be used for path-type resources, but I don't think it's an appropriate error for unacceptable CGI-style GET or POST parameters. ... [2]FWIW, as far as I cam see there actually isn't an HTTP status code specifically for "this request was properly formed, but some of the parameters in it are not acceptable". ... [3](FWIW, I'm an IETF protocol nerd and will be attending my 18th IETF meeting on the 27th)
    I agree on all but 3 points: 1) The resource (the cgi I submit to) exists, but the request is not being serviced whether authorized or not. 2) There is: it is 403/400. If the parameters are not acceptable then the request is not acceptable. Would you not consider an ArgumentNullException and an ArgumentOutOfRangeException to both be ArgumentExceptions? 3) Apparently not so much a nerd is you think.
  • Deeply Offended (unregistered) in reply to Hmmmm
    Hmmmm:
    Right or wrong, this is the way that SQL injection protection was done back then...

    I'm deeply offended that you could suggest that this could even be right. By using the phrase "Right or Wrong" you're clearly implying that this is acceptable today. And I want you to stop offeding me because waaaaaaaaaaaaaaaaaa

  • Hacker Attacker (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?

    Only way to completely stop hackers is to unplug that little power or ethernet cable...

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

    Yes, this is a dumb way to block SQL injection, but it makes a whole lot of sense to me that if you detect a condition that you think means that someone is trying to hack your site, you block the request and give them the minimum amount of information as to how you knew they were hacking.

    I think the concept of "security by obscurity" is a little overly maligned. Sure, if we are talking about a product that is commercially marketed and where these names or whatever are built in to the system, then just hoping that a hacker won't buy a copy and see what they are is a very thin defense. Anyone who relies on a hacker not knowing that Windows stores program files in "c:\program files" deserves what he gets. But if it's an in-house system or if the names are customizable by the user, and if they are protected as you would protect a password, then they are effectively passwords, and can indeed be very strong security.

    Regardless, it seems to me that giving the same uninformative error message for many different possible conditions that indicate a hack attack is plain common sense. Why tell the thief exactly how you caught him? This just gives him more information for his next try. If you catch him because you detected a SQL-injection attempt rather than, say, because his IP is on your watch-list, why tell him that? Okay, it's "security by obscurity" because you're hoping that he won't know that you're checking for SQL-injection attempts. If he had a copy of your source code and studied it then he could discover that and the obscure error message wouldn't prevent that. But apparently he does not have a copy of your source code and/or has not figured out that you are detecting SQL-injection attempts, BECAUSE HE JUST TRIED ONE. If he doesn't know that that's how you caught him, why tell him? Let him wonder.

    If you catch a thief trying to break into your warehouse, you don't tell him, "We caught you because we have a hidden security camera pointed at the window you tried to crawl through." That just tells him that next time he should try to enter a different way. Let him wonder whether it was a security camera, or a noise detector, or his accomplice was an undercover police officer, etc etc.

    It's one thing to blindly hope that no one will ever know or guess your secret security procedures. It's another to publish all your secrets on your Facebook page. Sure, smart thieves may figure them out. But why make it easy for them? Why make yourselves vulnerable to the dumber ones?

  • jay (unregistered) in reply to Hmmmm
    Hmmmm:
    Right or wrong, this is the way that SQL injection protection was done back then...

    And if people back then believed that it would work, then it would work, because good security is just a matter of opinion.

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

    Exactly. There is a reason why we don't say "Characters 1, 3, 4, and 5 of the given password were incorrect but characters 2 and 6 were right and it is the correct length. Please try again."

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

    I think the AC was sarcasmising there. However, in truth Microsoft DOES tell you whether the username is valid or not. They don't do it directly, but try this: attempt logging on with a valid username, and after a few (password)failures the system locks you out. Attempt logging on with an invalid username, and you can keep trying forever. This is almost as terrible a bug as the fact that the domain logs (quite possibly for systems other than Windows as well) record the username of every attempt. All you have to do is accidentally type your password into the Name field, then try again and login successfully, and your password and username are sitting prettily next to eachother in the log file, plaintext.

  • (cs)

    I'm surprised.

    While there is a code for "File not Found", where are the codes for the other two cases: TRUE FALSE

    You can now groan as we return you to the regularly scheduled program.

  • ztrem (unregistered)

    And the code, of course, won't even actually prevent SQL injection. So I want to drop a table, but can't say ;DROP? No problem. I'll even assume I still need the leading semicolon. All I have to do is put something between the semicolon and the drop statement:

    ;IF (1=1) DROP TABLE EMPLOYEES

    OK, you say, you'll just ban the IF statement, and all other SQL keywords. So I come back with this:

    ; /* Drops the table with the aid of this comment */ DROP TABLE EMPLOYEES

    So you also ban using a "/" (and while you're at it, any another special character that can be used as part of SQL) immediately after a semicolon. Surely that will protect your database, right? I mean, there's no way I could put an arbitrary word after a semicolon and have it be valid SQL, right?

    ; Just_A_Harmless_Label: DROP TABLE EMPLOYEES

    At this point you're either building some weird regular expression to try to counter that, or just banning the semicolon altogether, since you can no longer use it with half the English language anyway. With all the effort you're putting in (and it's STILL not secure), you may as well just do things properly and use stored procedures.

  • jay (unregistered) in reply to jEDI
    jEDI:
    faoileag:

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

    Being prepared doesn't necessarily lead to you expecting it. I never expect to get slapped.

    If being prepared precluded being unexpected then my supermarket wouldn't be telling me there was an unexpected item in the bagging area, as clearly they are expecting me to do just that with their comment. This happens less often [fewer often?] now that I've been trained by the machines.

    When I worked for the government, I once filled out a form that included a box where they requested, "List all possible unforeseen problems that may prevent completion of this project on schedule". As I didn't foresee any unforeseen problems occurring, left it blank.

  • Alnitak (unregistered) in reply to Paul Neumann

    Re: [1], I did say that in my opinion 403 was not appropriate. Unfortunately far too many RFCs are subject to interpretation. I'll find the relevant IETF mailing list and ask.

    Although I do use 400 myself, I don't think it strictly adheres to RFC 2616, which says (my emphasis):

    400 Bad Request The request could not be understood by the server due to malformed syntax.
    Now, in this particular case you could argue that a SQL injection string is indeed malformed syntax, but to my reading 400 doesn't address the case where the syntax is perfectly legal but the parameters contained therein are not.

    [2] follows from [1], if you believe that 403 is appropriate.

    [3] my main area of expertise is DNS, not HTTP. I do read a lot of RFCs, though!

  • jay (unregistered) in reply to ztrem
    ztrem:
    And the code, of course, won't even actually prevent SQL injection. So I want to drop a table, but can't say ;DROP? No problem. I'll even assume I still need the leading semicolon. All I have to do is put something between the semicolon and the drop statement:

    ;IF (1=1) DROP TABLE EMPLOYEES

    OK, you say, you'll just ban the IF statement, and all other SQL keywords. So I come back with this:

    ; /* Drops the table with the aid of this comment */ DROP TABLE EMPLOYEES

    So you also ban using a "/" (and while you're at it, any another special character that can be used as part of SQL) immediately after a semicolon. Surely that will protect your database, right? I mean, there's no way I could put an arbitrary word after a semicolon and have it be valid SQL, right?

    ; Just_A_Harmless_Label: DROP TABLE EMPLOYEES

    At this point you're either building some weird regular expression to try to counter that, or just banning the semicolon altogether, since you can no longer use it with half the English language anyway. With all the effort you're putting in (and it's STILL not secure), you may as well just do things properly and use stored procedures.

    That is, of course, the problem with this whole approach to security or error detection. You have to think of every possible way that it could be wrong.

    For SQL injection, this whole idea is unnecessary. You can, (a) use parameterized queries, or (b) flush or reject non-numerics in numeric inputs and double any quote marks in string inputs. Why people try to catch anything that looks like SQL instead of just doing (a) or (b) baffles me.

  • jay (unregistered) in reply to Ken B
    Ken B:
    Not to mention the joke about how to tell the difference between a plumber and a chemist.

    (Ask them to pronounce "unionized".)

    Another good way to recognize a chemist is to ask him what a "mole" is. A non-chemist will say something like, "a furry little creature that burrows in the ground". A chemist will take an hour to explain.

  • Alnitak (unregistered) in reply to Alnitak

    and following up to myself, I just found a comment on StackOverflow from Julian Reschke (who is a real bona-fide expert on HTTP) saying that "422 Unacceptable" is perfectly good for this situation.

    There perhaps needs to be a clarification to RFC 4918 and/or HTTP/1.1bis that the new status codes defined in RFC 4918 are not WebDAV specific.

  • Jeremy (unregistered) in reply to jay
    jay:
    ztrem:
    And the code, of course, won't even actually prevent SQL injection. So I want to drop a table, but can't say ;DROP? No problem. I'll even assume I still need the leading semicolon. All I have to do is put something between the semicolon and the drop statement:

    ;IF (1=1) DROP TABLE EMPLOYEES

    OK, you say, you'll just ban the IF statement, and all other SQL keywords. So I come back with this:

    ; /* Drops the table with the aid of this comment */ DROP TABLE EMPLOYEES

    So you also ban using a "/" (and while you're at it, any another special character that can be used as part of SQL) immediately after a semicolon. Surely that will protect your database, right? I mean, there's no way I could put an arbitrary word after a semicolon and have it be valid SQL, right?

    ; Just_A_Harmless_Label: DROP TABLE EMPLOYEES

    At this point you're either building some weird regular expression to try to counter that, or just banning the semicolon altogether, since you can no longer use it with half the English language anyway. With all the effort you're putting in (and it's STILL not secure), you may as well just do things properly and use stored procedures.

    That is, of course, the problem with this whole approach to security or error detection. You have to think of every possible way that it could be wrong.

    For SQL injection, this whole idea is unnecessary. You can, (a) use parameterized queries, or (b) flush or reject non-numerics in numeric inputs and double any quote marks in string inputs. Why people try to catch anything that looks like SQL instead of just doing (a) or (b) baffles me.

    It's probably because someone gave them one example of how someone could take advantage (or it actually happened once) and some "clever" "programmer" set off to come up with a hyper specific fix. For some reason it never dawns on those people that they aren't the first humans on the planet to have to deal with that issue and that maybe they should just look for an actual answer.

  • (cs) in reply to jay
    jay:
    Another good way to recognize a chemist is to ask him what a "mole" is. A non-chemist will say something like, "a furry little creature that burrows in the ground". A chemist will take an hour to explain.

    Hey, I'm a physicist, you insensitive molpy^H^H^H^H clod!

  • jay (unregistered) in reply to No name
    No name:
    Take two systems A and B. If the inner workings of A and B are identical, but system A obscures it, will system A be harder to hack? Yes. Does it matter? Not really. If system A and B are secure, it doesn't matter. If system A and B are insecure, it takes a hacker minutes to hours longer to hack the system. Is that worth it? That's the million dollar question.

    "Security" is not a Boolean value, it's a float.

    If I put a lock on my front door, does that make my house secure? Yes or no, please. In real life, nothing is "secure" or "not secure". The question is, "how secure is it".

    Earlier this year I bought an alarm system for my home. Does that mean that my house is now 100% secure against any possible thief? Of course not. I'm sure professional burglars have figured out ways to beat the cheap system I bought -- I've had musings about how to beat the system that I may try someday just for fun. But the really skilled burglars aren't going to bother breaking into the house of some ordinary middle class guy. They're going to be going for the mansions full of valuable jewelry and that sort of thing. I'm more worried about the teenage punks. And even there, sure, even supposing the alarm works flawlessly and the security company calls the police promptly, a competent thief could be in and out before they arrive.

    The test of a security system is not, Does it make the thing we are trying to protect absolutely impervious to any possible attack? The test is, Does it make an attack difficult enough to keep out the amateurs and not worth the trouble of the professionals, while not seriously interfering with the day to day access of authorized people?

    So if a little obscurity helps, it helps. It's how much, not yes or no. (Or file not found.)

  • (cs) in reply to Hmmmm
    Hmmmm:
    Right or wrong, this is the way that SQL injection protection was done back then...

    Not only is that comment boring and weird, it is also deeply offensive to me. You must immediately rewrite it in a way that does not suggest that it is possible to morally condone such behaviour.

  • (cs) in reply to Rob
    Rob:
    I don't see why they just don't return a 418.

    Beat me to it.

  • The other Frank (unregistered) in reply to ubersoldat

    Sometimes security thru obscurity works. Case in point: PRISM.

    But this is not security thru obscurity. This is stopping all communication when hackish behavior is seen. Sounds more like firewalling.

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

    TRWTF is being non compos mentis enough to be able to keep track of your username and password.

    Can't you just try the old "Can't remember my username and password" link and they'll just email it to your email address? Oh yeah, but I changed email supplier since I last logged in and ...

    FFS if the worst comes to the worst, create a different account. If you use it that occasionally it can hardly be that important.

  • Paul (unregistered) in reply to ubersoldat
    ubersoldat:
    ...because the problem is in the client request.
    Nope, the problem is in the implementation that does not sanitize the string properly.

    Anyway... http://xkcd.com/327/

  • (cs) in reply to Papa Gujio
    Papa Gujio:
    TRWTF is not using PHP. AMIRITE?

    You have a WTF in VB. Then you use PHP. Now you have two WTFs.

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

    600: Unexpected Spanish Inquisition

  • gnasher729 (unregistered) in reply to Alnitak
    Alnitak:
    and following up to myself, I just found a comment on StackOverflow from Julian Reschke (who is a real bona-fide expert on HTTP) saying that "422 Unacceptable" is perfectly good for this situation.

    There perhaps needs to be a clarification to RFC 4918 and/or HTTP/1.1bis that the new status codes defined in RFC 4918 are not WebDAV specific.

    422 is a WebDAV extension and not part of RFC 2616.

    403: "The request was a valid request, but the server is refusing to respond to it." is exactly right. There is nothing wrong with the request itself. However, the server is apparently vulnerable to SQL injections, and therefore refuses requests valid requests that resemble SQL injections.

Leave a comment on “SQL Injection Not Found”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article