4

Is it possible to expose sensitive application or system information via Java Exceptions when trust boundaries cross?

I mean, not just theoretically but if that happens in real environment.

e.g. java.io.FileNotFoundException might tell the caller about my application's file system structure etc . java.util.ConcurrentModificationException might give info about non-threadsafe classes of my app.

Can this situation be handled in any other way than the below two?

  1. Use Sysouts ( with only a customized message ) instead of throwing exceptions for codes which are supposed to be accessed by others?

  2. If its mandatory to throw exception, sanitize your messages and then throw exception

I am also wondering if point # 2 is completely avoidable and there would not be any mandatory situations for throwing exception.

My question is not about any specific application but programming practice in general ( where inter - application communication is needed in large enterprises like two different Banks etc ).

Sabir Khan
  • 9,826
  • 7
  • 45
  • 98
  • 6
    I personally think exceptions should be used always as sensitive since they also contain a stacktrace and other data, exceptions should NOT be shown to users in production environments. But giving exceptions them to the people who use your api is a good way to help them debug faster – Ferrybig Jan 08 '16 at 08:54
  • 2
    What do you mean with "trust boundaries" specifically in the context of Java application (this term can be interpreted in many ways). That will help give a more specific answer. – Erwin Bolwidt Jan 08 '16 at 09:08
  • @ErwinBolwidt- say one company is hosting a paid java webservice to be used by another organization or so. – Sabir Khan Jan 08 '16 at 09:29
  • An answer to the question was just deleted, where the user suggested to write own exceptions with less verbose output. Why is this considered bad practice? I am not sure if the stack trace was still visible (as the answer was deleted too fast for me to fully understand it). – hamena314 Jan 08 '16 at 09:36
  • @hamena314: I saw that too and that is what I meant in my point # 2 in question – Sabir Khan Jan 08 '16 at 09:38

1 Answers1

2

The most common way of exposing sensitive information is to give the user (client) of the program a stack trace.

A stack trace is useful for programmers debugging a problem, and not to anyone else. So logging code should not output stack traces as a matter of course. It should output them only when an exception indicates a bug in the program. And it should output them where they can be made available to a programmer, but to as few others as possible.

If a program has a log file invisible to normal users of the program but visible to administrators (as is the case with servers), that is an appropriate place to log stack traces.

Similarly arguments apply about other sensitive information.

Although your question is entirely about security concerns, this can be considered too as a user experience (user interface) issue: the messages you give to the various users of the program should be appropriate for those users, and should provide them with information that is useful to them, without extraneous information that could confuse them. In particular, the message text of an exception should not be reported to users (but should be include as part of any stack trace).

For a client-server program, the clients have no interest in the details of why the server failed to process a request sent by the client. They need to know that the request did fail. If the request failed because of a problem with the server, rather than a faulty request by the client, they need to know that is the case, so they can contact the administrators to fix the server. If the request failed because the client sent a faulty request, the client should be told that, with a description of what was faulty about the request, so the client can send a corrected request.

Also, beware that not all exceptions indicate a problem that some user must be told about. If the program automatically handles the condition signalled by an exception, in many cases there is no need to tell the user at all about the condition signalled by the exception.

Community
  • 1
  • 1
Raedwald
  • 46,613
  • 43
  • 151
  • 237