new HTTP Parameter Pollution (HPP) extension

[Guifre Ruiz Utges]

Hello,

I wrote a new plugin for ZAP to detect HTTP Parameter Pollution (HPP) issues. There are a very few pentesting apps that detect this type of vulnerability and I thought it would be a useful feature, in addition tu funny to write/test. The revision can be found at http://code.google.com/p/zap-extensions/source/detail?r=183

There are many types of HPP attacks, such as connection string HPP  and other server-side attacks. I focused this very first version of the extension on client-side attacks. Concretely, I based the logic of the plugin on the algorithm described in the "HTTP Parameter Pollution Vulnerabilities in Web Applications" paper, by Marco Balduzzi at BlackHat Europe 2011.


The current plugin algorithm works in high-level as follows: For each page that has URL or POST  parameters, it injects a malicious payload (hardcoded parameter) to each one of the previous parameters in a single HTTP request. If the payload is displayed back to the user in the 'href' attribute of a 'a' tag in the response body, the plugin will conclude that the page is vulnerable to HPP. As the tool presented in the previous paper, it is only able to detect client-side attacks.

I had to create my own testing page for the plugin as I couldn't find any demo app for testing HPP:

<?php
$v = $_GET['a'];
echo "<input name=\"a\" value=\"\" type=\"hidden\">\n";
echo "<input name=\"action\" value=\"\" type=\"hidden\">\n";
echo "<a href=\"http://aopcgr:10001/hpp/action.php?action=good&a=$v\">Link Text Here</a>";
?>

If someone knew a benchmarking tool vulnerable to HPP, I'd be very glad to know. The ouput of the previous page when debugging:


101442 [Thread-20] DEBUG org.zaproxy.zap.extension.httpParameterPollution.HPP - Targeting http://aopcgr:10001/hpp/
101443 [Thread-20] DEBUG org.zaproxy.zap.extension.httpParameterPollution.HPP - The following input parameters have been found:
101443 [Thread-20] DEBUG org.zaproxy.zap.extension.httpParameterPollution.HPP - Input Tag: a, 
101443 [Thread-20] DEBUG org.zaproxy.zap.extension.httpParameterPollution.HPP - Input Tag: action, 
101443 [Thread-20] DEBUG org.zaproxy.zap.extension.httpParameterPollution.HPP - Injecting payload...
101447 [Thread-20] DEBUG org.zaproxy.zap.extension.httpParameterPollution.HPP - Found Vulnerable Parameter with the injected payload: a, [%26zap%3Dzaproxy]
101447 [Thread-20] DEBUG org.zaproxy.zap.extension.httpParameterPollution.HPP - Page vulnerable to HPP attacks
101447 [Thread-20] DEBUG org.zaproxy.zap.extension.httpParameterPollution.HPP - New alert pluginid=20014 HTTP Parameter Pollution uri=http://aopcgr:10001/hpp


I tested it against many other packages without raising any false positive. The performance of the plugin is quite good, it only performs one request on pages that have user-controllable parameters, otherwise none.


Comments and suggestions are kindly welcome,

Guifre.

[Colm O'Flaherty]

Hi Guifre,

The paper is a bit of a big beast, so it's unlikely that you have implemented 100% of it.  I'm interested in the small number of special cases that the authors identified regarding false positives (Section 3.3.1 in the paper): does the scanner look for those cases, and ignore them?

Does your implementation look at the effect of the order of the parameters at all? ie, does it do the P-Scan, or just the (more necessary) V-Scan?

How does this version differ from the existing Parameter pollution scanner available on the extensions download page (zap-ext-servletParamPollution-alpha-1.jar)?

You could test this against some of the test case suites mentioned in previous mails. You're likely to find HPP vulnerabilities in some of the suites, even though they were not designed as HPP test cases.  It's also a good idea to test the scanner on a few different platform types: JSP based, PHP based, etc.

So many questions, so little time.

It looks like a nice piece of work, by the way. Well done!

Colm

--
 
 

[psiinon]

Agreed - great work!

And it would be really useful to test it against real world apps.

But it would also be great to have some regression tests as well - this actually goes for ALL scanners, and I've been meaning to post about this for a while ;)

I started making a set of vulnerable web pages for testing ZAP (called WAVE) but Shay took the idea and went way beyond where I'd got to, creating wavsep
I'd like us to use wavsep for our regression tests, and extend it to handle new tests.
Shay has agreed to look at adopting anything we add (and has already done so for previous tests)

Cosmin has already extended it for testing his spider: http://code.google.com/p/zaproxy/source/browse/#svn%2Ftrunk%2Fwavsep%253Fstate%253Dopen

So everyone please add more tests under the trunk/wassep/WebContent directory, either to test existing scanners or new ones (or for vulnerabilities we dont currently detect).
I'll try and set up easily reproducible regression tests around this (which I started for wavsep 1.1.1) - my plan is to set up a build server which will build and test ZAP every night.
As a side effect this will give us nightly builds that people can try out without having to build ZAP themselves :)

Many thanks,

Simon

[Guifre]

Hello,

Thanks for replying!

> The paper is a bit of a big beast, so it's unlikely that you have
> implemented 100% of it. I'm interested in the small number of special cases
> that the authors identified regarding false positives (Section 3.3.1 in the
> paper): does the scanner look for those cases, and ignore them?
> Does your implementation look at the effect of the order of the parameters
> at all? ie, does it do the P-Scan, or just the (more necessary) V-Scan?

I based the plugin on that paper, but I have not implemented 100% of
it so far. I thought determining the parameter precedence would
required additional requests and for this first commit I have not
developed it. However, it is a nice feature to include in the
following days. I have not make it to get any false positive so far.

> How does this version differ from the existing Parameter pollution scanner
> available on the extensions download page
> (zap-ext-servletParamPollution-alpha-1.jar)?

AFAIK, the algorithm is completely different. If I understood well the
code, the previous extension checks for the action attribute in the
form tags. If not available, it raises the alert.

On the other hand, the new one identifies all the input fields of the
targeted page, it injects a HPP payload in each one of those. After
it, it analyzes the body response to determine if the payload is
displayed back in a link. If so, it raises an alert. I think we are
looking for different things.

> You could test this against some of the test case suites mentioned in
> previous mails. You're likely to find HPP vulnerabilities in some of the
> suites, even though they were not designed as HPP test cases. It's also a
> good idea to test the scanner on a few different platform types: JSP based,
> PHP based, etc.

I did not know about those threads, I will look for them, test it and
post the results. Thanks!

Guifre.

[Colm O'Flaherty]

Hi.

It probably makes sense to consider merging the two plugins, or at least, being very clear about the name of the plugin, given the existing plugin.  Having two plugins with nearly the same name, doing very related things (admittedly in different ways) will just cause confusion, unless some additional clarification is made (IMHO).  What does everyone else think about this?

I won't get a chance to play with this over the next few days or week because of other commitments, so I can't make any comments on the behaviour.  Hopefully some of the others will get a chance to test-drive it! :)

The results from the test suites will be interesting.  In my experience, I always end up finding new scenarios that I hadn't handled when I run a new scanner against the various test cases.  If you get a chance as well, don't forget about Simon's comments about adding new test cases to wavsep for things that we test for.

Yes, the P-scan is a "nice-to-have".  It would definitely be nice to be able to know the parameter priority though, to more easily manually reproduce an exploit, if the need arose.  It would also be useful for us to validate the results of the scan.

C

Guifre.

--

[Guifre]

Hello,

I didn't want to break the current plugin, so I created a new one.
Whenever we feel it is time to, we can merge them both. However, I am
still writing new stuff so I think it is worth it to wait for the new
features to be working and for more testing.

Also, I agree with the needed wavsep tests and the P-scan feature, I
will start on those after finishing implementing a few features I am
working on.

Thanks and regards,
Guifre.

[psiinon]

I'd recommend not merging the 2 plugins, but just making sure that they are compatible and suitably named.
The other plugin is a passive rule, and so can flag potential issues before the active scanner is run.
There is a related issue: http://code.google.com/p/zaproxy/issues/detail?id=336 which talks about creating an active rule :)
Guifre - maybe you could update that issue to mention your new scanner?

Cheers,

Simon