Is a stack trace of a server application a vulnerability?

Question

In relation to my question on programmers.stackexchange.com.

Is it a security risk to have your application display a full stack trace to the user when things crash? Some security audit that our application passed through says it is. I disagree. I don't see how that could help an attacker in any way.

Of course, there is the principle of "tell as little as possible", but that has to be balanced with common sense too, and I think that there is greater benefit of having that information easily available than risk of having it abused.

Have there been any studies about this? Any evidence at all that would suggest that this is a security risk? Or is this an overzealos application of the above principle?

Answer 1

A stack trace is an information leak, which reveals information about your implementation. Whilst not a serious vulnerability, it does allow an attacker to gain certain information about your system. It may also allow them to use a debugging-based approach to exploiting flaws in your site.

One might argue that the stack trace in itself is a vulnerability, since nobody should be able to crash your site in such a way.

Ignoring the security implications, it's not exactly confidence-inducing for your customers to see a stacktrace. They'll assume the site is broken (which it is, really) and worry about whether their transaction will work, or perhaps even think that the site has been hacked.

Further reading: Is it a vulnerability to display exception messages in an error page?

Answer 2

A stack trace is usually not a vulnerability in itself. However, it can leak some information about the design of the software, which may be helpful to the attacker (e.g., revealing database versions, table names, code filenames, and so on). Therefore, usually it is not a good idea to reveal the stack trace.

The standard way of dealing with this is: turn off stack traces on production servers. You can turn on stack traces on debugging builds that are not exposed to the outside world, to help you debug crashes, but when you move it into production, turn off stack traces.

The web2py web framework has an even more elegant way of dealing with this issue. web2py never reveals stack traces to visitors. Instead, if an uncaught exception occurs, web2py constructs a new "ticket", reveals a ticket number to the visitor, and saves the details of the error (e.g., stack trace, etc.) associated with that ticket in an internal database. Ordinary visitors cannot see the details of the ticket, but an administrator can. An administrator can look at the list of all tickets. In addition, given a ticket number, the administrator can look up its details of that ticket and see, e.g., the stack trace. From a security perspective, this is a great approach.

(Incidentally, web2py is an elegant framework that has put a lot of thought into making security on by default and easy for developers. web2py tries to eliminate security pitfalls and make your service secure by default, to the extent that it can. If you're building a web service that needs to be secure, take a look at web2py!)

Answer 3

Yes, it is.

The best was one I came across that divulged ALL the database credentials on a webserver. Yup, you could remotely access the DB and run queries on it. Which probably means someone could do something nasty like DROP "databasename" or must more nicely, siphon off all the data in the database.

Another one I notified the owner about was a logged session where the stack trace showed the administration login name and unencrypted password.

Most stack traces are merely information leaks that will help someone in their nefarious activities, not quite as blatant as the first two examples given.