Why is this an issue?
Reflection injections occur in a web application when it retrieves data from a user or a third-party service and fully or partially uses it to
inspect, load or invoke a component by name.
If an application uses a reflection method in a way that is vulnerable to injections, it is exposed to attacks that aim to achieve remote code
execution on the server’s website.
A user with malicious intent exploits this by carefully crafting a string involving symbols such as class methods, that will help them change the
initial reflection logic to an impactful malicious one.
After creating the malicious request and triggering it, the attacker can attack the servers affected by this vulnerability without relying on any
pre-requisites.
What is the potential impact?
If user-supplied values are used to choose which code is executed, an attacker may be able to supply carefully-chosen values that cause unexpected
code to run. The attacker can use this ability to run arbitrary code on the server.
Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.
Application-specific attacks
In this scenario, the attackers succeed in injecting a seemingly-legitimate object, but whose properties might be used maliciously.
Depending on the application, attackers might be able to modify important data structures or content to escalate privileges or perform unwanted
actions. For example, with an e-commerce application, this could be changing the number of products or prices.
Full application compromise
In the worst-case scenario, the attackers succeed in injecting an object triggering code execution.
Depending on the attacker, code execution can be used with different intentions:
- Download the internal server’s data, most likely to sell it.
- Modify data, install malware, for instance, malware that mines cryptocurrencies.
- Stop services or exhaust resources, for instance, with fork bombs.
This threat is particularly insidious if the attacked organization does not maintain a Disaster Recovery Plan (DRP).
Root privilege escalation and pivot
In this scenario, the attacker can do everything described in the previous section. The difference is that the attacker additionally manages to
elevate their privileges as an administrator and attack other servers.
Here, the impact depends on how much the target company focuses on its Defense In Depth. For example, the entire infrastructure can be compromised
through a combination of unsafe deserialization and misconfiguration:
- Docker or Kubernetes clusters
- cloud services
- network firewalls and routing
- OS access control
How to fix it in Java SE
Code examples
In the following example, the code simulates a feature in an image editing application that allows users to install plugins to add new filters or
effects. It assumes the user will give a known name, such as "SepiaEffect".
Noncompliant code example
import java.lang.Class;
import java.lang.reflect.Constructor;
import java.lang.reflect.Method;
@RestController
public class EffectController
{
@GetMapping(value = "/filter/apply")
@ResponseBody
public ResponseEntity<String> apply(@RequestParam("effect") String effectName)
{
try
{
Class effectClass = Class.forName(effectName); // Noncompliant
Constructor<?> effectConstructor = effectClass.getConstructor();
Object EffectObject = effectConstructor.newInstance();
Method applyMethod = effectClass.getMethod("applyFilter");
boolean result = (boolean) applyMethod.invoke(EffectObject);
} catch (Exception e) {}
if (result)
{
return new ResponseEntity<>("Filter Applied", HttpStatus.OK);
}
else
{
return new ResponseEntity<>("Filter Failure", HttpStatus.FORBIDDEN);
}
}
}
Compliant solution
import java.lang.Class;
import java.lang.reflect.Constructor;
import java.lang.reflect.Method;
@RestController
public class EffectController
{
private static Set<String> EFFECT_ALLOW_LIST = new HashSet<>();
static
{
allowList.add("SepiaEffect");
allowList.add("BlackAndWhiteEffect");
allowList.add("WaterColorEffect");
allowList.add("OilPaintingEffect");
}
@GetMapping(value = "/filter/apply")
@ResponseBody
public ResponseEntity<String> apply(@RequestParam("effect") String effectName)
{
if (!EFFECT_ALLOW_LIST.contains(effectName)) {
return new ResponseEntity<>("Filter Failure", HttpStatus.FORBIDDEN);
}
try
{
Class effectClass = Class.forName(effectName);
Constructor<?> effectConstructor = effectClass.getConstructor();
Object EffectObject = effectConstructor.newInstance();
Method applyMethod = effectClass.getMethod("applyFilter");
boolean result = (boolean) applyMethod.invoke(EffectObject);
} catch (Exception e) {}
if (result) {
return new ResponseEntity<>("Filter Applied", HttpStatus.OK);
}
else {
return new ResponseEntity<>("Filter Failure", HttpStatus.FORBIDDEN);
}
}
}
How does this work?
Pre-Approved commands
The cleanest way to avoid this defect is to validate the input before using it in a reflection method.
Create a list of authorized and secure classes that you want the application to be able to execute.
If a user input does not match an entry in
this list, it should be rejected because it is considered unsafe.
Important note: The application must do validation on the server side. Not on client-side front-ends.
Resources
Articles & blog posts
Standards
