Grepular

Toughening up RequestPolicy

Written 13 years ago by Mike Cardwell

RequestPolicy is a Firefox addon which is used to block cross-site requests. It helps defend against CSRF attacks, some XSS attacks and various tracking/privacy issues. It’s one my favourite browser addons, alongside NoScript. One of the things that it does which I dislike, is to attempt to differentiate between user-initiated and automatic cross-site requests, letting user-initiated requests through without blocking. For example, if you click a link or submit a form which takes you to another site. If a JavaScript event triggers those actions, they wont be treated as user-initiated and they’ll be blocked using your standard rules, but if your mouse does it, RequestPolicy lets it straight through.

This has been done for usability. The addon already interferes quite a lot with your browsing experience, and the author wants to try and minimise this. I have spoken to him myself regarding these issues. The idea is that if a user initiates a request, then they want it to take place, so why bother asking them? The trouble with this approach, is that even the most paranoid geeks can be tricked into clicking links.

If for example, you have visited http://ATTACKERS_SITE/, and the author of that site wants to get you to initiate a request to http://TARGET_SITE/CSRF.ATTACK; non RequestPolicy users are painfully vulnerable to this. All the attacker has to do is include some HTML like this in their page, and you will perform the request without realising:

<img src="http://TARGET_SITE/CSRF.ATTACK" style="display:none;">

RequestPolicy users are safe though. RequestPolicy will detect the cross-site request and detect that it wasn’t user-initiated. Unless you’ve whitelisted that particular cross-site combination, it will block the request and alert you. It will then give you the option of temporarily (until the browser closes) or permanently allowing it.

So for the attack to work against a RequestPolicy user, they need to trick you into initiating it. For example, they could create a link like this, and tempt you to click it:

<a href="http://TARGET_SITE/CSRF.ATTACK">Kittens!</a>

Of course, if you hover over the link, you’ll see that it is destined for another site, and look at the destination before clicking it. But if an attacker does this:

<a href="/kittens/" onclick="this.href='http://TARGET_SITE/CSRF.ATTACK'">Kittens!</a>

Hovering over the link looks like you’ll be sent to “/kittens/“, but in fact, you’ll be sent to http://TARGET_SITE/CSRF.ATTACK. What was that I heared you say? You’ve disabled JavaScript so the href replacement trick wont work?

<form method="GET" action="http://TARGET_SITE/CSRF.ATTACK">
  <input type="submit" name="submit" value="Kittens">
</form>

Unlike with a link, you can’t hover over a form to see where it will submit to. You don’t know if the submission will be cross-site, and RequestPolicy wont block the request if a user initiates it by clicking the submit button. And then we have a whole class of clickjacking attacks whereby an invisible link or form hovers underneath the mouse to intercept any clicks.

These are all user-initiated events, which RequestPolicy doesn’t block, and which could lead to CSRF attacks. I want RequestPolicy to treat them the same way it treats non user-initiated cross-site requests. If a form or a link tries to take me to another site, I want RequestPolicy to jump in and apply its magic.

Solution (hack)

I’ve made some small modifications to my local version of RequestPolicy so that it never considers any action to be user-initiated, and thus requests confirmation for all cross-site requests that aren’t whitelisted. I’m not going to release a modified extension. I don’t want to fork the project. But here’s how I did it on my Ubuntu system:

  1. Install Mercurial (the source repository system)

    sudo apt-get install mercurial

  2. Fetch the bleeding edge RequestPolicy source code into ~/requestpolicy/

    cd hg clone https://www.requestpolicy.com/hg/requestpolicy

  3. Uninstall RequestPolicy if you already have it installed

  4. Tell Firefox where to find RequestPolicy

    ln -s ~/requestpolicy/src ~/.mozilla/firefox/**YOUR_PROFILE_DIR**/extensions/requestpolicy@requestpolicy.com

  5. Restart Firefox and make sure RequestPolicy is working as normal

  6. Delete or comment out every line where the functions “registerLinkClicked” or “registerFormSubmitted” are called, making sure to handle multi-line code, in the file:

    ~/requestpolicy/src/content/overlay.js

  7. Restart Firefox and test

Firefox will no longer automatically update RequestPolicy after this. You will need to fetch updates periodically by running:

cd ~/requestpolicy
hg pull
hg update
hg merge

You could cron this, but it’s better to do it manually so you’re alerted to any updates that conflict with the changes you made.

Want to leave a tip?BitcoinMoneroZcashPaypalYou can follow this Blog using RSS. To read more, visit my blog index.