Should a web application return true http errors?

Question

Exception and error information can be used by a malicious user to map out the API of an web application, so it is routine to see security checklists to advise returning only a "Please contact your administrator" type of message.

On the otherhand, we are encouraged to use HTTP standards, which recommend errors such as

• 400 -- bad request
• 401 -- unauthorized
• 403 -- forbidden
• 405 -- method not allowed
• 500 -- internal error
• 501 -- not implemented

Those all seem to provide some information about the API, namely that such an invocation exists and while your attack was close to a properly formatted request, it wasn't close enough.

Should all of these HTTP request be translated to the same error message, or should standards compliance prevail?

UPDATE: As an application developer, personally I prefer fairly rich exception messages and don't like that most apps I work on return 200 for everything that the application returns and only returns non-200 errors when ASP.NET or IIS feels like returning a non-200 error.

Answer 1

I'd say to not buck against RFCs in a vain attempt to provide security through obscurity, they'll create more headaches when someone plugs into your API and is receiving 200 codes when the server is really throwing 500s.

Honestly: if you somehow get a list of all my API signatures, I still wont care and will return 403s all day. Even on an open API your 500 messages should be generic enough that they don't really know what is going on to begin with other than "the server didn't like the input, please follow spec, etc. etc".

Answer 2

While not returning codes can provide some small measure of security through obscurity, each of those is a helpful thing to know on its own as a user. If your server kicks back a 500, I know as a legitimate user that it's not my fault as opposed to scratching my head over a false 404.

Consider altering those error messages only when you know there's a leak of some kind that you want to avoid (404 for a user page you're not authorized to know about vs. 403 would prevent enumeration). Wholesale altering everything comes with more downsides than upsides.

Answer 3

Like the other respondents so far I would agree that a small amount of security by obscurity does not outweigh the benefit of returning a semantically significant response code. In addition to informing the user of the status, it is a great help to have meaningful data recorded in logs for diagnosing errors, performance issues and for analysing security.

One caveat though is for a 401 error - this will usually cause the browser to prompt for a password which, in the absence of a digest directive, may be sent in clear text - if the request is unauthorized and (as in most cases) the authentication is handled by the code running on top of the webserver, then use a different code (I'm a teapot?).

Indeed I'd go further and suggest you think carefully about whether you can convey further information using the undefined status codes.

I assume that you're already aware of MSIE's habit of replacing HTML returned with non-2XX codes.

Answer 4

There are two side to look at here and you need to make a decision based on what you are protecting and what vulnerabilites the error codes may expose. On the one hand explicit error messages make debugging easier, and I am talking about debugging based on real user experience. The most dangerous bugs are the ones you never experience until the system goes live. The quicker you can squash those the better from both a security and business perspective.

On the scarier world side, the threats (black hats) out there now are very sophisticated. They will fingerprint your OS, Network, programming languages, libraries, and peak operating hours before they launch an attack. Giving them more information is dangerous especially if your systems are not frequently updated and patched. Allowing a threat to probe the sensative areas with authentication errors will raise your risk.

That said I tend to agree with Jeff and StrangeWill. The information you would be witholding will likely be used more frequently by your own team than by the opportunistic black hat. Unless what you are protecting has high value (more than just e-mail addresses and passwords) the ability to quickly fix errors is more important to the business then the denial of a small bit of information to the black hats (they will still get a lot anyway).