Browser Security Tools: RequestPolicy
Note: I originally posted this piece on my employer's blog. I'm shamelessly cross-posting it because this is a really cool extension, and I want lots of people to check it out.
I spoke about CSRF attacks at Defcon a few months ago, and while I was there, I had the opportunity to meet with Justin Samuel, the creator of RequestPolicy. RequestPolicy is a Firefox extension designed to provide CSRF protection and enforce web application boundaries. I love it.
Request Policy completely breaks the web... in all the right ways. You'll initially hate using it. StumbleUpon links will no longer work, due to their use of cross-site iframes. Shortened bit.ly and tinyurl links will present you with an intermediate page instead of following 302 redirects. Deeplinked images on blogs, social networking sites, and other pages won't show up. You will have to manually approve off-domain requests on a case-by-case basis. It's not convenient, but it's a lot safer than letting your browser blindly request resources.
In short, RequestPolicy gives you granular control over your browser. If you know what you're doing, this is a good thing. If you're a normal user, you'll probably find yourself checking the "Temporarily Allow All Requests" box or disabling the extension completely. I can't say I'd blame you, but try not to. The extension is still very young in its development process, and most of the issues that I've run into are UI/usability problems. The developer is aware of many of these issues and working to fix them, but it's not easy. Samuel is very open to suggestions, feedback, and criticism, so if you have useful input, I'm sure he'd be happy to hear it- just hit the contact link on the extension's website.
The UI is heavily modeled after NoScript, so if you're a fan of that extension (and you should be), it isn't too difficult to figure out. Off-domain requests are disabled by default, and can be enabled on a per-site, as-needed basis. The preferences pane is simple and fairly easy to understand, allowing you to more easily manage your whitelist of allowed domains. Additionally, the extension ships with a setup wizard to create generic whitelists based on common sites (recaptcha, for example, has to be whitelisted for every domain that uses it). All in all, it's pretty easy to set up, and though it will break a lot of sites at first, as you fine tune the settings to your browsing habits, it really doesn't get in the way too much.
RequestPolicy was created for a very specific purpose: to give users the ability to better control their browsers and prevent CSRF. It's a bit rough at the moment, but it's very good at it.
Labels: CSRF, Security Tools
posted by mckt at
3:20 PM
4 Comments:
I can't seem to understand why no one is thinking about the following simple solution: Major web sites who suffer from CSRF can just check the "referrer" http field.. Let's take facebook for example- if they allow their "login.php" or "sendmessage.php" to get POST requests only with the "referrer" field containing "www.facebook.com", or "iphone.facebook.com", "lite.faceb..." etc., that should solve any IFRAME logging-in and trying to pose as the user itself. Or you know what? maybe adding that we're-not-sure-you're-human captcha they do every once in a while if you do something they believe is fishy. That solves CSRF for facebook.
If all major services (and it's their interest as well as their users') block up their site as such, that problem should disappear. Am I missing something?
By
ofir, At
November 30, 2009 2:06 PM
Yes, you're missing something.
Referrer-based CSRF protection is used by many applications, but it's not a very resilient protection. First off, many browsers (mine included) can be configured to never send referrer headers. This is usually done for privacy reasons, but the web app needs to continue to function. Arguably, the app could detect this and insist that the user enable referrers, but this isn't user-friendly (remember those "we don't support your web browser" error messages? Remember how much you hate them?).
There are other legitimate reasons to not send referrers. Some web browsers don't send referrers on SSL sites. That sounds like a good idea to me, and more browsers should do the same.
Finally, there are ways to spoof referrers. It's been done with Flash before. It can be done with an open redirect, XSS, cross-site framing, or HTML injection hole. Depends on the targeted client and server, but the point is, referers aren't very strong.
As noted in a previous post, cPanel uses referer-based CSRF protection (where it's enabled). I posted a proof-of-concept demo video bypassing this very protection.
The CAPTCHA protection isn't a bad idea, but it is a hassle to use it on every form in an application. Instead of requiring user interaction, an app should simply set a cookie with a randomly generated token, embed that same token in the form, then check on the server side whether those tokens match up. If they do, one can assume that the user requested the same form that was submitted. If they don't match, then the form was not generated for this user. Problem solved.
By
mckt, At
November 30, 2009 2:06 PM
Post a Comment
<< Home