HTTP Parameter Pollution
ID |
java.http_parameter_pollution |
Severity |
high |
Resource |
Injection |
Language |
Java |
Tags |
CWE:235, NIST.SP.800-53, OWASP:2021:A3, PCI-DSS:6.5.1 |
Description
Improper neutralization of special elements into path, query string, or parameters of HTTP requests
Rationale
HTTP Parameter Pollution occurs when a web application inadequately handles parameters that are included in an HTTP request. By injecting additional parameters into a query string or request body, an attacker can manipulate the request path and parameters to override intended behavior or bypass certain validations, potentially accessing unauthorized data or altering application logic.
In contrast to Server-Side Request Forgery (SSRF), where an attacker controls the full request URL including the host and port, HPP focuses on manipulating parts like the path, query, or fragment of the URL. Common attack vectors exploit characters such as "&" to inject additional parameters, "../" to alter the path, ";" to add matrix parameters, and "#" to truncate URL components.
Consider a Spring-based Java web application interacting with a remote service, using a URL constructed with user input:
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.client.RestTemplate;
@RestController
public class BankingController {
private RestTemplate restTemplate = new RestTemplate();
@GetMapping("/balance")
public String showBalance(@RequestParam String account, @RequestParam String monetaryUnit) {
// Constructing URL by concatenating input
String url = "https://mybank.com/show-balance/account/" + account + "/" + monetaryUnit + "?date=now";
return restTemplate.getForObject(url, String.class);
}
}
In this example, user input (monetaryUnit
) is concatenated directly into the URL without validation. With an HPP attack, an attacker could manipulate the monetaryUnit
parameter by setting a malicious value, potentially altering the intended REST API interaction with unintended HTTP methods or paths.
Remediation
To remediate HTTP Parameter Pollution vulnerabilities, implement the following practices:
-
Input Validation and Encoding: Validate user input rigorously. Use encoding to ensure any special characters in input are safely included in URLs, preventing them from manipulating the request structure.
-
Parameter Handling: Instead of constructing URLs via string concatenation, utilize URI building classes (e.g., Spring’s
UriComponentsBuilder
) to safely handle and encode all parts of the URL, ensuring parameter integrity. -
Secure Framework Configuration: Consider using framework settings that limit or restrict parameter resolution from multiple sources, and ensure only expected parameters are processed.
Below is an improved version using Spring’s UriComponentsBuilder
:
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.util.UriComponentsBuilder;
@RestController
public class SecureBankingController {
@GetMapping("/balance")
public String showBalance(@RequestParam String account, @RequestParam String monetaryUnit) {
// Construct URL using UriComponentsBuilder
String url = UriComponentsBuilder.fromHttpUrl("https://mybank.com/show-balance/account/{account}/{monetaryUnit}")
.queryParam("date", "now")
.buildAndExpand(account, monetaryUnit)
.toUriString();
// Utilize RestTemplate in secure context
RestTemplate restTemplate = new RestTemplate();
return restTemplate.getForObject(url, String.class);
}
}
In this secure example, UriComponentsBuilder
helps construct URLs appropriately by encoding parameters and preventing malicious manipulation, thereby protecting the application from potential HPP exploits.
By employing these strategies, Java applications can effectively defend against HTTP Parameter Pollution, ensuring secure processing of HTTP requests and safeguarding against unauthorized data access or unintended request modifications.
Configuration
The detector has the following configurable parameters:
-
sources
, that indicates the source kinds to check. -
neutralizations
, that indicates the neutralization kinds to check.
Unless you need to change the default behavior, you typically do not need to configure this detector.
References
-
CWE-235 : Improper Handling of Extra Parameters.
-
OWASP - Top 10 2021 Category A04 : Insecure Design