56

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?

Andreas
  • 103
  • 5
Vilx-
  • 5,320
  • 4
  • 20
  • 24
  • 29
    Wow. Just... wow. "`Unfortunately there has been some kind of "Security audit"`" - Seriously? What kind of attitude is that? The security audits are for *your* benefit - to make your systems better, to find the problems before the bad guys do. You should really consider trying to work with them, not against them. Also, you could try to get more information on the security PoV over at [security.se]. – AviD Aug 23 '12 at 18:42
  • 8
    And btw, a security audit does not necessarily need access to the source code, they probably did a black-box penetration test, simulating what a malicious user would do - try to attack the application as a user. Though I agree that access to the source code could have enabled a much more effective form of audit. :-) – AviD Aug 23 '12 at 18:44
  • 2
    @AviD - in truth, I don't know what they analyzed, but from some reports I saw it seemed like a black-box test to me. To be honest, I don't want to work against them. Indeed, I did like the news when I heard them. But this particular "vulnerability" of theirs seems silly to me. In every security decision you have to weigh the threat reduction against the usability reduction. In this case I think it reduces the usability a lot more than it improves security. – Vilx- Aug 23 '12 at 19:52
  • 1
    I agree very much about the weighing, but I disagree about its application. It harms security more than you think, and I also think that your way (having done this myself, too, until I talked to some of the users.....) is worse for usability. Think of it in task-oriented terms - as @Jon's answer said, his way gets the user's job done much better. The user doesnt need to care about the stack (unless your users are the developers...) But, my expertise is in security - and the risks are real. – AviD Aug 23 '12 at 19:58
  • 2
    @AviD - Maybe you can point me to some resources that explain *how* a stack trace can be dangerous? I'm ready to accept that, but I want something more than the general priciple of "only show what you need to". – Vilx- Aug 23 '12 at 20:06
  • 1
    e.g the sec.se question linked to by @oleksi - http://security.stackexchange.com/questions/4471/is-it-a-vulnerability-to-display-exception-messages-in-an-error-page. – AviD Aug 23 '12 at 20:08
  • 1
    If you have further questions along the same lines it would be better to ask them on [Security](http://security.stackexchange.com/) Stack Exchange where the experts hang out. – ChrisF Aug 23 '12 at 21:02
  • @ChrisF - [Way ahead of you](http://security.stackexchange.com/questions/19130/is-a-stack-trace-of-a-server-application-a-vulnerability) :) – Vilx- Aug 24 '12 at 07:24
  • 2
    Far more useful than a stack trace is to tell the user the *precise time* of the problem (in the timezone of the logfile, ideally in [UTC](http://en.wikipedia.org/wiki/UTC)), and encourage them to tell you that time, so that you can go straight to that point in your log file. – Mark Booth Aug 24 '12 at 09:35
  • @MarkBooth - a unique ID serves the same purpose, but I suppose that adding time won't hurt either. Thanks! :) – Vilx- Aug 24 '12 at 10:14

8 Answers8

80

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.

Jon Egerton
  • 946
  • 8
  • 13
  • 6
    I like your answer because it presents a "middle road" - don't show, but make the looking-up of exceptions easy. I'll try to push for that now, I hope that they will agree. Thank you! – Vilx- Aug 23 '12 at 14:55
  • 2
    I think this is pretty much the standard "mature" approach. Also, stacktrace does give a wealth of information, however I'm yet to find a solution which can automatically log state information along with the stacktrace (without code changes everywhere). It seems that writing your own debugger and attaching it is one possible way to go, but far from trivial to implement. – Daniel B Aug 24 '12 at 12:09
  • @DanielB: In web apps its possible to get hold of some common stuff (like userid, clientid etc) from session/cache - as it's persisted "globally", even this much information can help reproducing errors greatly. More granular than that is very tricky through as you say. – Jon Egerton Aug 24 '12 at 13:03
  • @JonEgerton good point, and I guess almost everything else you'd need to reconstruct the error is available in the Request object, in an easy-to-serialise format. But yes, I was mostly referring to non-web environments, local variables, etc. I guess the stateless nature of web applications is a big advantage in this regard. – Daniel B Aug 24 '12 at 13:07
  • 3
    Some users of very critical applications demand immediate solutions to any error that impede the normal course of business. All the communication process involving various diciplines just for the error-solver to get ahold of the error stack can easely consume 1 hour or more when the error happens late at night or weekends. – Tulains Córdova Nov 05 '12 at 14:40
  • 1
    @user1598390: Agreed, in which case the copying of the error details to a monitored support mailbox can expedite the gathering of information, to the point that the support staff know something is broken even before the user does. – Jon Egerton Nov 05 '12 at 14:50
36

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.

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
  • 8
    I agree for the most part, but some of these things shouldn't matter. For example, what encryption algorithm you are using shouldn't have to be secret to secure your system. – Oleksi Aug 23 '12 at 14:47
  • 3
    It shouldn't matter, but the world is imperfect, and often it does. That's why defense in depth (doing many things simultaneously that *should* be enough if they were perfect) matters. – Kilian Foth Aug 23 '12 at 14:53
  • 4
    Quite frankly, if a stack trace reveals *anything* that could help an attacker, then you are [doing it wrong](http://en.wikipedia.org/wiki/Security_through_obscurity)! – Mark Booth Aug 23 '12 at 17:16
  • 3
    @MarkBooth statistically speaking, you probably *are* doing it wrong. No, scratch that - statistical **certainty** that you are getting some of it wrong. Do you really want to let the attackers find your security bugs before you do? – AviD Aug 23 '12 at 18:55
  • @AviD - Absolutely, security is hard, but sadly my sarcasm was only implicit. I was under the impression that the [You're doing it wrong meme](http://knowyourmeme.com/memes/youre-doing-it-wrong) would have been more widely recognised though. Maybe saying that security was just a *"small matter of programming"* ([SMOP](http://en.wikipedia.org/wiki/Small_matter_of_programming)) would have been recognised more easily as a joke. – Mark Booth Aug 24 '12 at 09:10
  • @MarkBooth my bad, I do know that meme... Joking aside, my point was that that is the reason for defence in depth - one part of which is not revealing the stack trace *just in case* (with a high probability) that you have other security flaws to be found. – AviD Aug 24 '12 at 09:19
  • 1
    @AviD - No, I agree, the most compelling reason to not display stack traces to users is that they have no idea what to do with them, and your logging system should be both secure and able to capture far more state than a screen grab of a web page ever could. – Mark Booth Aug 24 '12 at 09:30
18

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.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
12

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.

Community
  • 1
Oleksi
  • 11,874
  • 2
  • 53
  • 54
9

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.

Tom Resing
  • 191
  • 1
  • 4
  • 6
    As a Software developer, when I see a stack trace on the screen, my immediate though is "Here's a bozo who knows nothing about dealing with errors, cares less about them, and and probably even less about users". Others revolve around "this is crappy software, not on does it not work, its error handling doesn't work" and "WTF.... I'm not doing this guys job for him" What your user wants to know is what he needs to do to fix it. How does the stack trace do that. – mattnz Aug 24 '12 at 01:55
7

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.

Tulains Córdova
  • 39,201
  • 12
  • 97
  • 154
  • 1
    what are some of "the advantages of knowing inmediatly what went wrong", and why can't they be retrieved from a log file? It would seem that with an Intranet, you could access a log file even more easily than from a client site. – Wonko the Sane Aug 23 '12 at 15:48
  • In my scenario, there are critical applications that have "7/24" priority. User call help desk, if the problem is an application error or exception, help desk calls the maintainer who maybe is off the premises. Whith the error info the expert can instruct an on-site person to a workaround... Often times the time saved is precious if the app is business-critical. if the expert that if off the premisses has first to connect to the company, search the log, etc., a critical business function could be waiting unnecessarily. – Tulains Córdova Aug 23 '12 at 16:23
  • 3
    @user1598390 so build a log viewing mechanism. A simple web page, input the incident id, and the helpdesk can see the entire relevant log. Of course limit access to this feature, and so forth... – AviD Aug 23 '12 at 19:04
  • Just because an app is on your company's intranet doesn't mean there aren't malicious users on it. There are plenty of disgruntled employees out there who might very well misuse an internal system for their own benefit. Since these employees know a lot about the company and its policies they could actually be more dangerous than an internal hacker. Going through log files is a pretty trivial task, especially if you're following good practice and also log errors to a specific error log file. – cliff.meyers Jul 25 '13 at 20:44
7

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.

ddyer
  • 4,060
  • 15
  • 18
  • 2
    I would upvote this answer for the following line alone: *"The utility of this information to the customer is zero."*. Any technical details about the internals of a product should be hidden unless there is a good reason not to do so for the simple reason of simplicity and usability for the end user of the product. – Kjartan Apr 17 '15 at 08:56
0

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.

gnasher729
  • 42,090
  • 4
  • 59
  • 119