HTTP Parameter Pollution

问题:

In a web site we are developing, after doing a security check, we've identified security issues. This report contains HTTP Parameter Pollution vulnerabilities too. In web i could find what is HPP? How it can inject & etc; Yet I couldn't find how to avoid this kind of issues. The server language is php. & i know same parameter can be duplicated & php just consider the last parameter when there are many of same. But it doesn't make any sense to do something to avoid this risk. So can any one guide me with how to avoid HPP vulnerabilities with examples ?

Thanks in Advance

回答1:

Note that I am describing "server-side HPP" here, however, there is a client-side version of the vulnerability. Understanding the server-side version will also help with the client-side version.

HPP is when your application makes a back-end HTTP request to another system.

e.g. if your website uses the following front-end URL to make a money transfer:

https://www.example.com/transferMoney.php

This is only accessible via the POST method and takes the following parameters:

amount=1000&fromAccount=12345

When your application processes this page it makes the following POST request to a back end system to actually process the transaction with a fixed toAccount:

https://backend.example/doTransfer.php

toAccount=9876&amount=1000&fromAccount=12345

Now you say that PHP only takes the last parameter in case of duplicates.

Suppose someone alters the POST to your website to the following:

amount=1000&fromAccount=12345&toAccount=99999

If your transferMoney.php page is vulnerable to HPP then it now might make the following request to the back end system

https://backend.example/doTransfer.php

toAccount=9876&amount=1000&fromAccount=12345&toAccount=99999

The second toAccount injected by the user will override this backend request and transfer the money into their own account (99999) instead of the intended account set by the system (9876). This can be useful for the attacker to amend their own requests to your system. but it can be also useful to the attacker if the attacker can generate this link from their own website and entice other users to unwittingly follow the link unaware of the extra parameter.

To fix this you should make sure that any back-end HTTP requests have correct URL encoding applied as well as validating all input. e.g. that fromAccount is an actual valid account number. Also in my example even if this was not validated, the back-end request should have been encoded as fromAccount=12345%26toAccount%3D99999 which would have stopped the second toAccount from being interpreted as a separate POST parameter.

Client-Side

Client-Side HPP is when an attacker can manipulate links displayed on the page so when they are followed client-side, they do something different that the application developer intended. For example, "polluting" a transfer funds button with an extra parameter that changes the "to account" that is actioned directly from the app rather than a back-end service.