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:
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>
<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.
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:
Install Mercurial (the source repository system)
sudo apt-get install mercurial
Fetch the bleeding edge RequestPolicy source code into ~/requestpolicy/
cd hg clone https://www.requestpolicy.com/hg/requestpolicy
Uninstall RequestPolicy if you already have it installed
Tell Firefox where to find RequestPolicy
ln -s ~/requestpolicy/src ~/.mozilla/firefox/YOUR_PROFILE_DIRfirstname.lastname@example.org
Restart Firefox and make sure RequestPolicy is working as normal
Delete or comment out every line where the functions “registerLinkClicked” or “registerFormSubmitted” are called, making sure to handle multi-line code, in the file:
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.
Looking to hire somebody like me? I'm open to offers of full time employment and small contract jobs. Check out my hiring page. You can follow this Blog using RSS or Twitter. To read more, visit my blog index.