HTTP Parameter Pollution. So how many flawed applications exist out there?! We go online with a new service.

In this post, I’d like to give a brief overview about our upcoming paper on detecting HPP problems in web applications. The idea is to save readers from the effort of going through the entire paper.

Typically, web applications are built using heterogeneous technologies and consist of code that runs on the client (e.g., Javascript) and code that runs on the server (e.g., Java servlets). Even simple web applications today may accept and process hundreds of different HTTP parameters to be able to provide users with rich, interactive services. As a result, dynamic web applications may contain a wide range of input validation vulnerabilities such as XSS and SQL injection.

While these vulnerabilities have been intensively studied, a new class of injection vulnerabilities called HTTP Parameter Pollution (HPP) has not received as much attention. HPP was first presented in 2009 by Stefano di Paola and Luca Carettoni at the OWASP EU09 Poland conference (presentation).

HPP attacks consist of injecting encoded query string delimiters into other existing parameters. If a web application does not properly sanitize the user input, a malicious user can compromise the logic of the application to perform either client-side or server-side attacks. One consequence of HPP attacks is that the attacker can potentially override existing hard-coded HTTP parameters to modify the behavior of an application, bypass input validation checkpoints, and access and possibly exploit variables that may be out of direct reach.

The consequences of the attack depend on the application’s logic, and may vary from a simple annoyance to a complete corruption of the application’s behavior.

The typical client-side scenario consists of persuading a victim to visit a malicious URL that exploits the HPP vulnerability. For example, consider a web application that allows users to cast their vote on a number of different elections. The application, written in JSP, receives a single parameter, called poll_id, that uniquely identifies the election the user is participating in. Based on the value of the parameter, the application generates a page that includes one link for each candidate. For example, the following snippet shows an election page with two candidates where the user could cast her vote by clicking on the desired link:

Url: http://host/election.jsp?poll_id=4568
Link1: <a href=”vote.jsp?poll_id=4568&candidate=white”>Vote for Mr. White</a>
Link2: <a href=”vote.jsp?poll_id=4568&candidate=green”>Vote for Mrs. Green</a>

Suppose that Mallory, a Mrs. Green supporter, is interested in subverting the result of the online election. By analyzing the webpage, he realizes that the application does not properly sanitize the poll_id parameter. Hence, Mallory can use the HPP vulnerability to inject another parameter of his choice. He then creates and sends to Alice the following malicious Url:

Url: http://host/election.jsp?poll_id=4568%26candidate%3Dgreen

Note how Mallory “polluted” the poll_id parameter by injecting into it the candidate=green pair. By clicking on the link, Alice is redirected to the original election website where she can cast her vote for the election. However, since the poll_id parameter is URL-decoded and used by the application to construct the links, when Alice visits the page, the malicious candidate value is injected into these two links:

Link 1: <a href=”vote.jsp?poll_id=4568&candidate=green&candidate=white”>Vote for Mr. White</a>
Link 2: <a href=”vote.jsp?poll_id=4568&candidate=green&candidate=green”>Vote for Mrs. Green</a>

No matter which link Alice clicks on, the application (in this case the vote.jsp script)
will receive two candidate parameters. Furthermore, the first parameter will always be set to green.

To the best of our knowledge, no tools have been presented to date for the detection of this sort of vulnerabilities and no studies have been published on the topic. The most effective means of discovering HPP vulnerabilities in websites is via manual inspection. At the same time, it is unclear how common and significant a threat HPP vulnerabilities are in existing web applications.

We, therefore,  decided to dig deeper into the detection problem and created  the first automated system for the detection of HPP vulnerabilities in web applications. We call our implementation PAPAS (PArameter Pollution Analysis System) — see below for the link to the online service.

We then conducted a large-scale, real-world experiment with more than 5,000 popular websites that we took from Alexa. PAPAS discovered that 1499 websites (29.88% of the total we analyzed) contained at least one page vulnerable to HTTP Parameter Injection. That is, the tool was able to automatically inject an encoded parameter inside one of the existing parameters, and was then able to verify that its URL-decoded version was included in one of the URLs (links or forms) of the resulting page.

The problems we identified affected many important and well-known websites (e.g., Microsoft, Google…).

We have created an online service based on PAPAS (currently in beta version) that allows website maintainers to scan their sites. You can submit your site to PAPAS for being tested. For free. Our automated system will analyze your web application, and send you a nice HTML-formatted report when the scan is completed.

The service is online at http://papas.iseclab.org.

I am also glad to report that our paper has been accepted to appear in the Network and IT Security Conference (NDSS 2011) in February. You can download the PDF here.

Update: I published this new post (first of a series) that explains PAPAS’ architecture and algorithms to efficiently detect HPP flaws.