Should a stack trace be in the error message presented to the user?

I’ve got a bit of an argument at my workplace and I’m trying to figure out who is right, and what is the right thing to do.

Context: An intranet web application that our customers use for accounting and other ERP stuff.

I’m of the opinion that an error message presented to the user (when things crash) should include as much information as possible, including the stack trace. Of course, it has to start with a nice “An Error has occurred, please submit the below information to the developers” in large, friendly letters.

My reasoning is that a screenshot of the crashed application will often be the only easily available source of information. Sure, you can try to get a hold of the client’s systems administrator(s), attempt to explain where your log files are etc., but that will probably be slow and painful (talking to the client representatives mostly is).

Also, having an immediate and full information is extremely useful in development where you don’t have to go hunting through the log files to find what you need on every exception. But that could be solved with a configuration switch.

Unfortunately there has been some kind of “Security audit” (no idea how they did that without the sources), and they complained about the full exception messages citing them as a security threat. Naturally, the clients (at least one that I know of) has taken this at face value and now demands that the messages be cleaned.

I fail to see how a potential attacker could use a stack trace to figure anything out he couldn’t have figured out before. Are there any examples, any documented proof of anyone ever doing that? I think that we should fight this foolish idea, but perhaps I’m the fool here, so…

Who’s right?

I tend to build an application log, either in DB or in file, and log all such information to that. You can then give the user an error number, which identifies which log item the error is related to, so you can get it back. This pattern is also useful as you can follow errors even if the users don’t bother raising them with you, so you can get a better idea of where the problems are.

If your site is installed in a client’s environment and you can’t reach it, you can get the on-site IT dept to send you some extract based on the error no.

The other thing you could consider is having the system email details of errors to a mailbox that you have sight of, so you know when things are going wrong.

Fundamentally having a system that spills its guts when something isn’t right doesn’t inspire confidence in non-technical users – it tends to scare them into thinking something is very wrong (eg how much of a BSOD do you understand, and how do you feel when one comes up)?

On stacktrace:

In .Net the stack trace will show the full trace right into the core MS sourced assemblies, and will reveal details about what technologies you’re using, and possible versions as well. This gives intruders valuable info on possible weaknesses that could be exploited.

Yes, there are many.

A stack trace can reveal

what encryption algorithm you use
what some existing paths on your application server are
whether you are properly sanitizing input or not
how your objects are referenced internally
what version and brand of database is behind your front-end

… the list goes on and on. Basically every design decision in a large application might be security-relevant, and almost all of them may be given away through method or module names. Mind you, that doesn’t mean it doesn’t still make sense to display a stack trace if the environment it’s submitted to is safe (e.g. an intranet rather than an internet-facing website), but the cost in security is defintely not zero.

The thing is, it’s not our primary job to make things easier on ourselves. It’s our job to make things easier on the end user. To us, a stack trace looks like an extremely useful piece of information to provide a developer. To a user, it looks like complete gibberish that is of no use whatsoever. Even if you tell them otherwise, they don’t internalize it. If you think it’s hard getting that information from system administrators, getting it from end users is even worse.

As far as security goes, you might have a point if it was a desktop application. In that case, printing a stack trace doesn’t provide anything an attacker doesn’t already know. On a web app, that information isn’t already available to an attacker. You are indeed exposing internal details that will make an attack a lot easier.

Why not bypass both sources of concern and get exception reports automatically sent to you? That way you don’t even need to worry about people not reporting errors.

Take a look at this question of IT Security SE. In short, a stack trace can give the attacker more information to work with. The more information the attacker has, the more likely they are to penetrate your system. I wouldn’t base my security on the fact that stack traces are always hidden, but that also doesn’t mean that you should give that information to attackers.

You can get most of the benefits from proper backend logging anyway. It’s slightly less convient, but it’s probably not worth risking the secureness of your system and upsetting your customers.

You might consider not showing a stack trace for the following reasons.

Security

Showing a stack trace reveals possible attack surfaces to would be hackers. Intranets are not immune to hacking. It would reflect badly on you if your network was hacked because of an application you are responsible for

User Experience

For the user’s best experience, a strack trace is too much information. Yes, the proper information about an error condition should be logged and given attention by an engineer. However, aksing a user to do what you can automate will not be the best for the user.

Your Reputation

Whenever a stack trace is shown on a website, it looks bad. Most people don’t have any idea what it is and that makes them feel like the website isn’t friendly to them. To those who do know what it is, it may be an indication that the application was not well thought out. Many badly written applications show stack traces way too often because it is the default in some frameworks like ASP.Net.

In any delivered product, the expected number of this type of error should be zero. The utility of this information to the customer is zero. On both counts, there’s no reason to present a stack trace. If there is some useful context, it should be presented in a customer-friendly way, not as a stack trace.

On the other hand, if the actual number of occurrences isn’t zero, you desperately need this information, and shouldn’t rely on the customer to send it to you. 99.99% of the time they will not. You should install a bug reporing system that submits the information automaically, with only an “ok” from the customer.

Short answer: In an extranet or internet site, it makes sense not to show the stacktrace. In an intranet the benefits of showing the stacktrace surpass those of hiding it.

Long answer:

The same happened to me at work. I used to think that if an app fails, it should fail noisily.

But then they explained to me that a potencial hacker could infere a lot of things from a stacktrace.

I think there is no need for proof. Is evident that the more a hacker knows about your platform the better for him and that the less a hacker knows about your platform the better for you.

Also companies are not eager to disclose how a hacker broke into their systems.

On the other hand, it’s an intranet, and I think that the advantages of knowing inmediatly what went wrong whitout having to search a log file is of great advantage and security risks of showing a stacktrace inside the boundaries of your company is not as high as they are saying.

You might take any information that you deem useful, encrypt it, create an email addressed to your support, add any plain text information that is useful to the user and explains what is happening, then add the encrypted data as an attachment. On your server side you automatically extract the information and pass it to support or a developer. Make it possible for the end user to send everything to their own support so they are not responsible for sending information outside their organisation.

So the end user can read the email and send it on or not. Or an alert shown has this as an option.

Filed under: softwareengineering - @ 09:03

Thẻ: error-handling, security, usability

Thiết kế website giá rẻ

Danh mục

Should a stack trace be in the error message presented to the user?

Security

User Experience

Your Reputation