Paid Advertising
web application security lab

Using Parameter Pollution and Clickjacking to Aid Anti-CSRF Bypass

It’s been a while since I’ve talked about Clickjacking, with only a few exceptions here and there. Mostly because I haven’t seen it much in the wild - at least not yet. But there’s still a lot of research out there to be done. I got an interesting email the other day that talked about a way to use parameter pollution (or a mix of URL parameters and POST) to create a condition where you can defeat CSRF tokens:

The technique, found by Lava Kuppan describes a scenario where a mix of CSRF, parameter pollution and Clickjacking can defeat CSRF tokens in JSP and (sometimes) in ASP.NET. It’s worth a read. I did briefly mention using CSRF to pre-populate fields that may be necessary to create a Clickjacking scenario during Jeremiah and my brief talk at the world OWASP in New York. But this takes it to a new level, where you can pre-load information in such a way that it will actually defeat the application logic in the process. Anyway, cool stuff by Lava.

9 Responses to “Using Parameter Pollution and Clickjacking to Aid Anti-CSRF Bypass”

  1. digi7al64 Says:

    In regards to .NET, when the form is run at the server it will always add an action into form by default. Therefore the only real issue in regards to CSRF is when incompetent programmers (generally MS certified) use the request.params object as opposed to request.form object to get passed in variables (which opens the door to GET request attacks).

  2. embyte Says:

    Maybe you could be interested in a recent work we have conducted on clickjacking of the title “A Solution for the Automated Detection of Clickjacking Attacks”.
    Abstract is:
    Clickjacking is a web-based attack that has recently received a wide media coverage. In a clickjacking attack, a malicious page is constructed such that it tricks victims into clicking on an element of a different page that is only barely (or not at all) visible. By stealing the victim’s clicks, an attacker could force the user to perform an unintended action that is advantageous for the attacker (e.g., initiate an online money transaction). Although clickjacking has been the subject of many discussions and alarming reports, it is currently unclear to what extent clickjacking is being used by attackers in the wild, and how significant the attack is for the security of Internet users. In this paper, we propose a novel solution for the automated and efficient detection of clickjacking attacks. We describe the system that we designed, implemented and deployed to analyze over a million unique web pages. The experiments show that our approach is feasible in practice. Also, the empirical study that we conducted on a large number of popular websites suggests that clickjacking has not yet been largely adopted by attackers on the Internet.

  3. AppSec Says:

    If I read this correctly, which is usually a big *if*, there seems to be a realitvely simple way to prevent this problem:

    1) All forms should submit to a different page (this means that the attacker would have to atler either JavaScript or the HTML depending on where the action of the form is defined).

    2) All actionable requests (get rid of those darn URL based requests already) should submit via a post (duh).

    3) When processing data via an actionable request, make sure the parameters are not part of the URL.

    I did read it right, correct?

  4. lava Says:

    Thanks for posting. Small note, my full name is ‘Lavakumar Kuppan’ :)

    You are right about ASP.NET, the action attribute is added by the framework itself. However its behavior is exactly like that of not setting the action attribute in the form. Because by default if I request for “/updateEmail.aspx? ” ASP.NET puts the whole URL along with the querystring in to the form ‘action’ attribute. This is more serious because almost all ASP.NET forms are set this way. It would not be a stretch to say that any ASP.NET application that uses ‘Request.Params’ is vulnerable to this attack. If the form is being submitted over ‘GET’ then it only gets worse. Am going to update the post with this detail. Thanks for pointing this out.

    Your interpretations are right.
    To simply things, the following can prevent this:
    1) If its a JSP application then hard-code the form’s action attribute and donot take this from the URL of the request.
    2) For ASP.NET applications, donot use Request.Params and stick to POST method for form submission.

  5. Tom T. Says:

    Is there any reason why this attack would not be defeated by the default clickjacking protection in NoScript, even with JS “globally allowed” (gasp!)? And with the default of “forbid [IFRAME]” at all but whitelisted sites, and some of us apply all of those restrictions to even our trusted sties. (NS > Options > Embeddings > “Apply these restrictions to whitelisted sites too”.) Two different protections against the attack.

  6. p0deje Says:

    @Tom T.
    There are couple of ways to prevent Clickjacking within NoScript:
    ClearClick. which was tested by RSnake by the way. but I didn’t really go deep into how it works. Maybe he’ll enlighten us about bypassing it :)
    Using X-Frame-Policy but I know only couple of sites which use this header and besides, sometimes NoScript fails (e.g. yesterday I’ve noticed that it ignores X-Frame-Options header if site is in object tag)
    And certainly forbid [IFRAME] won’t help, because there are also object, frame, embed elements and maybe smth else

  7. Tom T. Says:

    @ p0deje:

    Yes, ClearClick is Giorgio Maone’s name for his principal clickjacking protection, built into NoScript and default-enabled with no user action necessary. My question was, wouldn’t this prevent the attack? If not, why not?

    NoScript blocks practically everything - objects, frame, etc. — by default on untrusted sites. And if you tell it to, it will block them on trusted sites as well. You can allow individual exceptions temporarily as needed, if you trust the site. So again, if NS is in “full lockdown” mode, can the attack bypass that? That was my question.

  8. p0deje Says:

    @ Tom T.

    As far as I remember, NoScript doesn’t block iFrames and Frames by default, but I maybe wrong.

    ClearClick is cool thing, but it can be bypassed (it seems that I’ve found a way, but gotta test more). And more, it saves only your clicks, not your keyboard hits. So you may trick user with something like “Click Tab and hit Enter to download this video”

    So, I think, NoScript doesn’t 100% bullet proof by default. But if you block all iframes, objects etc. for all trusted sites, I suppose you will be safe.

  9. p0deje Says:

    Argh, I was wrong. ClearClick protects your keyboard hits also and my “bypass” was just a same-domain design idea.
    It seems that NoScript will save you