Is your cloud application secure? Part1: HTTP Parameter Pollution

[SvetoManolov]

This blog is the first of a series dedicated to web application security – common vulnerabilities, threats, attacks, and protections. The emphasis will be also on on-demand applications – what cloud environments provide, what we need to know, what we need to do specifically for cloud deployments, etc.

HTTP Parameter Pollution, or HPP, is a web-application attack, used to manipulate or retrieve data without authorization. HPP may even allow pretty dangerous things like SQL Injection or Cross Site Scripting.

The attack is based on a weakness in the HTTP RFCs – they do not standardize the HTTP parameter manipulation, allowing each web server to deal with it differently.

What does that mean? To understand it let’s dissect the HTTP request syntax.

For the purpose of illustrating the problem I use a simple web app that just echoes the sent parameters. A standard GET request with parameters will look like that:

GET /echo?par1=val1&par2=val2

The standardized HTTP syntax defines sending parameters via query string, which is a list of name-value pairs.

Now, do you know what will happen with an application if the HTTP request contains multiple occurrences of the same parameter?

GET /echo?par=val1&par=val2&par=val3

The answer is that the behavior strongly depends on the web application environment. Usually applications manipulate the request parameters via an API provided by the environment, and those APIs behave differently.

Here are some types of behavior in some common web application environments when a request contains multiple occurrences of the same parameter:

• Return only the first occurrence of the parameter
• Return only the last occurrence
• Return an array with all occurrences
• Return a single value, concatenating the values of all occurrences

(for details see [1])

You see, this varies a lot and can significantly change the business logic of the application by executing different functionality or accessing different data.

Unfortunately this is not the end of the story. To make it even more complicated one needs to consider the combination of GET parameters, POST parameters, and COOKIE values having the same name. Some application environments mix those, while others keep them separate.

To make the life of HANA Cloud Platform application developers at least a bit easier here is the information of how the HCP application environments (Java and HANA XS) behave.

Java

The Java runtime provides request parameter manipulation via the Servlet API, which offers two methods:

• getParameterValues(java.lang.String) - Returns an array of String objects containing all values of the parameter
• getParameter(java.lang.String) - Returns the value of the first occurrence of the parameter

Although using the first occurance is usually safer than using the last one, in order to be absolutely safe use the getParameterValues method. If the correct behavior of the application expects a single value for a parameter then reject the requests with multiple values.

HANA XS

In HANA XS request parameters are obtained via the parameters member of the $.net.http.Request class, which is a list of name-value pairs ($.web.TupeList). Its get(String) method returns either a String object (in case the parameter has a single value) or an array of Strings containing all values of the parameter.

Now, be careful! Due to the weak typing of Java Script the array of Strings can be used right away as a single String. Its value is a concatenation of all values from the array.

Let’s illustrate that with an example. Suppose

1.      A standard XS application code

2. A fuzzy request

GET /echo.xsjs?pollute=val1&pollute=val2&pollute=val3

The result page will be

To avoid erroneous side effects always verify the input and handle it properly. If the correct behavior of the application expects a single value for a parameter then you’d better verify that.

In a combination of GET parameters, POST parameters, and cookies with the same name Java and HANA XS behave similarly.

• GET parameters are listed before POST parameters
• Cookies are never mixed with parameters, but obtained via a different API method

Be careful with the cookies, however, as they can also have multiple values. As cookies can also be manipulated (e.g. by Cross-site cooking) you shall also verify if a cookie has multiple values and handle those cases properly.

References

[1] HTTP Parameter Pollution - Luca Carettoni, Stefano di Paola

[2] OWASP Guide: Testing for HTTP Parameter Pollution