Year Of Security for Java – Week 22 – HTTP Parameter Pollution

No Gravatar

What is it and why should I care?
HTTP Parameter Pollution (HPP) is a technique that allows you to “override or add HTTP GET/POST parameters by injecting query string delimiters”. This term was created and popularized by a 2009 paper that showed you could tinker with request parameters, specifically by sending the same parameter multiple times, and cause some applications to behave unexpectedly. What happens if someone alters a request that looks like

/mypage.jsp?query=abc&acct=4

to look like

/mypage.jsp?query=abc&acct=5&acct=4

What value do you get when you call request.getParameter(“acct”)? What happens here depends on your server. Fortunately, there’s a handy slide on page 9 of this deck that shows a number of web and application servers and how they deal with this HPP issue. In general for Java, you get the first instance of a parameter – meaning you would get the value “5”.

What can go wrong here? Well, there are several ideas pointed out in the paper that are excellent, including overriding parameters, modifying behavior, accessing variables, and bypassing input validation.

One thought I had that’s similar to the HTTP path parameter issue I wrote about previously is that you could be doing some type of custom url-parsing for authorization checks and then could be getting a different value in the actual request. In the example I gave above, that would mean you might get the last value for “acct” in your url parsing authorization code and get the value “4”, determine the user is authorized to view that account, and then your actual database retrieval code uses request.getParameter(“acct”) to get the value of the account to retrieve from the DB, which is “5”, and which the user does NOT have access to. Now you have an insufficient authorization problem.

What should I do about it?

There are a handful things you can do to address HPP.

1. Awareness
You must know your environment. Know the application server you are running on and how it handles HPP.

2. Consistency
Be consistent in the way you access and evaluate parameters. If you need to access a parameter multiple times, make sure you access it in the same way both times. Don’t parse the url manually in one case, and then use request.getParameter() the next time.

3. Validate Input
Various techniques are available for performing this attack, and encoding is very common in most of them. Validate all your input to ensure it’s in the expected format. This requires canonicalization and validation. The ESAPI framework has a good validator that performs these tasks well.

4. Detect known attacks
You can use AppSensor or AppSensor-like detection to find out when an attacker is trying this type of an attack. You could do something simple like call request.getParameterValues(“acct”) and if you get a number of parameters that is not 1, then you know that either a) you have a bug, or b) someone’s tinkering with the site. You can then keep track of these events and detect when an intrusion has occurred. This should help keep you in front of the attackers. (Note: this specific example won’t work for some types of input like multi-select boxes, which you generally expect to return 0 -> many results.)

HPP is an interesting technique, and unfortunately not well known or understood. It’s not difficult to prevent, but does take some forethought. Hopefully this starting list helps. Comment if you have other ideas.

References
———–
http://blog.mindedsecurity.com/2009/05/http-parameter-pollution-new-web-attack.html
http://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf
http://www.jtmelton.com/2011/02/02/beware-the-http-path-parameter/
https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
https://www.owasp.org/index.php/OWASP_AppSensor_Project

Be Sociable, Share!

Technorati Tags: , , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *