3

In my Spring MVC 3 application, I am following REST patterns and lots of logic is based on HTTP status codes. For instance 500 defines a server error. But OWASP modsecurity says not to expose this status code.

I don't understand why a 500 status code would be bad? I see even Google showcases 500 properly.

2
  • This is somewhat a matter of opinion. The most common approach - and what I favour - is to return a 500 error code, but include no technical details in the error message.
    – paj28
    Commented Oct 4, 2016 at 10:27
  • it's talking about overly-revealing 500 pages that dump out a stack trace with file paths, app source code, variable values, and the like.
    – dandavis
    Commented Oct 4, 2016 at 17:37

2 Answers 2

2

An error 500 indicates that the server had an internal error. It normally means one of two possibilities:

  • either a component is down - ok, the error will disappear as soon as it is up again
  • or an exceptional condition is not correctly processed by the application

The occurence of an error 500 should always be followed by an action: if a component was down, it must be repaired or restarted, and if an exceptional condition was not filtered, the application needs a fix.

A problem occurs with applications that do not process exceptional conditions, and are poorly supervised and maintained. If an attacker sees an error 500 that consistently happens in certain requests, it is an indication that the application could not process it, and did not process the error condition either. Maybe a slight variation could make bad things happen...

But simply replacing the 500 code with say a 400 is not a true solution: it only hides the real problem. If I was doing a black box penetration test (with no access to code), I just would not rely on the value of the error code and try all known weaknesses, so hiding an internal 500 with a 400 would not protect the application. And I really believe that serious hackers will think the same...

In a professional world, the 500 errors should be analyzed, and when caused by an non processed exceptional condition, a ticket should be filled to the developper team. For an internal application, an error 500 should mean (explicitely or implicitely) this is an unexpected error, please contact support

1

servers errors generally give overall view of how far the attack was successful on server. like if its 403, it shows that specific authentication was successfully blocked by server (means server handled certain illegal activity quite well), but when server throws 500, it means it was not able to handle certain error, hence it got confused , as a result, giving hacker chance to put more effort in exploiting 500 related error, where he can dig more deeper to penetrate inside server.

In short, 500 errors can be dangerous, as they are only thrown when something unhandled occurs, and users should not see its result or output it generates.(that status or result can be effective in penetrating deeper into server)

3
  • How would a UI convey that something bad happened to a real guy ? There has to be some distinguishing factor, then in that case any distinguishing factor would be enough for hacker..no ? Commented Oct 4, 2016 at 5:48
  • obviously hackers can reach to the api or http call made behind the UI, from there they can get the status code. Commented Oct 4, 2016 at 6:38
  • Yes, my point is how to then show some catastrophic message on UI if there is 500 in backend ? Ofcourse, we cannot show success message. Commented Oct 4, 2016 at 6:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .