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?
Use Sysouts ( with only a customized message ) instead of throwing exceptions for codes which are supposed to be accessed by others?
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 ).
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.
Related
Which is more suitable out of these two exception object (e) or e.getMessage() for log.info() and log.error() or log.debug().
What should be followed/rule of thumb for different logging levels.
It really depends on the reason of the exception being thrown. I would add here WARN level consideration as well. If this is an unexpected error that should not happen, meaning that this is something wrong with codebase you should definitely log the whole exception object, especially to get the stacktrace that allow developer to find and potentially fix issue faster. Therefore such situation should be logger on ERROR level if this is something wrong with the system, or WARN if this is something wrong with client's data.
INFO level should really not contain exception details, it should keep information easy to read by non-developers(for example testers) and describe the most important parts of the data processing flow.
I think it is up to you to put exception in DEBUG level but I would still recommend not to do it just to keep things clearer OR use e.getMessage() to describe it.
P.S. In general, I would redirect this question to this page since it is a general SE question but since you asked about using particular Java feature I wanted to keep things in the right place.
Don't try to create a fixed rule about including or not including the stacktrace depending on the log level. Instead, when creating a log entry, ask yourself:
Who will read that entry? A user, a system administrator, or a developer?
What information will be useful to that reader for understanding the situation? It's better to add too much information than to omit important parts.
If the entry is to be read by a developer, is the text enough or should I include the stacktrace? Non-developers typically get confused when seeing a stacktrace, but developers very much appreciate it.
This will greatly improve the quality of your logging.
As a very rough rule of thumb, include the stacktrace whenever you log an exception. An exception means that something went wrong, which might involve analysis by a developer, who will be very unhappy if the log entry only reads "NullPointerException" without a hint where it came from.
Of the typical log levels, INFO might be the one not addressing developers (thus not asking for a stacktrace), but generally you don't want to use INFO for exceptions.
Is it possible to create something like an event in java which will be triggered if an Exception was thrown?
I want to make something like a exception tracking system which sends all Exception to a central server.
Is this possible or do I have to call a method on myself within every catch block?
The recommended way to handle this would be with logging (for example SLF4J and Logback). You can configure loggers to send the messages to a centralized logging server, but you still need to manually log the exception and if applicable, handle it.
If you were hoping for an automagical way to just forget about exceptions, that's not really possible. Exception handling is not as easy as it may seem, if you intend to make your applications robust and easily debuggable.
A good additional "trick" is to use Thread.setDefaultUncaughtExceptionHandler() to provide a final fail-safe. Its only job should be to log any exceptions that aren't handled elsewhere. However it should happen only in case there's a massive failure and the stacktrace might otherwise be lost. If it's being invoked just because some input was of the wrong format, your design and code is of poor quality.
I am writing a wrapper around the DefaultHttpClient to handle some of the error-prone configuration options.
For example I will pre-configure everything to handle UTF-8 properly and to shutdown the connection cleanly.
When a non-200 is returned, I thought about the client registering a handler for a specific status code and then calling it.
I would provide some default handlers to take care of simple cases.
Is this a good pattern for a clean API? If I throw exceptions, the client has to handle cases which might not happen at all as I would have to throw an exception per possible HTTP status code (or most).
The thing I like about handlers is that I can provide a couple of 'default handlers' which might be overwritten...
I'd like to hear your input and maybe get some more creative ideas.
Cheers
Currently, accepted practice for Java APIs is to employ unchecked exceptions, so client won't need to change it's internal code just to accommodate API's exceptions into client's codebase.
Instead, if you use unchecked exceptions, you'll save your code unchanged except the places where you really need to handle exceptions.
Here're slides about Robert Martin's "Clean code" book which talk about error handling best practices: slides.
I wouldn't create a different exception for each http error code. At most create one or two general exceptions and store the exact error code as part of the exception. That way if the client code just wants to log or ignore them it can, or it can get more details based on the error code.
Errors/Exceptions in applications are currently logged to a log file. Unless someone examines these log files, we don't get visibility into number of errors happening. We are looking for a web application that can display different types of exceptions, their stats (graphs), etc. so that anyone can easily look at the interface or set up monitors to send an email when more than x errors happen in an application.
What are the best practices to monitor for exceptions and get notified?
Try JSnapshot, it may be very useful for you.
This question already has answers here:
Closed 12 years ago.
Possible Duplicates:
Where/what level should logging code go?
Debug Levels
Is there a convention, a standard, or a widely used guide which will help with logging in Java? Specifically, what to include at each level (verbose, debug, ... etc.) rather than the actual mechanism of logging.
There are many guides out there of what to include at each log level, but none of them are specific; they're all vague, and this makes it hard to "follow orders".
Any tips would be appreciated.
It's subject to personal interpretation, but mine is (in order from finest to coursest):
Trace - The finest logging level. Can be used to log very specific information that is only relevant in a true debugging scenario, e.g., log every database access or every HTTP call etc.
Debug - Information to primary help you to debug your program. E.g., log every time a batching routine empties its batch or a new file is created on disk etc.
Info - General application flow, such as "Starting app", "connecting to db", "registering ...". In short, information which should help any observer understand what the application is doing in general.
Warn - Warns of errors that can be recovered. Such as failing to parse a date or using an unsafe routine. Note though that we should still try to obey the fail fast principle and not hide e.g., configuration errors using warning message, even though we a default value might be provided by the application.
Error - Denotes an often unrecoverable error. Such as failing to open a database connection.
Fatal/Critical Used to log an error the application cannot recover from, which might lead to an immediate program termination.
In the end it's up to you to define what suits you best. Personally, I run most production system with logging level of Info, where I'm mostly interested in following the applications main logic, and of course catch all warnings/errors.
Except for code cluttering, there is no such thing as too much logging. All logging which helps you reproduce or understand problems better are good logging. On a performance note, most logging systems (e.g., log4j) allows configuring which level to actually append to the physical log which is a great thing.
For what it's worth, we're using the following log levels:
DEBUG level messages give highly-detailed and/or specific information, only useful for tracking down problems.
INFORMATION messages give general information about what the system is doing. (e.g. processing file X)
WARNING messages warn the user about things which are not ideal, but should not affect the system. (e.g. configuration X missed out, using default value)
ERROR messages inform the user that something has gone wrong, but the system should be able to cope. (e.g. connection lost, but will try again)
CRITICAL messages inform the user when an un-recoverable error occurs. (i.e. I am about to abort the current task or crash)
I think the most important thing with log levels is to figure out a scheme, document it, and stick with it. Although making log level consistent between programs would be nice, as long as you've used common sense in defining your log levels, users will tolerate a certain amount of variance between programs.
Simple log what yuo think is important if you were to come back later and need to read the logs. This of course means that your Object.toStrings now need to be nice and readable and not a dump of crap thats impossible to read. This also means you need to do sensible things like quoting strings etc..