Paid Advertising
web application security lab

Detection of Parameter Pollution

30 posts left…

There are a lot of web based exploits that can be really tricky to spot if you’re talking about a WAF. Multiple encoding issues, obfuscation and the like… Well, one attack in particular I think is actually pretty easy to detect programmatically (in most cases). In the case of HTTP Parameter Pollution the attacker has to double up on the parameters. So something like: ?a=1&b=2&a=3. If the WAF sees the same parameter (in this case “a”) supplied twice it’s pretty easy to understand that either there was something screwed up or it’s an attack. Either way, it’s worth reporting, and possibly even blocking if you know your site isn’t built like this.

Of course the normal caveats for non-standard parameter delimiters apply (hopefully the WAF could be developed to understand those delimiters in a perfect world). Not to mention the fact that even last week I saw a site that did Parameter Pollution on itself because of shoddy programming (and probably a lot of cutting and pasting by the developer). There could also be cases where some parameters come in on the URL field and others are POST parameters, so that would need to be taken into account as well for systems that don’t care and accept it all as a big pool of parameters. Lastly, I doubt many attackers are actually using Parameter Pollution (yet), but it should be easy enough to catch in most cases.

12 Responses to “Detection of Parameter Pollution”

  1. Jim Manico Says:

    Please keep in mind that multi-select lists (select component’s with the MULTIPLE attribute) will legally send multiple selections with the same parameter name. This is legal HTML.

    I’ve seen filters of this nature break apps that depend on this kind of very standard form component. And yes, programmers *can* let forms submit over GET, although it is a bad practice.

  2. Jim Manico Says:

    > If the WAF sees the same parameter (in this case a) supplied twice its pretty easy to understand that either there was something screwed up or its an attack.

    I again submit, respectfully, that this statement is wrong due. In my comment above, I meant to say “This is legal HTTP” not “This is legal HTML”.

  3. RSnake Says:

    @Jim - Sure, in the case where your site was built like that, yes, you’d want to turn off such a filter. Certainly not the norm, but something to be aware of - I agree.

  4. Narkolayev Shlomi Says:

    It’s relatively easy to defend against HPP attacks.
    Ten months ago I have designed similar solution for F5 ASM and it works great.

    From my experience, it didn’t break applications at all, because most of the application don’t expect same parameter name (Even if it’s case sensitive) on same request.

    Narkolayev Shlomi,

  5. Matt Presson Says:

    I have also seen HTML radio buttons work in the same way the Jim mentions. Of course, in this case you wouldn’t turn on the filter for that param, but thought I should add to the list of caveats.

  6. Matt Presson Says:

    Sorry, not radio, but check boxes (don’t know what I was thinking there)

  7. Jim Manico Says:

    Matt is right - checkbox groups do indeed send multiple values with the same parameter name. These use-cases are very common in enterprise applications. Be careful about globally using this defense method without carefully reviewing the forms of your app.

  8. Narkolayev Shlomi Says:

    Matt is right, checkbox uses same paramter name, but checkboxs are very rare use in most of applications, and it will not work for single checkbox (On/Off).

    In advanced solution the administrator can just turn this feature off on specific pages and on specific parameter name for specific page or it can be done automaticaly using sort of dinamic policy builder.

    Narkolayev Shlomi,

  9. Jim Manico Says:

    Nark, the solution should not be administrator centric, that’s implying faulty human configuration. And what do you do if you work at a SaaS with many thousand forms? This kind of defense should be baked into your application stack in a way that auto-discovers multi-select lists and (multiple) checkboxes as described above. If you just blindly “flip this filter on” you are going to break many forms. Your “advanced solution” is fragile and would require a huge amount of work to maintain over time.

    Bottom line: Sending multiple values with the same request parameter name over GET or POST is legal HTTP and you cannot apply this filter blindly.


  10. Soroush Dalili Says:

    Regarding to Jim sayings which are right, we can find duplicated parameters by having anomaly detection before enabling this option. Check boxes do not contain dynamic values (normally), therefore I think it is possible to find normal behaviour of the application (and finding duplicated parameters) by using a Crawler (with form submitter) and/or web application functional testing tools. Then, it is possible to exclude these duplicated parameters from the list. However, in case of adding a new form or having complicated Javascript to create dynamic forms, it can be a pain.

  11. Narkolayev Shlomi Says:

    As I mention above, this is WAF based solution that support manual and automatic policy configuration.

    Dynamic profilers can easily detect legitimate use of repetitive parameter (like checkbox parameters) and disable this check for this specific parameter on specific page.

    As we all probably know, HPP could allow attackers to evad filters, so if the application don’t have filter at all, maybe this should not worry the application owner.

    HPP is a result of frameworks bug, so I decided that there is a need for a solution for this evasion technique for some application frameworks, and for eliminating False Positive and application break, there is a need to detect legitimate use of repetitive parameter.

    Narkolayev Shlomi,

  12. Arthur Says:

    @Jim Manico

    You’retotally right. There are cases where the solution won’t work. Therefore we shouldn’t use it.