HTTP parameter pollution (HPP) vulnerabilities can be introduced if multiple HTTP parameters have the same name. This issue may cause an application to interpret values incorrectly. An attacker may take advantage of HPP vulnerabilities to bypass input validation, trigger application errors, or modify internal variable values.
NOTE HPP vulnerabilities can lead to server- and client-side attacks.
An attacker can find HPP vulnerabilities by finding forms or actions that allow user-supplied input. Then the attacker can append the same parameter to the GET or POST data – but with a different value assigned.
Consider the following URL:
<https://store.h4cker.org/?search=cars>
This URL has the query string search and the parameter value cars. The parameter might be hidden among several other parameters. An attacker could leave the current parameter in place and append a duplicate, as shown here:
<https://store.h4cker.org/?search=cars&results=20>
The attacker could then append the same parameter with a different value and submit the new request:
<https://store.h4cker.org/?search=cars&results=20&search=bikes>
After submitting the request, the attacker could analyze the response page to identify whether any of the values entered were parsed by the application. Sometimes it is necessary to send three HTTP requests for each HTTP parameter. If the response from the third parameter is different from the first one – and the response from the third parameter is also different from the second one – this may be an indicator of an impedance mismatch that could be abused to trigger HPP vulnerabilities.
TIP The OWASP Zed Attack Proxy (ZAP) tool can be very useful in finding HPP vulnerabilities. You can download it from *https://github.com/zaproxy/zaproxy*.
Insecure Direct Object Reference vulnerabilities can be exploited when web applications allow direct access to objects based on user input. Successful exploitation could allow attackers to bypass authorization and access resources that should be protected by the system (for example, database records, system files). This type of vulnerability occurs when an application does not sanitize user input and does not perform appropriate authorization checks.
An attacker can take advantage of Insecure Direct Object References vulnerabilities by modifying the value of a parameter used to directly point to an object. In order to exploit this type of vulnerability, an attacker needs to map out all locations in the application where user input is used to reference objects directly.
Let’s go over a few examples on how to take advantage of this type of vulnerability. The following example shows how the value of a parameter can be used directly to retrieve a database record:
<https://store.h4cker.org/buy?customerID=1188>
In this example, the value of the customerID parameter is used as an index in a table of a database holding customer contacts. The application takes the value and queries the database to obtain the specific customer record. An attacker may be able to change the value 1188 to another value and retrieve another customer record.