Paid Advertising
web application security lab

RequestPolicy Firefox Extension

Over the last few days I’ve had the pleasure of corresponding with Justin Samuel, who has recently authored a new module called RequestPolicy that has some pretty wide reaching security implications for anyone who is concerned with cross domain related exploits. Here’s a snippet of our conversation:

RequestPolicy gives users full control over the cross-site requests made by their browser. It has a default deny policy and allows easy whitelisting of origins, destinations, and origins-to-destinations.

The website is here:

You can probably imagine the various security issues this helps with (not just CSRF, but that’s a big one). We have a security page here with some details:

I see RequestPolicy as fulfilling an essential role for privacy and security in our browsers. I believe that a truly secure Firefox install is running at a minimum both RequestPolicy and NoScript. (RequestPolicy is not a competitor to NoScript, obviously, but unfortunately a large number of people immediately think this because they are unaware of threats that aren’t from scripts and objects.)

Justin has a bunch of things on his to-do wishlist, including improvements to the UI, more granular control over what gets blocked, a blacklist of subnets (similar to localrodeo), and so on. Of course there are a few small issues that I ran into almost immediately, like the fact that subdomains are always allowed, which means an attacker could subvert that protection by assigning a subdomain to RFC1918 (assuming LocalRodeo wasn’t installed) or to a target domain that required no cookies to be submitted for the exploit to function since the wrong hostname would be sent. So perhaps for the time being a combination of LocalRodeo, NoScript and RequestPolicy is the safest bet.

It’s also fairly easy to detect that this module is installed, and for most users, it will be a very tough user experience to get used to, unless they whitelist everything. Still, very cool module to prevent most of the crossdomain/cross website client side hacking, and I bet it will become even better with time!

9 Responses to “RequestPolicy Firefox Extension”

  1. Wladimir Palant Says:

    Interesting, I’ll have to take a look at this. I made some steps into a similar direction in Adblock Plus 1.0 and 1.0.1.

  2. Giorgio Maone Says:

    Interesting indeed.
    Some users of mine (”luntrus”, most notably) told me about that last week.
    By the way, did you notice ?

  3. Justin Samuel Says:

    @Wladimir - With the steps in a similar direction you mentioned, I think you’re referring to the filter option “third-party”. I could be wrong about that. Either way, that’s great that ABP users are getting more control over cross-site requests. I’m positive that there are plenty of ABP users who will be able to fulfill their cross-site request blocking needs with ABP alone and won’t need RequestPolicy.

    @Giorgio - First off, thank you for making NoScript. NoScript is still the first addon people should install on any new Firefox profile (or SeaMonkey, or Flock, or Songbird, etc.). I’ve spent a fair bit of effort trying to debunk the idea that RequestPolicy intends to compete with NoScript. Of course, people who understand web security know that that’s not the case, but there are a fair number of security-concerned users I’ve encountered who don’t see this as clearly. If anyone ever tells you they don’t need NoScript because they have RequestPolicy installed, point them right to me and I’ll set them straight. And ABE looks like it will be amazing. A tool like ABE definitely needs to exist and I’m glad you’re making it.

  4. ungullible Says:

    As you noted, this could be a rough user experience for many. And it is browser-specific, and requires users to install additional software, so I don’t see a high adoption rate. An alternate anti-CSRF-specific idea that I had recently involved modifications to the browsers and perhaps HTML specs, but would not require any end-user involvement. I’m interested in your and your readers’ thoughts on this.

    My idea was simply to re-engineer browsers so that they never transmit cookies along with cross-domain requests. If there was a legit reason to transmit session tokens, the web app generating the request would have to know it and send it as a POST variable (hopefully over https) instead of relying on cookies. Alternatively (and here’s where expansion of the HTML specs comes in), if the app needs to transmit session info but doesn’t know it, the developers can add a special tag to the request that causes the browser to generate a security warning to the user that asks permission to include cookies.

    This is admittedly CSRF-specific protection, and isn’t perfect. But it seems to me that it would protect a much larger population of internet users and suffer less from a bad user experiences managing their own whitelists.

  5. Anthony Lieuallen Says:

    The same thing is doable with the right ruleset, with my Karma Blocker extension, sans GUI:

    Personally, I just have some bad karma for “third policy”. But you can certainly write a “host is” and “origin host is” rule, too!

  6. Rob Says:

    I am a n00b in matters like this, so please forgive my ignorance, but if you could explain in a little more detail how RequestPolicy is different from NoScript that would be great.

    I understand the idea behind NoScript, not allowing any scripts from running that you don’t specifically allow.

    How do you recommend getting users to understand and use tools such as NoScript and RequestPolicy? What is a good high level way of explaining it?

  7. kaes Says:

    Ungullible: That’s HTTP specs, not HTML. And presumably instead of adding “special tag” to the request, you meant a special HTTP header?
    Unless you’re seriously proposing adding network/transport protocol specific declarations to a document markup language ..

  8. Justin Samuel Says:

    @Rob Hopefully this can clarify the difference between RequestPolicy and NoScript a bit:

    In terms of how to use these tools, my advice for people who may not otherwise use them due to their restrictiveness is to whitelist everything they need to in order to make websites they need to use work. Even with very liberal whitelist policies, these extensions will keep your browsing more safe and private than if you did not use them at all. More advanced/concerned users who are not at risk of frustration causing them to uninstall or disable the extensions can be pickier about what they whitelist and base those decisions off of their knowledge of web security and gut feelings about individual websites.

    (Also, today’s 0.5.0 release of RequestPolicy added the ability to use finer-grained domain policies, such as using full domains rather than only registered domain names.)

  9. Rob Says:

    Thank you for the clarification Justin, very much appreciated.