Insecure or unset HTTP headers - Content-Security-Policy - Java

Insecure or unset HTTP headers - Content-Security-Policy - Java

Need

Implementation of secure and properly configured Content-Security-Policy headers

Context

  • Usage of Java 8 for developing applications with enhanced features and performance
  • Usage of javax.servlet-api for developing Java web applications with Servlets

Description

Non compliant code

        import javax.servlet.http.HttpServletResponse;

public class UnsafeHeaderServlet extends HttpServlet {

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // ... some code here ...
    }
}

The above Java servlet does not set the Content-Security-Policy HTTP header in its responses. This is a security vulnerability because the Content-Security-Policy header is used to prevent Cross-Site Scripting (XSS) attacks and other code injection attacks resulting from execution of malicious content in the trusted web page context.

The Content-Security-Policy header allows you to create a whitelist of sources of trusted content, and instructs the browser to only execute or render resources from those sources. Even if an attacker can inject a script tag into your HTML content, the browser will not execute the script if the script's source is not in the whitelist.

In the above code, the doGet method sends a response to the client without setting the Content-Security-Policy header. This means that the response could potentially contain malicious script that the browser will execute.

Steps

  • Understand the purpose of the Content-Security-Policy header and its importance in web application security.
  • Determine the appropriate security policies that need to be defined in the Content-Security-Policy header based on the application's requirements.
  • Ensure that the Content-Security-Policy header is included in the server responses.
  • Define the mandatory security policies in the Content-Security-Policy header to enforce secure behavior.
  • Avoid using insecure values in the security policies, such as 'unsafe-inline' or 'unsafe-eval'.
  • Regularly review and update the Content-Security-Policy header as needed to adapt to changes in the application's requirements and security best practices.

Compliant code

        import javax.servlet.http.HttpServletResponse;

public class SafeHeaderServlet extends HttpServlet {

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // Define the Content-Security-Policy header
        response.setHeader("Content-Security-Policy", "default-src 'self'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';");

        // ... some code here ...
    }
}

The above code fixes the vulnerability by setting the Content-Security-Policy header in the server's HTTP response. The Content-Security-Policy header is a security feature that helps prevent attacks such as Cross-Site Scripting (XSS) and data injection attacks. It does this by specifying the domains that the browser should consider as valid sources of executable scripts.

In the fixed code, the Content-Security-Policy header is set to only allow resources (scripts, images, stylesheets, etc.) to be loaded from the application's own domain ( 'self'). This is done using the setHeader method of the HttpServletResponse object.

The default-src 'self'; directive sets the default policy for fetching resources such as JavaScript, Images, CSS, Font's, AJAX requests, Frames, HTML5 Media from the same origin.

The script-src 'self'; directive restricts where the browser can load JavaScript from to only the application's own domain.

The connect-src 'self'; directive restricts URLs which can be loaded using script interfaces.

The img-src 'self'; directive restricts from where the browser can load images.

The style-src 'self'; directive restricts from where the browser can load stylesheets.

By setting these policies, the application is protected against loading potentially malicious resources from unauthorized domains. This is a crucial step in securing the application against common web vulnerabilities.

Please note that the actual Content-Security-Policy header value should be defined based on your application's specific requirements. The above is just a basic example and might not fit all use cases. Regularly review and update the Content-Security-Policy header as needed to adapt to changes in the application's requirements and security best practices.

References