Blog | G5 Cyber Security

Insurance Site Leak: Java StackTrace Exposure

TL;DR

An insurance website is publicly exposing detailed stack traces from its Java-based JSON parser when errors occur. This reveals internal code structure and potentially vulnerabilities. We’ll cover how to identify the issue, why it’s bad, and steps to fix it by disabling detailed error reporting in production.

Understanding the Problem

When a web application encounters an error while processing data (like parsing JSON), it often generates an error message. A stack trace is a report showing exactly where in the code the error happened, including all the functions that were called leading up to the problem. While incredibly useful for developers during testing and debugging, exposing stack traces to the public on a live website is a serious security risk.

Here’s why it’s dangerous:

Step-by-Step Fix

  1. Confirm the Leak (if you haven’t already):
    • Try sending invalid JSON data to the website’s API endpoints. For example, a missing closing bracket or an unexpected character.
    • Examine the response carefully. Look for error messages that include long blocks of text with lines starting with “at…” – these are stack traces.
  2. Identify the Logging Framework:

    Most Java applications use a logging framework like Log4j, SLF4J (with a backend like Logback or java.util.logging), or similar. You need to find out which one your application uses.

    • Check Application Configuration: Look for configuration files named log4j.properties, logback.xml, or similar in the application’s deployment directory.
    • Examine Code: Search the codebase for imports like org.apache.log4j.*, org.slf4j.*, or java.util.logging.*.
  3. Disable Detailed Error Reporting in Production:

    The goal is to configure the logging framework to log errors without including full stack traces in production environments.

    • Log4j (Example): In log4j.properties, adjust the appender configuration for your error logger. Change a line like this:
      log4j.appender.errorAppender = org.apache.log4j.FileAppender
      log4j.appender.errorAppender.layout = org.apache.log4j.PatternLayout
      log4j.appender.errorAppender.layout.ConverterMap={org.apache.log4j.spi.ThrowableInformationAppender=false}

      to:

      log4j.appender.errorAppender = org.apache.log4j.FileAppender
      log4j.appender.errorAppender.layout = org.apache.log4j.PatternLayout
      log4j.appender.errorAppender.layout.ConverterMap={org.apache.log4j.spi.ThrowableInformationAppender=false}
    • SLF4J/Logback (Example): In logback.xml, modify the logger configuration for your application:
      <logger name="your.application.package" level="ERROR" additivity="false">
        <appender-ref ref="errorAppender"/>
      </logger>

      Ensure that the appender configuration (e.g., errorAppender) does not include a ThrowableInformationAppender or similar component.

    • java.util.logging (Example): Configure the logging level to avoid printing stack traces. This is often done through system properties or a configuration file.
      java.util.logging.level = ERROR
  4. Restart the Application:

    After making changes to the logging configuration, you must restart your application for the new settings to take effect.

  5. Verify the Fix:
    • Repeat the test from Step 1 (sending invalid JSON).
    • Confirm that the error response no longer includes detailed stack traces. You should see a more generic error message instead.

Additional Considerations

Exit mobile version