The 10 Major Java Vulnerability Types that Threaten Your Software

Programmers have relied on Java for nearly 30 years, and over the years, hackers have found numerous ways to exploit applications built on this language. Cybersecurity professionals are in an endless cycle of eliminating vulnerabilities and discovering new ones, so if you’re developing with Java, you need to know the inherent vulnerabilities you’re working with, and what you can do about them.

There are several ways that malevolent actors can use your Java application against you. Most of these Java security risks involve three ingredients:

1. User input fields (e.g., username, password, search bars, etc.);
2. The commands that those inputs trigger on the back end of your application;
3. Hacker-created inputs that bend those commands to malicious purposes.

In this article, we’ll examine some of the most prevalent types of attacks Java applications can fall prey to—and how software composition analysis can protect you from them:

How Java security vulnerabilities work: a coffee shop analogy

One of my colleagues worked as a Starbucks barista as a teenager, and he told me once about how baristas would play pranks on each other by “hacking” the drink ordering system.

Back in the late 2000s, if you ordered a drink at Starbucks, your cashier would ring up your order and then call your order to the barista making the drinks. If you listened carefully, you would notice that the way the cashier would call the drink wasn’t always word-for-word what you said.

For example, if you ordered a “small iced latte with an extra shot and skim milk,” your cashier would call for an “iced, double, Tall, nonfat latte.” Baristas had a system for efficiently translating your order (the user input) into commands for the barista (the calling code).

If you understood this code, you could game the system to order drinks at a discount—or free altogether. One infamous example was the “no-water cup of water” trick. The menu item “cup of water” was free. Several drink parameters were also free, including:

• “No-water” for people who wanted extra-milky chai lattes
• “No-ice” for people who didn’t want ice in their cold drinks
• “Add milk” for people who wanted a splash of milk in their coffee or tea
• “No-room” for people who wanted their drink filled to the very top (usually because they didn’t want to add cream to their coffee)

A cup of milk would normally cost $1.00, but if it were rung up as an “iced, Tall, add milk, no-ice, no-room, no-water cup of water,” it would be free!

This was all in good fun, and the human barista would quickly realize what was going on, laugh it off, and charge the other barista the correct price.

But imagine there were no humans taking orders and making drinks—only robots. They might not catch on, and the store could be easily exploited until someone found a way to get the robots to reject spurious orders. And if customers got really clever, they might be able to order their drinks in such a way that convinced robots that “milk” really meant $100 bills—effectively getting cups of money for free!

If someone knows how the system works, they can manipulate it. Baristas would hack their system in harmless fun, but when hackers attack your applications, they’re after more than just a laugh. Java security vulnerabilities can be exploited to steal your customers’ information, alter user experience, corrupt your database, or even delete your whole application.

Java developers should familiarize themselves with security vulnerabilities to protect against them when setting up user input fields on websites and apps. In this article, we’ll explore the common ways hackers exploit Java applications.

The 10 most common types of Java security vulnerabilities

Below is an overview of the ways hackers exploit vulnerabilities in Java applications. These are board-level categories, and this article is not an exhaustive list. However, understanding how vulnerabilities work is the first step to securing your application.

We’ll explain how each vulnerability works and provide links to further reading. At the end, we’ll share how SCA helps address them all.

If you don’t already, make sure to set security processes in place to keep these kinds of attacks from being executed. And if you’re curious whether or not these vulnerabilities are lurking within your code, a robust software composition analysis (SCA) tool will let you know if these kinds of vulnerabilities (and others) pose a threat to your current version.

1. SQL Injections

One of the most prevalent types of attacks in the Java world, SQL injections, give hackers access to your queryable information—and potentially let them steal, destroy, or corrupt your database. This commonly takes place when malevolent actors use user input fields to upload SQL code to your application.

To use SQL injections, Hackers must make assumptions about how your user input fields translate to SQL commands within your app. If they correctly guess the way you’ve coded your application, they can enter SQL code that your application runs unbeknownst to you. Hackers may run queries, execute commands, or even store scripts in your database that execute when queried later (i.e., a second order SQL injection).

You can protect against these kinds of attacks by adding SQL parameters to your queries before they are executed. These function as guardrails, which prevent malicious SQL commands from being executed.

For further reading on SQL injections:

• SQL Injection | OWASP Foundation (OWASP)
• SQL Injection (W3 Schools)
• Connection string builders (Microsoft)
  
  

2. XPath injections

An XPath injection attack occurs when a hacker uses user inputs to construct an XPath query to access XML data. This type of attack is very dangerous, and it’s becoming more prevalent as more organizations adopt microservices architecture.

Because microservices involve many small applications accessing XML resources, organizations using this infrastructure are especially vulnerable to this sort of attack. When exploited, hackers can see how you’ve structured your XML data, access confidential information, and even hijack your authentication protocols to gain privileges.

For further reading on XPath injections:

• XPATH Injection (OWASP)
• XPath Injection Attack - What is it? How to prevent it? (Mukhadin Beschokov, Wallarm)
  
  

3. Cross-site scripting (XSS)

A cross-site scripting vulnerability arises when hackers can use your website to attack your users, i.e., malevolent actors attack users across your site. This attack’s two most common varieties are reflected XSS and stored XSS.

Reflected XSS

Web applications and websites often allow users to input information—e.g., search queries, comments, etc. When a user completes the input, the site may return a results page with a URL including the user input (or some function thereof).

But if the user input contains a malicious script, then the input can hijack the “trusted” website. This means that hackers can exploit this vulnerability by creating URLs with the malicious script already queued up. They can then trick users into clicking on a link to the malicious URL.

The user’s browser won’t stop the script from executing because it’s happening on a “trusted” website. This can give the hacker control of what the user sees on the target site, allowing them to direct the user to take harmful actions.

Stored XSS (or persistent XSS)

Stored XSS is even more dangerous. This takes place when a malicious user injects a script on a target site in such a way that the site stores it and serves it up to users. In this scenario, the target site attacks users automatically, triggering the malicious script when users visit a page the script is injected in.

Sites that allow users to input information that is served to other users (like social media platforms, forums, and blogging platforms) are especially vulnerable to this sort of attack.

For further reading on Cross-site scripting (XSS):

• Cross Site Scripting (XSS) (OWASP)
• Reflected XSS Vulnerability in Depth (Geeks for Geeks)
  
  

4. Buffer overflows (aka buffer overruns)

Applications will often use buffers to hold data (including user inputs) while it is being moved from one place to another. If a malicious user correctly estimates how much memory space is allotted to a given buffer, they may input more data than the buffer is meant to hold—causing your application to overwrite other code within your application. If a hacker uploads more data than your buffer can hold, it may force your application to write the rest of their input over other code you’ve written.

This can leave you vulnerable to foreign code being written over your own code, which can lead to crashes, errors, or actions that the software was never meant to perform.

For further reading on buffer overflows:

• Buffer Overflow Attack (OWASP)
  
  

5. Remote code execution (RCE)

A critically dangerous type of attack, remote code execution lets an attacker execute commands on the target’s device even if the attacker is not in the same location. The hacker can use someone else’s computer from anywhere, often through malware installed on the target computer. Once a malicious actor has gained access to another computer, they can deploy several of the other kinds of attacks listed in this article.

The log4j exploit is a recent (and disastrous) example of such an attack.

For further reading on remote code execution (RCE):

• Remote Code Execution (RCE) (BugCrowd)
• What is RCE vulnerability? Remote code execution meaning (Mukhadin Beschokov, Wallarm)
  
  

6. Serialization and deserialization exploits

Serialization is the process of transforming objects into a serial form (such as a JSON payload), making them more portable. Deserialization is the process of turning these serial elements back into the objects they represent.

If a valid serialized object falls into the wrong hands, hackers can alter it to include malevolent code.This might involve modifying the object’s attributes and data types, or inserting commands to execute processes your application was never intended to do. If your application or API deserializes the compromised object, these changes can affect your software—corrupting your data, altering its structure, and potentially giving the hacker the ability to execute an RCE.

For further reading on serialization and deserialization attacks:

• Insecure Deserialization (OWASP)
• Serialization Attacks: What They Are and How to Prevent Them (Reblaze)
  
  

7. Command injections

Command injections go straight for your operating system. If a hacker deduces that one of your features involves user inputs in system commands, they can give foreign commands to your operating system by including them in their inputs.

If your application doesn’t have privileges to execute system commands, these sorts of attacks won’t work. (The user can’t command the application to do something it isn’t authorized to do.) But if it does, it’s imperative to sanitize all user-provided data before use—otherwise a command injection could access privileged information, delete files, or even shut down your entire application.

For further reading on command injections:

• OS Command Injection Defense Cheat Sheet (OWASP)
• Command Injection in Java: Examples and Prevention (StackHawk)
  
  
  

8. LDAP injections

The Lightweight Directory Access Protocol (LDAP) is a popular software protocol for authenticating users and allowing them to access other entities within a network. If you don’t have parameters around your LDAP query interfaces, hackers may insert LDAP queries in user input forms, which allow them to look up otherwise private information within your database. LDAP injections may also give attackers the ability to change users’ permissions, status, and privileges.

For further reading on LDAP injections:

• LDAP Injection Prevention Cheat Sheet (OWASP)
• Preventing LDAP Injection in Java (OWASP wiki)
  
  

9. Resource injections

If your application names resources based on user input, hackers may find opportunities to change resource identifiers (e.g., port numbers, file names, etc.). This type of attack may give the hacker access to resources they shouldn’t have, hide resources from the application, or even turn file names into malicious scripts themselves.

For further reading on resource injections:

• Resource Injection (OWASP)
  
  

10. Connection string injections

Connection strings define the way your application connects to data sources. Connection string injection attacks take place when hackers add extra parameters to connection strings, which can allow them to bypass proper authentication, hijack credentials, or even gain control over the database server.

For further reading on connection string injections:

• Connection String Parameter Attacks (Chema Alonso, Informatica 64)
• How a Connection String Injection Attack is Performed (Geeks for Geeks)
  
  

MergeBase protects your Java application from these attacks and more

Your developers should be building applications that protect against these types of attacks—but what about vulnerabilities in the components you’ve sourced from third parties? Software companies deal with this problem using software composition analysis (SCA) tools. These tools scan your components for known vulnerabilities, so that you know which parts of your software are open to attack.

MergeBase is an advanced SCA tool, providing more than just vulnerability reports. With MergeBase, your developers can see where vulnerabilities lie within your application, how much of a risk they pose, and what available patches are compatible with your current application.

One problem that often arises with SCA tools is false positives. While you don’t want to let vulnerabilities persist in your application unchecked, you also don’t want your developers wasting time hunting down issues that don’t exist. MergeBase protects you from this hypervigilance as well: of all the leading SCA providers, we have the lowest false positives rate. (It’s one of the main reasons software companies switch to us from other providers.)

But what happens when your software has a known vulnerability, and you don’t have the resources necessary to fix it right away?

MergeBase’s Dynamic Application Surveillance and Hardening provides an additional layer of security for these cases. With Runtime Protection, you can simply disable the actions that allow a hacker to exploit a known vulnerability in your system. So if one of your user input forms is vulnerable to a high-risk threat, Runtime Protection allows you to block the steps that the hacker would need to take in order to actually attack your application.

Hackers are always looking for a way in—but MergeBase gives you peace of mind. If you want to see how MergeBase can help you keep your Java application secure, start a free trial today!