Need

Enforce proper dependency pinning and version control

Context

• Usage of Java for building scalable and robust applications
• Usage of javax.servlet for building Java web applications with servlets
• Usage of javax.servlet.http for handling HTTP requests and responses in Java web applications

Description

Non compliant code

        import javax.servlet.*;
import javax.servlet.http.*;

public class MyServlet extends HttpServlet {

    public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, java.io.IOException {
        // Some code here...
    }
}
        
        

The Java Servlet above is a simple HTTP Servlet that responds to GET requests. The Servlet uses the javax.servlet library, which is declared as a dependency in the pom.xml file.

The vulnerability lies in the pom.xml file, where the javax.servlet dependency is declared without a specific version. This is a problem because the application does not make explicit the whole dependency tree it requires (direct and indirect third-party libraries) and their respective version. This can lead to potential issues when the application is built in different environments, as it might pull in different versions of the javax.servlet library, leading to inconsistent behavior or potential security vulnerabilities if a version with a known vulnerability is pulled in.

In this case, the version of javax.servlet is not pinned, meaning that Maven (the build tool used by this project) is free to choose any version of javax.servlet that it finds suitable. This could potentially lead to the application being built with different versions of javax.servlet in different environments, leading to inconsistent behavior and potential security vulnerabilities.

By not specifying the version of the javax.servlet library, the application is at risk of "dependency confusion" attacks, where an attacker could potentially trick the build system into pulling a malicious version of a library. This could lead to arbitrary code execution, data leakage, or other security issues.

To mitigate this vulnerability, the version of each dependency should be explicitly declared in the pom.xml file, ensuring that the same version is used in every environment.

Steps

• Identify all the direct and indirect third-party libraries used by the application.
• Determine the specific versions of each library that the application depends on.
• Explicitly specify the dependencies and their versions in the project configuration file (e.g., pom.xml for Maven projects or build.gradle for Gradle projects).
• Regularly update the dependencies to the latest secure versions to ensure that any known vulnerabilities are patched.
• Monitor for any security advisories or updates related to the dependencies used by the application.
• Perform regular security audits and vulnerability scans to identify any potential vulnerabilities introduced by the dependencies.

Compliant code

        import javax.servlet.*;
import javax.servlet.http.*;

public class MyServlet extends HttpServlet {

    public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, java.io.IOException {
        // Some code here...
    }
}
        
        

The above code is a simple Java servlet that handles HTTP GET requests. However, it does not explicitly specify the versions of its dependencies, which can lead to potential security vulnerabilities.

To fix this, we need to specify the versions of all direct and indirect dependencies in the project's configuration file. For a Maven project, this would be the pom.xml file, and for a Gradle project, this would be the build.gradle file.

For example, if the project uses Maven and depends on the javax.servlet-api library, the pom.xml file should include:

                <dependencies>
    <dependency>
        <groupId>javax.servlet</groupId>
        <artifactId>javax.servlet-api</artifactId>
        <version>3.1.0</version>
        <scope>provided</scope>
    </dependency>
</dependencies>

            

References

• 120. Improper dependency pinning