How To Check for JID Attacks With Java

A consistent inclusion in the OWASP top 10, insecure deserialization is a subtle but dangerous application security threat. This aptly named attack exploits data serialization, the “bread and butter” data transformation process that takes place when an object is passed from one web application to another. Under normal circumstances, when a new object is sent to application, the object is first converted (serialized) into either a structured or binary format before passing through a network as a sequential stream of bytes. On the application’s end, the serialized file is turned back into an object (deserialized) before being interpreted by the application. Most commonly, that data is serialized using CSV, XML, or JSON format. No matter which format is used, properly securing this deserialization process is a critical piece of the design “puzzle” for any individual developer or business to solve.

The purpose of this article is to highlight the dangers of insecure deserialization attacks and demonstrate a cloud-based security API solution that can be used to help mitigate this specifically for JSON deserialization. This demonstration includes step-by-step instructions to structure your API call with Java using code examples provided further down the page.

Dangers of Insecure Deserialization Attacks

When an attacker exploits an insecure deserialization vulnerability, they are successfully causing the targeted application to trust and deserialize a malicious object. Such vulnerabilities are usually targeted by attackers aiming to remotely execute code within a web application, arbitrarily read files within that application’s system, or cause a denial-of-service, rendering a network resource within the application unreadable for its intended users. A notable example of an insecure deserialization attack targeting a large credit reporting company in 2017, exploiting a vulnerable REST web service that was quietly capable of deserializing malicious objects containing remote commands. As a result of this attack, sensitive information belonging to millions of Americans was exposed, and company shares fell 13% as trust in the company’s security policies waned.

In the last half-decade or so, the JSON format has begun to exceed its contemporaries in popularity for deserialization, in part due to its inherent simplicity/interoperability as a lightweight, text-based format designed specifically for data transfer, and in part due to its intrinsic connection with the ever-growing popularity of JavaScript, which can be found in more than 90% of the world’s websites. With the increased popularity in the use of any data format/tool ‚Äč‚Äčthroughout the technology landscape, threats attempting to exploit that asset are likely to increase more or less proportionately over time, and as a result, additional focus needs to be applied towards bolstering that asset’s threat profile. Plainly, the growing popularity of the JSON format is, in and of itself, the best indication that your JSON deserialization tool’s security policies should be reviewed and improved regularly. Weakly configured JSON deserialization tools lacking adequate data validation features will continually be in danger of processing malicious, invalid files during the deserialization process. When it comes to any popular, oft-championed format like JSON, it’s easy to fall into a false sense of security.

Cloud-Based Security API Solution

Boosting your application’s threat profile against insecure deserialization doesn’t begin with adding new services to your deserialization process, however. Rather, it starts with carefully analyzing the data your application trusts to deserialize. If you’re pulling data from an external network/data source that your application isn’t in control of, your application shouldn’t automatically deserialize that data under any circumstances. To passively limit threats in this serialization tools can be certain scenario that only process primitive data types, limiting the pool of potential threats entering your application in the first place. When that isn’t possible, and when the dataset in question is relatively small, you may alternatively be able to manually review JSON objects in-memory and detect discrepancies that way. However easily readable JSON may be, though, that is certainly not an efficient option, and a well-conceived validation service attached to your web application will accomplish that same task much more quickly and effectively. Even with the inclusion of such a service, it should remain standard practice to take additional, fundamental steps such as logging failures/exceptions in the deserialization process, strictly regulating all network activity (as much as possible), and testing deserialization tools regularly to ensure they’re performing their duty as intended.

To help you mitigate this vulnerability with a data validation service, you may implement a free Cloudmersive Security API which detects insecure JSON objects and provides a Boolean validating the presence of an attack (or lack thereof). With the protection of this JSON Insecure Deserialization (JID) API, your JSON deserialization tool will be equipped to quickly detect JID attacks in-memory before the deserialization process occurs, rendering JSON-based threats inert and avoiding a potential breach of your system. The goal of the below demonstration is to show you how to implement this JID Detection API based on pre-formatted, ready-to-run code examples provided in Java. I’ve added some additional documentation around these code snippets describing how to properly satisfy the basic parameters you’ll need to make this API call.


The first step toward implementing this API is to install the Maven SDK. To do so, start by adding a jitpack reference to the repository in pom.xml:


After that’s done, add a reference to the dependency in pom.xml:


Now you can use the below example code to structure the API call, beginning by adding in the Import classes. Before calling the API, however, you’ll want to make sure you have the two required parameters ready. Those include:

  1. Your JSON object string
  2. Your Cloudmersive API key (obtain a key by registering a free account; your key will provide a limit of 800 API calls per month)
// Import classes:
//import com.cloudmersive.client.invoker.ApiClient;
//import com.cloudmersive.client.invoker.ApiException;
//import com.cloudmersive.client.invoker.Configuration;
//import com.cloudmersive.client.invoker.auth.*;
//import com.cloudmersive.client.ContentThreatDetectionApi;

ApiClient defaultClient = Configuration.getDefaultApiClient();

// Configure API key authorization: Apikey
ApiKeyAuth Apikey = (ApiKeyAuth) defaultClient.getAuthentication("Apikey");
Apikey.setApiKey("YOUR API KEY");
// Uncomment the following line to set a prefix for the API key, e.g. "Token" (defaults to null)

ContentThreatDetectionApi apiInstance = new ContentThreatDetectionApi();
String value = "value_example"; // String | User-facing text input.
try {
    StringInsecureDeserializationJsonDetection result = apiInstance.contentThreatDetectionDetectInsecureDeserializationJsonString(value);
} catch (ApiException e) {
    System.err.println("Exception when calling ContentThreatDetectionApi#contentThreatDetectionDetectInsecureDeserializationJsonString");

After successfully making your API call, you’ll receive a near-instantaneous response letting you know whether the operation was successful, and whether the object in question contained a JSON deserialization attack. Below, I’ve provided an API response model.

  "Successful": true,
  "ContainedJsonInsecureDeserializationAttack": true,
  "OriginalInput": "string"

Implementing this JID detection API is one easy way of securing a common, dangerous vulnerability. Ideally, it should free up more of your time and resources to focus on other important tasks, such as preventing other, equally concerning data security threats from impacting your system. Such threats come in many forms; Other common additions to your list of application vulnerabilities may include the likes of SQL injection, cross-site scripting, server-side request forgery, and more. As ever, efforts to research new security solutions and increase your web application’s security policies are highly recommended to ensure your data stays safe in the long term.


Leave a Comment