How to Automatically Detect Multiple Cybersecurity Threats from an Input Text String in Java

If there’s one thing nearly all contemporary, interactive client-side web applications have in common, it’s a reliance on dynamic user-facing text input fields. These fields play the all-important role of capturing plain text data from client-side browsers and sharing that information with a server-side application, allowing that application to perform specific actions with that data based on stringent request parameters. We encounter these fields when we log into or register a new account within an application, query content from a web application’s database, fill out a contact form, write comments on an article post, and more.

When we interact with these fields as client-side users, we might notice that some fields only accept data in a certain format. For example, if we enter integers into a “First Name” or “Last Name” field, we’ll likely receive an error response from the application quickly notifying us that integers aren’t valid in that field. Similarly, if we enter our name into a field that asks for our date of birth, we’ll likely receive an error response that asks for valid integers instead.

On the one hand, these validation measures are important to ensure web applications retrieve accurate information from client-side users and avoid issues related to invalid data.  On the other hand, they’re the first of many steps involved in securing the web application against web-based cyberattacks.

Cyberattacks From User-Facing Text Input

When user-facing text input fields don’t exhaustively validate and/or sanitize client-side input, they can be quickly and easily exploited by client-side threat actors to launch a variety of significant cybersecurity attacks. While most of these attacks attempt to steal resources from the underlying server-side application/database, others try to passively exploit unsuspecting client-side users accessing the same web application’s content on a different browser.   

One common example of an attack that steals information from a web application’s server-side resources is SQL Injection (SQLI). Many web applications store data in SQL databases, so the text we enter into those applications’ search fields is formulated into an SQL query to modify (select, update, delete, insert, etc.) that data.  If the search field inputs aren’t adequately validated, a cybercriminal can enter their own SQL query directly into one of those fields and ask the database for resources far outside the scope of that input field’s usual request parameters. Depending on the sophistication of the attacker in question, this breach can allow them to steal other users’ login information, manipulate or delete valuable data, acquire administrative permissions, or even inject malware in extreme cases.  

The latter scenario – in which an attacker leverages a web vulnerability to exploit other client-side users – is best exemplified by Cross-Site Scripting (XSS) attacks. When user-input text fields are designed to store and subsequently reflect client-supplied data back on a web page for other users to see (e.g., the comment section on an article), threat actors can attempt to exploit these input fields by entering malicious scripts within them. If the web application blindly trusts user input provided in these fields, an attacker’s malicious script can be stored in the application database, reflected onto the original input page, and subsequently executed within another user’s browser. This process allows the attacker to steal data from an unsuspecting victim or even impersonate them and carry out malicious actions on their behalf.

The above examples are just two of several common, well-documented web security threats which are frequently used to breach vulnerable web applications all over the world. Along with critical client-side input validation and sanitization measures, the implementation of dedicated threat detection policies is important for bolstering any web application’s threat profile against these user-facing text input threats. The existence of multiple unique content-based threats means multiple unique policies should be put in place – but that doesn’t mean they have to stand apart from one another and clutter unnecessary clutter, either. By funneling client-supplied content through a single, dynamic threat detection API, we can build sensible and efficient security redundancy into our workflow in one simple step.

Demonstration

In the remainder of this article, I’ll demonstrate a free Web Security API which can be used to automatically detect a variety of unique, commonly encountered cybersecurity threats from user-facing text input. Threat coverage includes:

• SQL Injection (SQL)
• Cross-Site Scripting (XSS)
• XML External Entities (XSS)
• Server-Side Request Forgery (SSRF)
• JSON Insecure Deserialization (JID)

This API input accepts a string containing user-facing text input from a web application field.  When any of the above threats are detected, the API will return a “CleanResult: False” value in the response body, along with a Boolean reading “True” for the specific threat encountered in that request.  The specific data type used in that request (i.e., XML, JSON, or URL format) will be identified as well.  A full example response body can be viewed below in JSON format:

{
  "Successful": true,
  "CleanResult": true,
  "ContainedJsonInsecureDeserializationAttack": true,
  "ContainedXssThreat": true,
  "ContainedXxeThreat": true,
  "ContainedSqlInjectionThreat": true,
  "ContainedSsrfThreat": true,
  "IsXML": true,
  "IsJSON": true,
  "IsURL": true,
  "OriginalInput": "string"
}

We can easily take advantage of this API using ready-to-run Java code examples provided further down the page. Before we get to that, however, we’ll first need to install the client SDK. We can do so by first adding a reference to the repository in our Maven POM file (JitPack is used to dynamically compile the library):

<repositories>
    <repository>
        <id>jitpack.io</id>
        <url>https://jitpack.io</url>
    </repository>
</repositories>

And we can then add a reference to the dependency:

<dependencies>
<dependency>
    <groupId>com.github.Cloudmersive</groupId>
    <artifactId>Cloudmersive.APIClient.Java</artifactId>
    <version>v4.25</version>
</dependency>
</dependencies>

We can then structure our API call by adding the imports and Java examples into our file:

// 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)
//Apikey.setApiKeyPrefix("Token");

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

Now we can authorize free requests by entering a free-tier API key into the Apikey.setApiKey snippet.

This solution will add a new layer of security to our web application, but it should by no means serve as a single point of failure. It’s extremely important to carefully review best practices associated with preventing each of the threats mentioned above and enhance web application security measures accordingly.