> For the complete documentation index, see [llms.txt](https://zeyad-abulaban.gitbook.io/notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zeyad-abulaban.gitbook.io/notes/web-penetration-testing/web-vulns/hpp.md).

# HTTP Parameter Pollution

## Definition

HTTP parameter pollution (HPP) is the process of manipulating how a website treats the parameters it receives during HTTP requests. The vulnerability occurs when an attacker injects extra parameters into a request and the target website trusts them, leading to unexpected behavior. HPP bugs can happen on the server side or on the client side (which is usually your browser).

* HPP vulnerabilities depend on how server-side code uses values passed as parameters, which are controlled by an attacker.
* Finding these vulnerabilities might require **more experimentation** than other types of bugs.

## Server-Side HPP

In server-side HPP, you send the servers unexpected information in an attempt to make the server-side code return unexpected results.\
By playing with the requests you can identify if there is any vulnerable parameters to HPP. **Server-side HPP** depends on you identifying potentially vulnerable parameters and experimenting with them.the servers don’t just return a web page but also run some code based on information they receive from the URL that is sent This code runs only on the servers, so it’s essentially invisible to you: you can see the information you send and the results you get back, but the code in between isn’t available. But sometimes HPP vulnerabilities occur as a result of hidden server-side behavior from code that isn’t directly visible:

```js
user.account = 12345
def prepare_transfer(params) //1
 params << user.account  //2
 transfer_money(params) //user.account (12345) becomes params[2] //3
end
def transfer_money(params)
 to = params[0] //4
 amount = params[1] //5
 from = params[2] //6
transfer(to,amount,from)
end
```

This code creates two functions, prepare\_transfer and transfer\_money . The prepare\_transfer function takes an array called params **#1**, which con- tains the to and amount parameters from the URL. The array would be `[67890,5000]` , where the array values are sandwiched between brackets and each value is separated by a comma. The first line of the function **#2** adds the user account information that was defined earlier in the code to the end of the array. We end up with the array `[67890,5000,12345]` in params , and then params is passed to transfer\_money **#3**. Notice that unlike parameters,arrays don’t have names associated with their values, so the code depends on the array always containing each value in order: the account to trans- fer to is first, the amount to transfer is next, and the account to transfer from follows the other two values. In transfer\_money , the order of the values becomes evident as the function assigns each array value to a variable. Because array locations are numbered starting from 0, params\[0] accesses the value at the first location in the array, which is 67890 in this case, and assigns it to the variable to **#4**. The other values are also assigned to vari- ables at lines **#5** and **#6**. Then the variable names are passed to the transfer function, not shown in this code snippet, which takes the values and trans- fers the money. Ideally, the URL parameters would always be formatted in the way the code expects. However, an attacker could change the outcome of this logic by passing in a from value to params , as with the following URL:

```url
https://www.bank.com/transfer?to=67890&amount=5000&from=ABCDEF
```

In this case, the from parameter is also included in the params array passed to the prepare\_transfer function; therefore, the array’s values would be `[67890,5000,**ABCDEF**]` , and adding the user account at **#2** would result in `[67890,5000,**ABCDEF**,**12345**]` . As a result, in the transfer\_money function called inprepare\_transfer , the from variable would take the third parameter, expecting the user.account value 12345 , but would actually reference the attacker-passed value ABCDEF **#4**.

## Client Side HPP

Client-side HPP vulnerabilities allow attackers to inject extra parameters into a URL to create effects on a user's end (client side is a common way of referring to actions that happen on your computer, often via the browser, and not on the site’s servers). The security impact of this issue depends largely on the nature of the application functionality. Even if it has no direct impact on its own, an attacker may use it in conjunction with other vulnerabilities to escalate their overall severity.

#### Mitigation

Ensure that user input is URL-encoded before it is embedded in a URL.

## Summary

Through trial and error, you might discover situations in which HPP vulnerabilities occur. Usually, social media links are a good first place to test for this vulnerability type, but remember to keep digging and think of HPP when you’re testing for parameter substitutions, such as ID-like values.

## HackerOne Reports

* [**https://hackerone.com/reports/105953/**](https://hackerone.com/reports/105953/)
* [**https://blog.mert.ninja/twitter-hpp-vulnerability/**](https://blog.mert.ninja/twitter-hpp-vulnerability/)
* [**https://ericrafaloff.com/parameter-tampering-attack-on-twitter-web-intents/**](https://ericrafaloff.com/parameter-tampering-attack-on-twitter-web-intents/)

## References

* [**https://owasp.org/www-pdf-archive/AppsecEU09\_CarettoniDiPaola\_v0.8.pdf**](https://owasp.org/www-pdf-archive/AppsecEU09_CarettoniDiPaola_v0.8.pdf)\*\* (Recommended)\*\*


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://zeyad-abulaban.gitbook.io/notes/web-penetration-testing/web-vulns/hpp.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
