Suppressing HTTP 500 response codes

Question

I’ve had a bit of feedback from some threat and vulnerability folks relating to websites returning HTTP 500 response codes. Essentially the advice is that all possible measures must be taken to avoid the server throwing a 500 (i.e. extensive form input validation) which is fine.

However, the advice also suggested that attempts to compromise security by means such as inserting a tag into a random query string causing ASP.NET request validation to fire or manipulating viewstate also should not return an HTTP 500. Obviously the native framework behaviour is to interpret the request and possibly throw to a custom error page but even this will return a 500 response code.

So I’m after some thoughts on how to approach this. Is there any way to configure the app at either the .NET level or IIS level to return an HTTP 200 when a 500 is raised? Or does this become a coding exercise at global.asax level in one of the application events? Are there other consequences to consider?

BTW, the rationale from the security side is that apps which return HTTP 500 may be viewed as “low hanging fruit” by bots randomly scanning for vulnerabilities and prompt further malicious activity. attempts I’m personally not convinced that changing response codes offers any real security gains but am happy to hapy to take the advice of the pros.

Answer 1

Why? Sending back a 500 code without any other information does not give an attacker much information.

Provided you don't throw stack trace, state dumps etc, back to the client then you're fine. And I doubt very much you want to do that.

Seriously, just create a "500" page (picture of a whale optional) and return that with your status 500 - it gives nothing away.

Sending a 200 status when the page was NOT generated successfully is plain wrong and may cause bad things to happen - such as bots thinking it is a genuine page. You don't want your "500 error" page showing up on Google because you sent back a 200 status instead.

Answer 2

You can set custom error pages in config - and you could re-set the response status in your custom error page

<customErrors  mode="On" defaultRedirect="~/DefaultErrorPage.htm" >
  <error statusCode="500" redirect="~/CustomError.aspx"/>
</customErrors>

Serious warning...!

Make sure there aren't any errors EVER in your custom error page. Usually, you would use a html page, not an aspx page - but if you want to change the response headers you may need to use the aspx page. Don't do anything else on there except change the headers (i.e. don't display any data from a database or try to run any logic) and error on your custom error page will cause a "maximum number of redirects" error.

Answer 3

To answer your question: global.asax is the correct place, in particular, the Application_Error event handler. You should be able to do something like

Response.StatusCode = 200
Response.StatusDescription = "OK"

there.

PS: Don't do it. :-) To me, this sounds like yet another security-by-obscurity-by-violating-standards approach. I really don't think the (possibly marginal) security increase is worth breaking correct HTTP behavior (think about Google indexing your error pages, etc.).