21

It is a known fact that exposing the exception information to the end user provides security risks since an adversary can user that to figure out how things work internally and attack it. But what about a web service, where that information might be relevant to the developers that consume the API?

On one hand exposing full stacktrace and even the message is risky since it might contain some database information e.g. on the other hand if something goes wrong and the server just says 500 "sorry", then developers would be frustrated. I guess really the proper way is to handle all exceptions you know of in a secure manner, i.e. catch business/validation exceptions and return it back with special error codes and messages (no stacktrace) and for all unknown still make 500 "sorry".

But I would like to here what are the common ways of doing it and which approach should be taken from security point of view.

Ilya Chernomordik
  • 2,197
  • 1
  • 21
  • 36
  • Relevant: https://www.owasp.org/index.php/Information_Leakage – d0nut Apr 25 '16 at 14:02
  • 8
    My approach designing an interface is usually the same as the law's: *Anything you say can, and will, be used against you*. Don't share anything you don't need to. – 1ace Apr 25 '16 at 15:32
  • Google Dorks - Google cached stack trace/error dump pages containing anything from obtuse jargon to explicit access credentials. I've come across several that give away the keys to the kingdom. Writing this to a local file would have saved the embarrassment from that one error catch routine that someone forgot to sanitize. – Fiasco Labs Apr 25 '16 at 17:43
  • @1ace that is *extremely* clever. I will definitely use that whenever someone tries to argue with me that it's okay to leave stacktraces accessible to users. – d0nut Apr 25 '16 at 19:22
  • I would not call this question a duplicate. The difference is between end users and developers. – Stig Hemmer Apr 26 '16 at 09:44
  • I don't think so either, since the part of the question here is really how to properly handle the exceptions and give that information to the developers consuming the API. – Ilya Chernomordik Apr 26 '16 at 10:41
  • This question is not a duplicate - it's specific to web services rather than websites. – Fahim Farook Jan 23 '19 at 19:37

3 Answers3

27

The API should not expose any internal information, i.e stack traces or similar. As you really noticed they might leak information which might be used to attack the implementation.

Moreover they are usually only relevant for the developer of the API and not the user of the API. These users expect proper error messages anyway and not some strange message where they would need to ask the API developer first what this means and the developer would need to look at the source code. So this might be less a security issue but more a usability problem of the API if you just throw the stack trace to the user instead of something meaningful for the user.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 6
    And you can still dump the stack trace to a log file (if you can catch the exception) together with some user info in case you want to know more when the user reports "Yesterday around two o'clock I was doing ...., and suddenly..." –  Apr 25 '16 at 14:59
  • Where possible I try to give the users a short code that identifies the exception with the text "when contacting support or your systems administrator, please quote this to help us look into the issue more quickly". Good users will do just that and you then don't have to deal with approximate times and other guesswork or Chinese whispers between you and them. "Bad users" will forget to note it - they get their problems dealt with more slowly than good users - and of course a really bad exception may block the log and code generation, but often it can be very useful. – David Spillett Apr 25 '16 at 19:57
7

Usually, there are two kinds of exceptions:

  • Expected exceptions, like invalid input values; or authentication failure; or asking for non-existing object. So you can (and should) be prepared to deal with this kind gracefully, with descriptive and documented error code and message. There is no point of stack trace in this case.

Youtube invalid video code

  • Internal (or unexpected) exceptions: unavailability of database; insufficient memory; bug in your code leading to NPE. There is also no point in stack trace for API user. You (as a developer), however, have interest in such stack traces. For the most cases, user itself can't solve such problem, so he must contact the developer. You can attach encrypted stack trace to a generic "sorry" message, so you as the developer can resolve user problem more easily:

Youtube internal error

deniss
  • 193
  • 5
  • 10
    Or put it in a QR code so that you can still recover the data when they inevitably send you a screenshot instead of pasting the text. – Random832 Apr 25 '16 at 16:44
  • 6
    It's probably better to log the stacktrace on the server and associate it with an special ID and send the user just the ID as in "If you want us to look into this please contact us and report us the following ID: xxxxxxx". – Bakuriu Apr 25 '16 at 19:41
  • 1
    @Bakuriu, you are probably right, but it is a whole new question why youtube did it this way. I think it is not always possible to log critical error in a reliable way, but spitting it to the user is as easy as "print(encrypt(stacktrace))". – deniss Apr 25 '16 at 19:51
  • A common terminology for this distinction are *client* vs. *server errors* (cf. the SOAP specification) – meriton Apr 26 '16 at 00:38
  • Actually, there are [three kind of exceptions](https://blogs.msdn.microsoft.com/ericlippert/2008/09/10/vexing-exceptions/). – Pharap Apr 26 '16 at 04:17
  • @Pharap Your link literally mentions **four** kinds of exceptions. – ruohola Dec 20 '19 at 16:19
  • @ruohola "There are two hard things in programming: cache invalidation, naming things and off-by-one errors" – Pharap Dec 20 '19 at 19:49
4

It is a problem of usability vs. security.

  • An API, specially a REST one, should be friendly, self-documented. This includes giving friendly errors indicating the exact error, possible cause, stack, etc.

  • In the other hand think that friendly is risky...

So the answer is: Yes, it is a security problem. The information will help a potential attacker to know more about your API.

Common ways of doing it?

In ASP.NET you have setting in web.config to control how verbose are the errors (CustomErrors).

Default settings shows a generic safe error, except that you are browsing from the same computer, then it shows full error. This way developers in their local computers can see the errors but once deployed to an environment detailed error information cannot be seen.

<?xml version="1.0"?>
<configuration>
    <system.web>
        <customErrors mode="Off"/>
    </system.web>
</configuration>
Oscar Foley
  • 850
  • 1
  • 7
  • 12