The Daily WTF: Curious Perversions in Information Technology

2013-07-19 Reply Admin

Matthew:
jay:

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?

Because when he tries the request again without the SQL injection, and it works, he'll figure out that's how you caught him anyway?

But if I don't tell him that that's the problem, maybe he'll think I have his IP black listed and try he same request from a different IP. Maybe he'll think we caught him because he sent requests too fast, and he'll try to space out his hack attempts. Maybe he'll think he has the table or database name wrong, etc etc. Sure, he might guess right away that the problem is that we're catching SQL injection. But he might not. Why help him out?

2013-07-19 Reply Admin

SomeGuy:
I like people like you. I set up websites that ask for username and password, and then store what you put. It never ceases to amaze me how many people will cycle through every password they ever use when they get rejected. Often they change usernames too in an attempt to log in, and you can get some pretty good idea on what passwords people might use for different things. (and if you ask for an email address instead of a username you can often find out what their password is to their actual email account - yes, it's amazing how many people think it's secure to sign up to "hackerz R us" with their primary email address and the same password they use for their email account.

No reason for it to be even that hard. Jus include some standard security questions. I'll bet lots of people give the same answer every time when asked "In what city were you born?" or "What was the name of your first pet?" Collect those answers, then go to some random sites, try the same user id, tell them you forgot your password, and there's a fair chance they'll ask you one of these security questions that you now know the answer to.

2013-07-19 Reply Admin

xaade:
If you get offended, that's your own emotion. So manage it by yourself. I don't expect to keep your friendship if your easily offended and I offend you. So, what other way can you "punish" me.

In America? She can sue you. At the very least, she can complain to the boss and you lose your job. Or she can post pictures on the web and make your boss nervous and you lose your job.

I make it a point not to offend people, if it's reasonably sane. I have this personal belief as a backup to that. The point being, I don't feel morally obligated to keep you from being offended, but I'd like to try.

Sure. In my humble opinion, there's a big difference between, "I am offended because he screamed obscenities in my face", or "I am offended because he deliberately insulted me", and "I am offended because he expressed a political or social opinion that I disagree with." Especially when the latter is followed by demands that people who express such opinions be censored.

2013-07-19 Reply Admin

Phuul:
Perhaps someone like Matt Westwood could tell me why I have to enter my username at a secured site, then get redirected to a page that tells me I was logged out due to inactivity. I then have to log in again with the same damn username. Why? No idea. Talked to tech support and they said "security". Which pretty much means that they fucked up their logic in the home page.

The theory is that if your computer is in some place where it might be accessible by other people, like your office or a library, that if you forget to log out when you walk away, they minimize the window of opportunity for a stranger to walk up and access your information, bank account, whatever.

2013-07-19 Reply Admin

Bullhonkey:
anonymous:
The HTTP status code should be 200 and the page should have an error message for the user.
When a user submits a form with a required field left blank, do you send back a 400? No, you send back a 200 with the same form again and that field highlighted in red.

No, I don't agree that this is OK. RFC 2616:
10.2 Successful 2xx

   This class of status code indicates that the client's request was successfully received, understood, and accepted.

10.2.1 200 OK

   The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:

   GET    an entity corresponding to the requested resource is sent in the response;

...

   POST   an entity describing or containing the result of the action;
By returning 200, you're stating to the client that "I did what you asked me to do. IF there's an entity in the response, that entity represents the results of what you asked me to do." If the request was not "successfully received, understood, and accepted" then 200 should not be returned.

I think you're confused about the difference between levels and domains of errors.

HTTP status codes are for errors in communications and security. There are codes for things like "header too long" and "timeout expired". These codes are not appropriate for application errors. There are no codes for "the product you are ordering has been discontinued" or "vorpal swords are ineffective against monsters with a magic level greater than 9".

Suppose you sent a letter to a company using snail mail. The postal service might return the letter with a postal-service stamp on it for problems like "invalid zip code" or "moved -- no forwarding address on file". But you wouldn't expect the post office to have a stamp for problems like "we're sorry, you're warranty has expired" or "we have already filled the position you are applying for". You'd expect the company to send you a reply that describes the problem, but that's not in the same category as the sort of problems that the postal service deals with. We're at a different level, like data vs metadata.

2013-07-19 Reply Admin

jay:
I think you're confused about the difference between levels and domains of errors.
HTTP status codes are for errors in communications and security. There are codes for things like "header too long" and "timeout expired". These codes are not appropriate for application errors. There are no codes for "the product you are ordering has been discontinued" or "vorpal swords are ineffective against monsters with a magic level greater than 9".

Suppose you sent a letter to a company using snail mail. The postal service might return the letter with a postal-service stamp on it for problems like "invalid zip code" or "moved -- no forwarding address on file". But you wouldn't expect the post office to have a stamp for problems like "we're sorry, you're warranty has expired" or "we have already filled the position you are applying for". You'd expect the company to send you a reply that describes the problem, but that's not in the same category as the sort of problems that the postal service deals with. We're at a different level, like data vs metadata.

You're confused about the very real role that applications play in the HTTP protocol. See my previous post, but in a sentence: the application writing the response is as much a participant in the HTTP protocol as the traditional web server is. Your postal service analogy is not correct. The postal service takes a role more like TCP: I take your packet (letter) and it get it from here to there. Neither TCP nor the postal service gives one whit what happens to the transmission after it's been delivered. HTTP is not like that. I am expected to receive protocol-level information about the disposition of the request I made in addition to supplementary, human-readable information. Your scenario is more like mailing off an order form and getting a reply in the mail that's stamped with "We received and accepted your order!" on the outside, but includes a letter saying "Sorry, we couldn't accept your order" on the inside. Similarly, if the building I mail my letter to exists, but the suite inside does not, I don't expect to get an envelope back stamped "We delivered your letter!" but a letter inside that says "Oops, we didn't find that suite." The HTTP status code should be consistent with the disposition of the request.

chubertdev · 2013-07-19 Reply Admin

Bullhonkey:
You're confused about the very real role that applications play in the HTTP protocol. See my previous post, but in a sentence: the application writing the response is as much a participant in the HTTP protocol as the traditional web server is. Your postal service analogy is not correct. The postal service takes a role more like TCP: I take your packet (letter) and it get it from here to there. Neither TCP nor the postal service gives one whit what happens to the transmission after it's been delivered. HTTP is not like that. I am expected to receive protocol-level information about the disposition of the request I made in addition to supplementary, human-readable information. Your scenario is more like mailing off an order form and getting a reply in the mail that's stamped with "We received and accepted your order!" on the outside, but includes a letter saying "Sorry, we couldn't accept your order" on the inside. Similarly, if the building I mail my letter to exists, but the suite inside does not, I don't expect to get an envelope back stamped "We delivered your letter!" but a letter inside that says "Oops, we didn't find that suite." The HTTP status code should be consistent with the disposition of the request.

Uhhh.......no.

Put it in terms of speaking a language. If I told you to go jump off a bridge, it's valid English. The HTTP codes are meant to handle things like invalid English spelling/grammar, so they do not apply here. Even though you (analogous to the server) object to the content of the message, it's still valid.

2013-07-19 Reply Admin

[quote user="chubertdev"]Uhhh.......no.[quote]

No? Cite me something from RFC 2616 that supports your view and contradicts mine.

If you told me to go jump off a bridge, it is certainly possible but not very logical for me to respond "OK, I accept your request for me to jump off a bridge" and then not do it. It is far more logical for me to say "no, I do not accept your request for me to jump off a bridge." In your analogy, the "server" is not merely the portion of the brain dedicated to parsing speech; it also includes whatever area(s) responsible for delivering to you my response. In between my hearing and understanding what you've said and my giving you an answer, there's a decision made about whether to accept or reject your request, and that decision is wholly (not partially) relevant to whatever response I give you. One more quote from 2616: "The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request." Emphasis mine. Note that "understanding" a request is specifically not sufficient on its own.

An HTTP status code should be consistent with the disposition of the request. I'm not sure why that's in the least controversial. I guess it's just easier to let 200 go through no matter what, since it's generally the default and there's hardly ever a negative consequence for doing so. But don't confuse your laziness with correctness.

2013-07-19 Reply Admin

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.

Bastardizing standards is most certainly NOT the proper way to do security. Code 404 has a very precisely defined meaning which this case does not meet. It's NOT the same thing as not specifying which credential was wrong.

2013-07-19 Reply Admin

Bullhonkey:
One more quote from 2616: "The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request." Emphasis mine. Note that "understanding" a request is specifically not sufficient on its own.
An HTTP status code should be consistent with the disposition of the request. I'm not sure why that's in the least controversial. I guess it's just easier to let 200 go through no matter what, since it's generally the default and there's hardly ever a negative consequence for doing so. But don't confuse your laziness with correctness.

I've never really been satisfied with any status code in these kind of situations.

400 is imo not correct, since the definition of it is very specific towards not being able to understand the request. The server/application understood it, but it just wasn't good enough. 403 is more along the lines of "you as a person are not allowed to do this" rather than "your input is incorrect" 404 feels really weird for me in this context. The request-uri (I don't consider the post-body to be part of the request-uri) was perfectly understood and the resource was available. The other 4xx's are very HTTP-specific and/or are not appropriate either.

I agree that none of the 5xx's are valid, this code is clearly expecting these kinds of inputs. It just refuses to fully process the data. If there was no SQL-injection prevention and some input would cause a SQL-statement to fail, than you could throw a 500.

If you define a CMS edit form more like something like this: "please validate this content and if you agree that it fits, update/insert the specified record" than a 200 is perfectly valid. The request is received, its processed and turns out to be something that needs a bit more work before it can actually be stored... And a 200 is a valid choice for a response code.

Since these kinds of web forms are generally only used by actual people, the specific response code is not very interesting anyway. If you're designing for applications, the correctness of each part of a request is much more important.

Unfortunately, there is no response code specification for a "The request was perfect HTTP and pointed to a resource that was able to process it, but we just don't want to do that for a very domain specific reason.". In RFC 4819 you have the 422 which is actually the most correct, so if you assume that thats not just for WebDAV you should respond with a 422 :)

2013-07-19 Reply Admin

Hacker Attacker:
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...

...or connect both of them together >:)

2013-07-19 Reply Admin

jay:
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?

The problem isn't security by obscurity here; the problem is abuse of HTTP status codes. What's the point in even having them if nobody actually uses them for their intended purpose?

2013-07-19 Reply Admin

xaade:
jay:

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.

Seriously?

You know what that is right? That's the pregnancy trap. They want you to list any possible scenario you are considering that you haven't committed to (so basically anything that can put you on medical leave act). That's how most people approach having a child. "I can't foresee having a baby, but I want to, and we're trying."

And since they legally can't ask if you're trying to get pregnant, they do this.

Now, for private companies, I give them a pass on this, because it's a big cost to them to have half their staff on medical leave and be forced to leave the spots open for whenever those employees return, legally.

However, when the government employers do that, it's basically saying, "Yeah, I know we make it a point to protect women's 'equality' in the workplace, but we don't want to inhibit ourselves, just private sector businesses. We want to protect what we see as women's rights, but with someone else's money".

Which is basically bigotry in its most gruesome form.

So your view is that the government needs to be intentionally inefficient? You must own shares of some government contractors....

2013-07-19 Reply Admin

Bullhonkey:
anonymous:
The HTTP status code should be 200 and the page should have an error message for the user.
When a user submits a form with a required field left blank, do you send back a 400? No, you send back a 200 with the same form again and that field highlighted in red.

No, I don't agree that this is OK. RFC 2616:
10.2 Successful 2xx

   This class of status code indicates that the client's request was successfully received, understood, and accepted.

10.2.1 200 OK

   The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:

   GET    an entity corresponding to the requested resource is sent in the response;

...

   POST   an entity describing or containing the result of the action;
By returning 200, you're stating to the client that "I did what you asked me to do. IF there's an entity in the response, that entity represents the results of what you asked me to do." If the request was not "successfully received, understood, and accepted" then 200 should not be returned.

It could be argued that the request was received, understood, and processed; and the result of that processing was to not do anything. I mean, the code worked as expected, right? If you click the 'cancel' button on a form, shouldn't that return 200? Just because the server doesn't change anything doesn't necessarily mean the request wasn't accepted.

I mean, it's kind of a stupid argument, but it's got some validity....

2013-07-19 Reply Admin

ACM:
I've never really been satisfied with any status code in these kind of situations.
400 is imo not correct, since the definition of it is very specific towards not being able to understand the request. The server/application understood it, but it just wasn't good enough. 403 is more along the lines of "you as a person are not allowed to do this" rather than "your input is incorrect" 404 feels really weird for me in this context. The request-uri (I don't consider the post-body to be part of the request-uri) was perfectly understood and the resource was available. The other 4xx's are very HTTP-specific and/or are not appropriate either.

I agree that none of the 5xx's are valid, this code is clearly expecting these kinds of inputs. It just refuses to fully process the data. If there was no SQL-injection prevention and some input would cause a SQL-statement to fail, than you could throw a 500.

If you define a CMS edit form more like something like this: "please validate this content and if you agree that it fits, update/insert the specified record" than a 200 is perfectly valid. The request is received, its processed and turns out to be something that needs a bit more work before it can actually be stored... And a 200 is a valid choice for a response code.

Since these kinds of web forms are generally only used by actual people, the specific response code is not very interesting anyway. If you're designing for applications, the correctness of each part of a request is much more important.

Unfortunately, there is no response code specification for a "The request was perfect HTTP and pointed to a resource that was able to process it, but we just don't want to do that for a very domain specific reason.". In RFC 4819 you have the 422 which is actually the most correct, so if you assume that thats not just for WebDAV you should respond with a 422 :)

I don't agree that 400 is "too specific." If a user agent does not understand some other 4xx code it is required to interpret it the same as 400. By definition, then, 400 must be the least specific code that indicates a problem (of some kind) with the request.
I don't understand how you can not consider the POST body part of the request-URI. It's right there in 2616. It's black and white in section 9.5, read it yourself.
I don't agree that the submission of content to a "CMS edit form" is supposed to be provisional in any way. If you thought there was a problem with the content, then presumably you wouldn't submit it! What you're talking about here sounds more like 202 Accepted, where the server says, "I've accepted your input but I'm not sure yet if it's OK, you should check back again later." Note, too, that the discussion of 202 (section 10.2.3) talks about e.g. batch jobs that will occur later, strongly implying once again that the status of an HTTP response is intimately connected to the result of whatever action the server was asked to perform. In this case, the server doesn't know the result yet, and responds with 202 to indicate that fact--NOT 200! That also implies that if the server knows that a request is not acceptable or satisfiable, then there is no justification for returning 200.
I agree that the status code is of minimal importance for an interactive session, and that's why you can get away with sending 200 all day long and nobody cares. But the "who cares, doesn't matter" argument isn't terribly convincing to me.
Remember that a "resource" (again, as defined by 2616) includes all the information in the query string or POST body! So there are, in fact, a plethora of response codes that deal with these situations. It just requires acknowledging the difference between what you think constitutes a resource and what 2616 says constitutes a resource.

chubertdev · 2013-07-19 Reply Admin

urza9814:
It could be argued that the request was received, understood, and processed; and the result of that processing was to not do anything. I mean, the code worked as expected, right? If you click the 'cancel' button on a form, shouldn't that return 200? Just because the server doesn't change anything doesn't necessarily mean the request wasn't accepted.
I mean, it's kind of a stupid argument, but it's got some validity....

It's a stupid argument since he's obviously just trolling.

2013-07-19 Reply Admin

I worked on a site where hacking attempts would return a 503 so that the hackers would think they brought your site down. And it would return THEM a 503 for a timeout period, so it looked like an easy target. The idea was that they would think they succeeded and move on while everyone else was using the site just fine.

And according to the logs, it actually looked to be surprisingly effective.

2013-07-20 Reply Admin

Am I the only one with magical things happenning after clicking the word 'protection' in the article (the one right before the code)?

2013-07-20 Reply Admin

Well, the real WTF is not the error, its that the "injection protection" would not prevent all injections.

For example there is a way to inject into login forms that for many databases would get you logged in to the first account in the database.

Usually that is one with some administrative permissions ;)

And it does not match any of those examples.

I will not repeat the example here since there are to many still vulnerable pages out there :(

2013-07-20 Reply Admin

TRWTF is urldecoding before checking for SQL injections... FAIL!

2013-07-21 Reply Admin

Bullhonkey:
1) I don't agree that 400 is "too specific." If a user agent does not understand some other 4xx code it is required to interpret it the same as 400. By definition, then, 400 must be the least specific code that indicates a problem (of some kind) with the request.

RFC2616 writes this about 400: "The request could not be understood by the server due to malformed syntax."

When I read that (and I'm not a native English speaker, so that may not help), I interpret that like send a 400 in a case like this: "GETT /somepage HTTP1.1"

I.e. syntax errors in the HTTP-request, not in aspects that are valid HTTP but just not valid for the application itself.

Apart from that, I don't see any indication that 400 is the most basic 4xx and should therefore be a last resort code of sorts. But there is an indication that any 4xx should be treated as a error with the request as supplied by the client (whereas 5xx is a error outside the scope of the client).

2) I don't understand how you can not consider the POST body part of the request-URI. It's right there in 2616. It's black and white in section 9.5, read it yourself.

That's not how I read it...

This is in 9.5, http://tools.ietf.org/html/rfc2616#section-9.5

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line.

The bold is mine, which clearly suggests there is a Request-URI and whatever is in the POST-body will be the contents of a new entity not yet in the system. In practice I doubt many will take the trouble to differentiate between POST for new entities and PUT for changes or that a POSTed entity will be a direct subordinate of the request uri... But still, I don't see anything in that section 9.5 that suggests the body of the POST (or PUT) is part of the Request-URI.

As I understand it - and just now again read it - (see section 3.2 and 5.1.2) the URI is basically the thing you see in your browser's uri bar.

The body of POST and PUT are about the contents of the entity represented by the URI (or created newly as part of the response).

3) I don't agree that the submission of content to a "CMS edit form" is supposed to be provisional in any way. If you thought there was a problem with the content, then presumably you wouldn't submit it!

That probably really depends on the form and workflow surrounding that form. I'm fairly certain that users will "abuse" the server side validation of forms in various scenario's to see if the server "will finally accept" the new version of the contents ;) Whether that should result in a 2xx or a 4xx is of course the whole debate here... But I have yet to find a suitable response code (apart from the 422 in WebDAV). 202 suggests the response will be act upon some time in the future. It does not imply the user should issue a new request for that to happen.

5) Remember that a "resource" (again, as defined by 2616) includes all the information in the query string or POST body! So there are, in fact, a plethora of response codes that deal with these situations. It just requires acknowledging the difference between what you think constitutes a resource and what 2616 says constitutes a resource.

Well, I just reread it. See section's 3.2 and 5.1.2 for yourself and re-read 9.5 while your at it. The query string is part of the Request-URI, as is the hostname, the schema, the port number and the path (and I probably forgot a few)... But the request's body is by defintion not part of the Request-URI. The body indicates what should be done with or by the requested entity.

And if you really want to read more about URI's, als read http://tools.ietf.org/html/rfc3986

2013-07-21 Reply Admin

A 404 is a great way to get the automated attack scripts to go away. If for some bizarre reason there was a code "503 SQL injection detected" it would be stupid to use it.

The only WTF here is their SQL Injection detection. The usual prepared statements type methods would be best but to detect and then 404 an attack as well as to later harden the actual SQL query would be great security.

They just need to make sure they are detecting an attack not a valid query.

So I would say their attack detection needs some fixing.

David1 · 2013-07-21 Reply Admin

"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." ... which is great so long as you don't care that you're causing real users to rip their hair out. I think we should start with compilers; if it thinks that the programmer is trying to put a back door in (by whatever heuristics), they should silently reject the program without error message.

"If you catch a thief trying to break into your warehouse" the way that computer programs do, you'd quickly get fired after you sent your CEO to the police station in handcuffs. The first thing you do is make sure the person is a thief and not someone who was supposed to be there and just didn't give the right security handshake.

2013-07-22 Reply Admin

It is my understanding that HTTP error codes should indicate errors on HTTP level, that means that a web server should return 4xx responses when it can't understand the request at all (400 Bad Request: The request cannot be fulfilled due to bad syntax.).

In this case, the error is in the application layer, so ordinary 200 OK response (there was no error in the HTTP processing) is in order with a friendly error message telling the user that the SQL injection protection is pretty stupidly implemented.

2013-07-22 Reply Admin

Ha,

Have you heard the SecondLove story?

SecondLove is a Dutch dating site for people who want to cheat on their partner

The website also responded to a wrong password with the text "Wrong password".

So entering an email address was enough for somebody to know their partner was a member of the site.

2013-07-22 Reply Admin

hugh:
right or wrong I think this is justified.

Something can't be wrong and justified at the same time. Secondly, it's an idiotic question. "What unforeseen problems do you foresee?" It's unanswerable.

2013-07-22 Reply Admin

Worrying that the front end was sending SQL at all! (Or strings that will end up in SQL). We have at least parameterised queries, if not proper business logic and domain mapping nowadays.

And security by blocking known bad is not as reliable as security by enforcing known good. You may find there's some unknown bad you'd not thought about.

no laughing matter · 2013-07-22 Reply Admin

ZoomST:
Not again please: The error is in the Server side since the SQL injection protection code is utter crap (highlighting by me).

It is. So this means the server hosts utter crap. We need a code that reads as "I'm a crap-pot!".

This does not exist so far, but there is one that comes close and it was already suggested by some other commentors: 418.

2013-07-22 Reply Admin

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?
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.

So in April 2014 there'll be a new RFC defining 6xx HTML response codes?

I'd suggest to use 6xx for failures due to programmers and 7xx for failures due to management. (Maybe 7xx to 9xx?)

This would let us define 666 - BOFH style code has been executed. Clients SHOULD attempt to execute anything in the response they identify as possible code.

(I'd have ideas for several other possible codes, too.)

tchize:
If all else fail, always resort to the HTTP 418 error code.

But what should we do if the user orders a cup of tea after receiving this code?

2013-07-22 Reply Admin

Bullhonkey:
jay:
I think you're confused about the difference between levels and domains of errors.
HTTP status codes are for errors in communications and security. There are codes for things like "header too long" and "timeout expired". These codes are not appropriate for application errors. There are no codes for "the product you are ordering has been discontinued" or "vorpal swords are ineffective against monsters with a magic level greater than 9".

Suppose you sent a letter to a company using snail mail. The postal service might return the letter with a postal-service stamp on it for problems like "invalid zip code" or "moved -- no forwarding address on file". But you wouldn't expect the post office to have a stamp for problems like "we're sorry, you're warranty has expired" or "we have already filled the position you are applying for". You'd expect the company to send you a reply that describes the problem, but that's not in the same category as the sort of problems that the postal service deals with. We're at a different level, like data vs metadata.
You're confused about the very real role that applications play in the HTTP protocol. See my previous post, but in a sentence: the application writing the response is as much a participant in the HTTP protocol as the traditional web server is. Your postal service analogy is not correct. The postal service takes a role more like TCP: I take your packet (letter) and it get it from here to there. Neither TCP nor the postal service gives one whit what happens to the transmission after it's been delivered. HTTP is not like that. I am expected to receive protocol-level information about the disposition of the request I made in addition to supplementary, human-readable information. Your scenario is more like mailing off an order form and getting a reply in the mail that's stamped with "We received and accepted your order!" on the outside, but includes a letter saying "Sorry, we couldn't accept your order" on the inside. Similarly, if the building I mail my letter to exists, but the suite inside does not, I don't expect to get an envelope back stamped "We delivered your letter!" but a letter inside that says "Oops, we didn't find that suite." The HTTP status code should be consistent with the disposition of the request.

All right, I'll give you that: My postal service analogy is flawed in that the application -- in the analogy, the recipient of the letter -- may be involved in deciding what status codes to return.

Still, that doesn't change my main point: that the types of conditions indicated by status codes are not in the same category as "no such part number".

What HTTP status code would you return with such a message? There is no error code for "no such part number". How could there be? How could the w3c create status codes for all the possible error conditions that any application might generate?

And what would be the point? HTTP status codes are messages to the user agent, i.e. the browser, etc, not the human user. What would a browser do differently for "invalid part number" than it would do for "here's the current stock quantity of that part"?

I suppose we could create a code for "there was an application-level error in your request, such as a required field missing or a field value not found in the database". But there is no such code now, and it's not at all clear what the value of such a code would be.

2013-07-22 Reply Admin

Roberto:
Ha,
Have you heard the SecondLove story?

SecondLove is a Dutch dating site for people who want to cheat on their partner

The website also responded to a wrong password with the text "Wrong password".

So entering an email address was enough for somebody to know their partner was a member of the site.

An extreme example, but exactly my point. We want to be careful about divulging private information in the course of telling people that they are not authorized to see this information. It's like those jokes along the lines of, "The boss ordered me not to tell you that he really is in his office but he just doesn't want to speak to you now."

2013-07-22 Reply Admin

David1:
"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." ... which is great so long as you don't care that you're causing real users to rip their hair out. I think we should start with compilers; if it thinks that the programmer is trying to put a back door in (by whatever heuristics), they should silently reject the program without error message.
"If you catch a thief trying to break into your warehouse" the way that computer programs do, you'd quickly get fired after you sent your CEO to the police station in handcuffs. The first thing you do is make sure the person is a thief and not someone who was supposed to be there and just didn't give the right security handshake.

If the CEO tries to get into the warehouse but he has forgotten his ID card, and the guard at the door has never seen the CEO before and so does not recognize him, should the guard just let him in because he says, "Hey, I'm the CEO"? If I was the CEO, I'd fire such a guard for extreme stupidity.

OF COURSE we don't set up a security system where if someone puts the wrong key in the lock it automatically opens fire on him with machine guns. Yeah, someone might try the wrong key by mistake. But if he uses the wrong key, we don't let him in either.

OF COURSE security systems have to balance keeping unauthorized people out with a minimum of inconvenience to authorized people. Sure, I've used systems that forgot about the "minimum inconvenience" part.

2013-07-23 Reply Admin

jay:
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."

And the reason lies in hashing passwords plus salting them, so the server can't possibly tell us which part of the password is wrong and if the length is correct, right?

Other than that "Security through obscurity" is a failed approach, since it tends to make people believe, that they can make their unsafe system safe by simply telling no one that it's not safe.

It's like not locking your car and then not telling anyone that you didn't lock. But you shouldn't be surprised if it's gone anyway when you return.

2013-07-23 Reply Admin

Bullhonkey:
anonymous:
I'm going to go ahead and continue to say that the "wrong" response is correct here. The user is the one who needs to know what went wrong. There is no need for the browser to know this. The browser's request was successfully received, understood, and accepted by the server, and the result was a human-readable error message meant for the user, not their browser.
Aside: I tried clicking "Submit" without entering the captcha, and the HTTP result was "200 OK", despite giving me the same form again with "* That's not it" instead of posting my comment. I see nothing wrong with this. This is correct behavior.

I'm not seeing an argument here for why 200 is the "correct" choice. You say that a human-readable response is necessary for the user to take appropriate action, and that's a fair point; but returning 400, 403, 404, 500, or 999 doesn't preclude that. Both the 4xx and 5xx status code classes bear the following general statement: [RFC 2616]

"Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents SHOULD display any included entity to the user."

If the user agent understands that the request was not successful, it can provide an additional nudge to the user to examine the response body for what went wrong.

And, of course, in systems where there isn't a human being available to analyze the response body, the HTTP status code is the only information readily available to decide whether the request was successful or not.

When you're intentionally trying to discourage people from automating a process (hello, captcha!), I see no reason to serve up an HTTP status code indicating exactly why their attempt failed.

chubertdev · 2013-07-23 Reply Admin

Hannes:
It's like not locking your car and then not telling anyone that you didn't lock. But you shouldn't be surprised if it's gone anyway when you return.

I don't expect my car to be stolen if I leave it unlocked...

2013-07-24 Reply Admin

chubertdev:
Hannes:
It's like not locking your car and then not telling anyone that you didn't lock. But you shouldn't be surprised if it's gone anyway when you return.

I don't expect my car to be stolen if I leave it unlocked...

And someone who creates an unsecure system doesn't expect to be hacked.

2013-07-24 Reply Admin

400 is also not the right status since the request is valid from an HTTP point of view. I'd vote for either 403 or 204.

chubertdev · 2013-07-24 Reply Admin

Hannes:
chubertdev:
Hannes:
It's like not locking your car and then not telling anyone that you didn't lock. But you shouldn't be surprised if it's gone anyway when you return.

I don't expect my car to be stolen if I leave it unlocked...

And someone who creates an unsecure system doesn't expect to be hacked.

I think that you're missing the point. Stuff from the car may be stolen. But I still have the keys, so the car's not going anywhere without a tow truck.

2013-07-25 Reply Admin

Definitely. 403 might have been suitable as well.

2013-07-26 Reply Admin

You know what's really amazing?

It's 2013, I've been dealing with this crap for well over a decade, it was trivial to solve then, it's been solved over and over, and STILL TO THIS DAY there aren't BIG FRIGGEN WARNINGS all over documentation like PHP's pg_query about how using pg_query directly is a REALLY BAD IDEA and that you really should use an API that has some protection built in....

http://www.php.net/manual/en/function.pg-query.php

2013-07-28 Reply Admin

But why hasn't intellisense capitalised stuff?!

2013-08-01 Reply Admin

Actually, a 404 may be the right thing for security purposes. SQL injection is an attack, so there is no real need to "play nice" and follow protocol. If an attacker is trolling your site with SQL injections, getting back a 500 gives them valuable information: that your site has a page there and it's worth the attacker paying special attention. Returning a 404 doesn't give the attacker any free info as to which URLs are crackable and which aren't.

2013-08-06 Reply Admin

That's not true, 500 would be more appropriate. The client did not intend to do a SQL injection, so it ís an application bug on the server end and therefore a server issue. The application should have handled the string better to make sure its inserted into the database safely, not simply reject it.

SQL Injection Not Found

Leave a comment on “SQL Injection Not Found”