ONEAPM Grand Lecture Hall | Java Exception Logging Best practices

"Editor's note" The writer is Casey Dunham. Casey is a professional software developer with more than more than 10 years of experience and is known for its unique approach to application security issues. This article is a domestic ITOM management platform OneAPM engineer compiled and collated.

As a security advisor, I evaluate a variety of applications. In all of the applications I've tested, I've found that they typically encounter some processing of exception problems and insufficient logging. Logging and monitoring are often overlooked areas, and because of the increasing threat to WEB applications, they have been added to one of the top ten issues of OWASP Top 10, called "Insufficient Logging and monitoring (not enough logging and monitoring )”。

What is the problem? Let's take a look.

who needs a log ?

First, why should we use logs? What's the point?

Proper logging is not only useful for debugging applications, but it also has many benefits for forensics and incident response. How do you know if someone is running a vulnerability scanner for your application? Or is a brute force attack program trying to access a user account? It's best to know about this, but there are other more subtle things.

Most successful attacks are from attacking the application and looking for its weaknesses. The more times an attacker investigates an application, the greater the likelihood that an attacker can find and successfully exploit the application's weaknesses. The attacker was able to keep the attack because its attacks were ignored, and because the average period of violation detection was 191 days, the log was usually the only way we could see that the attack was taking place. Without log information, it would be difficult to assess who was visiting and how deep it was.

Create and follow a logging policy

I seldom see an application with an actual logging policy. In most cases, our implementation of logging is already a matter of practice. I think it might be a strategy, but can we do better? I think we can.

When you add logging to an application, it is best to have a consistent policy overall. Use the same logging framework wherever possible in all applications. This allows for easy sharing of configurations, such as message formats, with consistent logging patterns. There is a consistent guideline for when to log warnings/errors and which logging levels to use. When you log anything, the message format should contain at least the timestamp, the current thread identifier, the caller ID, and the source code information. All modern logging frameworks support this type of information.

All of this is a great way to create and maintain logging in all business applications, as part of the developer documentation.

log the full stack trace

In many of the security code previews I've done, one of the errors I've often seen is that you don't log the entire stack trace to find an exception. Take this assumption as an example, which is a typical error pattern I've seen several times:

There are several problems with this example, and we only focus on the part dealing with SQLException. For example, when we look at the logs in production, we see this:

This does not tell you a lot of information. What caused the sqlgrammarexception? The logger categorizes all exceptions that contain thrown objects and writes out the stack traces. By slightly changing the code, we can get a clearer picture of what's going on:

With this code we can record the stack trace in full, and the records clearly show that some of the evil activities are being quietly carried out.

Now, as soon as we look at the logs, we can see the problem immediately. Someone tried to find the customer with Acme ' and broke our SQL statement. This exception explicitly shows SQL injection, which is easy to ignore if we only see the original message when we parse the log. It is likely that we have not considered this issue in depth and turned to other issues, leading to the failure to find this serious flaw.

Log all Exceptions

The "engulfing" exception is another common problem I see: Throwing an exception somewhere in the application that the developer intends to handle with a catch block, but for some reason the developer forgets it or finds it unimportant. The following example illustrates this problem:

In my experience, this practice is very common and worth mentioning. Log the exception, re-throw the exception, or not handle the exception at all, and the logs do not show any problems with the application. We have no reason not to log exceptions. An exception such as "engulfing" causes the underlying problem to be overlooked and ultimately leads to business logic or security breaches.

do not return exceptions to the user

Each piece of information about an application or its environment may be useful when performing any type of security assessment. The seemingly harmless error message may be what the consultant (or the attacker) needs. Consultants may find a loophole in your system-attack the system or significantly reduce the payload, and if the error message reveals information about the database system that the vulnerability is using, then we need to do a SQL injection test of the vulnerability.

It is also a common practice to simply return an exception message to the user through some sort of error handling. When I tested the authentication system, I ran into a lot of problems, as shown in the following screen:

The code that handles the problem might do this:

Later, the exception is thrown and captured. The developer uses the exception information to write the error message that is communicated to the user, which causes the user to see the system's original exception information.

In the case of exception handling, this is not only a bad practice, but it also opens the application for user account validation. Depending on the type of application you are working on, this may be a risk in itself.

Do not return the contents of the exception object to the user. Catches an exception, logs it, and returns a generic response. As the code evolves, you never know what information the exception message might contain, and whether the exception message itself will change in the future.

do not log sensitive information

I mentioned that logs can be used not only for debugging, but also for compliance, auditing, and forensics. Because logs have many uses, and we tend to "record everything", they can be an amazing source of information. If the log contains a user name, password, session token, or other sensitive information, it does reduce the workload of the attacker. The log will reveal the internal work and failure of the application, which can be used by attackers to further attack the application. Therefore, we need to treat the logs with care and keep them safe. Information that should not be logged is as follows:

• Credit card number

• Social Security Number

• Password

However, the following types of information should not be written to the log:

• Session identifiers

• Authorizing tokens

• Personal name

• Phone number

• Information that the user chooses to exit (for example, do not track)

There is also a problem: some jurisdictions do not allow the tracking of certain information, which violates the law. It is important to understand the compliance requirements of an application and the data it processes.

don't let yourself be in the dark.

Although logging is not a complex task, there are many subtleties and points of balance in the proper use of logs. Too little information is less valuable, but if handled improperly, too much information can become a burden.

Logging the Application log is not a choice question, there is not enough log, you will be in the dark.

OneAPM Li The Intelligent Log Analytics platform collects massive logs, real-time search, real-time analysis, and insight into the value of the data center infrastructure and applications in real time. To read more technical articles, please visit the OneAPM official technology blog .

Original address: https://blog.scalyr.com/2018/03/java-exceptions-log/

ONEAPM Grand Lecture Hall | Java Exception Logging Best practices