Java configuration: how to prevent security misconfigurations

Java configuration is everywhere. With all the application frameworks that the Java ecosystem has, proper configuration is something that is overlooked easily. However, thinking about Java configuration can also end up in a security issue if it is done in the wrong way. We call this misconfiguration. Security misconfiguration is part of the infamous OWASP top 10 vulnerability list and has a prominent spot on place 6.

Wrongly configuring your Java application can lead to security issues. First of all, defaults may turn out to be convenient as it makes a library or framework work instantly. Nevertheless, these defaults are not always the safest Java configuration as they might disclose information that is both great for debug reasons, but also disclose information that is interesting for intruders.

Java configuration issues

One of the most famous examples is the misconfiguration of the XML parsers in Java. In the 

10 Java security best practices cheatsheet, we already discussed the possibility of XXE attacks because of misconfiguration. I also explained in this youtube video that the default Java configuration for all XML parsers is vulnerable. By simply putting in the correct configuration and disabling external entities, we prevent possible XXE attacks.

Another example is proper Java configuration for your error handling. No matter how well written your Java web application is, somehow, an exception will turn up eventually. If an exception is not uncaught—and, therefore, not handled in, for instance, a JSP application—the default behavior is to display the exception and the stack trace in the browser.

This doesn’t only show that you are using Java, but also what kind of internal package you utilize. In many cases, these exceptions may also include specific information like IDs. None of this information is useful for the user and even harms the user experience. More importantly, this exposes information that might be valuable to people who have less good intentions when using your application.

By configuring for error pages, as seen below, you redirect the user based on a return code or an exception-type without displaying internal information.

<error-page>
   <error-code>401</error-code>
   <location>/ErrorPage401.jsp</location>
</error-page>

<error-page>
   <exception-type>java.lang.Throwable</exception-type>
   <location>/ErrorPage.jsp</location>
</error-page>

Configuration issues in Java libraries and frameworks

Using java libraries and third-party packages to do some of the heavy lifting for you is a great approach. However, you should be aware that configuring these tools appropriately is crucial for your security strategy. Luckily, most library maintainers make sure that the default values are entirely secure. However, changing them might look convenient but can get you in a whole lot of trouble.

Let’s look at Jackson, for instance, a well-known library that is widely used to parse JSON to POJOs and visa-versa. When misconfiguring the Jackson library and allowing “default typing”, you can deserialize arbitrary objects that are available on the classpath. This might lead to the same sort of deserialization vulnerabilities that existed in Java’s native serialization.

Thankfully, by default, this feature is disabled and, therefore, a deserialization issue with code execution, for example, is far less likely to happen. However, if you change this configuration in your java application and enable it, you might introduce unwanted security risks.  

Spring configuration issues

Spring Framework is the most popular application development framework for Java. The main feature of the Spring Framework is dependency injection or inversion of control. 

Spring Boot is basically an extension of the Spring Framework. It allows us to build a stand-alone application with minimal or zero configurations. Spring Boot has a number of starter components that bring in features by simply importing the correct dependency.

Spring Boot Actuator

By adding the spring-boot-starter-actuator dependency to your manifest, Spring Boot Actuator gives you a number of endpoints that are interesting for maintainers and developers. 

You can think about the env endpoint, which shows you environment properties, for example, what’s in the classpath, the beans (all Spring beans in the app),the threaddump, and shutdown endpoint. Check the complete list in the documentation. 

By default, all these endpoints are enabled but, luckily, not all are exposed via HTTP by default. Nevertheless, configuring these default endpoints and enabling them for web or JMX is easy. Also, it an easy thing to turn off when going to production. Having the following line in your properties exposes all endpoint (except the shutdown endpoint) to the web:

management.endpoints.web.exposure.include=*

Be aware to only enable and expose the endpoints in production that you actually need. Preferable, by blocking everything except a few, instead of the other way around.

management.endpoints.enabled-by-default=false
management.endpoint.info.enabled=true
management.endpoints.jmx.exposure.include=health,info
management.endpoints.web.exposure.include=env,beans

In addition, make sure that the endpoints are only available by authorized systems and people by including and configuring spring-security correctly for these endpoints.

Spring Boot developer tools

As the name suggests this Spring Boot component is an additional set of tools that is helpful during development and makes the application development experience a little easier. Things like automatic restarts, remote debugging, and remote updating make this feature set extremely helpful for development.

According to the Spring documentation this is the default behavior: “Developer tools are automatically disabled when running a fully packaged application. If your application is launched from java -jar or if it is started from a special classloader, then it is considered a “production application”. 

However by setting the property spring.devtools.restart.enabled you can overwrite the safe default behavior. 

Conclusion

In general, we should be aware that your Java application configuration is just important as writing the code itself. When using frameworks and libraries you should be aware of what the default configuration settings are and if certain changes have security implications.

Giving too much information away by leaving debug logging or enabling endpoints or features that are in place for development purposes will hurt your application and your company. 

This holds true for both application frameworks and libraries, but also for the settings of your webserver. Remind yourself that exposing information might not be harmful at first sight, but if you combine all these bits and pieces of information you will give an attacker enough ammo to do something, potentially, malicious.

Using libraries, frameworks, and even application servers is very useful but you should be aware of how they work. Java configuration and misconfiguration is a serious thing. Make sure that you are not accidentally giving people access to your application because you forgot to set a specific property in your configuration.