Victim must visit a malicious web page: most likely scenarios are clicking an external link from an incoming message or surfing porn while checking email from time to time.

The malicious web site forges a POST request to GMail's "Create Filter" wizard, possibly using an autosubmit invisible form to build a filter which forwards incoming messages to a mail recipient owned by the attacker.

Since user is already authenticated, her session cookie is passed along with the forged request and the GMail filter gets silently implanted, with all the output hidden inside an IFRAME.

The new GMail filter now acts as a persistent backdoor stealing incoming messages, and it will go unnoticed forever unless the victim is a power GMail user who creates or edits from time to time her own filters, which are deep buried in the "Settings" user interface: I, for instance, never saw them until yesterday!

Very clever and very dangerous.
As I said, this surely counts as a 0day public full disclosure: no matter if pdp omitted an explicit PoC. How many of us, having minimal web coding experience, wouldn't be able to build a working exploit using the info above?

CSRF Countermeasures

As usual, now that's been publicly disclosed, this vulnerability is being patched very quickly by the great Google development crew.
Nonetheless, many other holes of this kind are still around. That's why CSRF is called â€œThe Sleeping Giantâ€: some web coders may still need to learn how to fix or prevent them, and users surely want to know how to protect themselves.

1. Web Developers

Please use form keys!

Generate a random identifier (form key) every time you display a form meant to be submitted by authenticated users only.

Echo your key as an hidden field of the form and bind its value to the user session data kept on the server side.

As soon the form is submitted, compare the returned key with the one stored in session data: if they don't match, throw away the request because it is probably forged.

The above is a simple yet effective anti-CSRF technique. It will work fine unless a further Cross Site Scripting (XSS) vulnerability is present too, allowing attacker to read your form key on the fly and forge a seemingly valid requests.

2. Web Users

This GMail incident proves how even the best trained web developer in the world can fail at implementing CSRF countermeasures.
Most of the existing literature about XSS and CSRF will tell you that poor users can do nothing to protect themselves from these attacks, but this is blatantly false.
A quite radical, not very usable but effective approach would be using different browsers (or different profiles, if you use Mozilla derivatives) for each "sensitive" web site you access, and force yourself not to follow any external link nor browse any other site while logged in.

Anyway, if you prefer not to make your life miserable by spawning multiple browsers and scanning every single link with a magnifying lens, your answer is, once again, Firefox + NoScript (sorry to sound repetitive, but that's it).

First of all, automating a POST request is trivial if JavaScript is enabled on the attacker site --

form.submit()

-- but just impossible if malicious scripts are blocked by NoScript.
The obvious objection, raised for instance by both pdp and Adrian Pastor at GNUCITIZEN, sounds like:

The attacker could simply build an invisible POST form and disguise its "submit" button as a regular link or an image, then social-engineer his victim into clicking it and so have the exploit launched no matter if JavaScript is disabled.

True, but NoScript effectively defeats this attack as well!

A common misconception about NoScript is that it just blocks JavaScript on untrusted sites.
It certainly does, but NoScript actually enhances browser security in several other ways.
A very incomplete list:

It implements the most advanced and effective anti-XSS protection available on the client side.

NoScript's anti-XSS protection deploys various specific countermeasures, e.g. HTML/JavaScript injection detection, URL sanitization on suspicious cross-site requests, UTF-7 encoding neutralization and many others.
One of them also provides an effective defense from CSRFs of the kind affecting GMail: in facts, NoScript intercepts POST requests sent from untrusted origins to trusted sites and strips out their payloads.
This means that, even if the attacker exploits a scriptless vector to launch his POST CSRF through social engineering, NoScript users are still safe as long as the malicious site is not explicitly whitelisted.

Giorgio, sounds good, but doesnâ€™t that break things?
I mean, CSRF is one of the most fundamental Web characteristic.
Disabling it might be OK for people like us, but for the general population, that is a no go!

Petko, my friend,

The very foundation of the Web is CSR (Cross Site Requests, AKA Hyperlinking), not CSRF (Cross Site Request Forgery) which is an unwanted side effect of bad coding practices.

RFC 2616 defining HTTP (hence, in a certain sense, the Web itself), clearly states that while GET requests (the ones we generate by following hyperlinks or submitting a search form) are idempotent, i.e. should not modify the receiving system, POST is reserved to requests which cause a permanent change. NoScript just prevents untrusted sites from modifying data held by trusted sites, and this looks Pure Good™: why could you want the contrary?

Even if you actually wanted the contrary, you can either use the "Unsafe reload" command, available whenever a request is filtered by NoScript, or permanently configure some sites of your choice as unfiltered recipients of unsafe requests by listing them in NoScript Options/Advanced/XSS/Exceptions

The NoScript feature we're talking about has been in place for more than six month now.
I guess it's transparent enough if security researchers like you, Adrian or .mario -- people "like us", much more attentive to what happens inside their browsers than "the general population" -- did not even notice it... ;)

This entry was posted on Wednesday, September 26th, 2007 at 1:27 pm and is filed under CSRF, XSS, Google, Security, NoScript. You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.

To be dead honest with you, I don't use it. :) No really. I don't use it mainly because the browser is my power tool and I want to be able to do whatever I want with it without letting it be too cleaver my taste. I remember once reading an article which listed NoScript as one of the plugins you should not install. I through that this article is just stupid and the guy who wrote it does not know what he is talking about. However, let's be honest here for moment. How many people actually use NoScript? I would suggest that most technically savvy people use NoScript. However, not every body wants to know about scripts.

"What is a script? My browser asks me whether I want to run this script... hmm ok.. yes run it, damn you... I just want to see this page...what? White list? What is that?"

How many people know what is Cross-site scripting? Now, from that group, how many people do you think know what is Cross-site request forgery. I would say just a few. Most of the securty guys don't know what CSRF is. They've heard of it but they have no idea what it is.

Don't get me wrong. NoScript is one of the best things that have happened to Firefox and my and the rest of the community truly appreciate the work that has bee done. But also, I have to say that normal users will hate it in their guts mainly because it makes their MySpace page not working. We know that we cannot make regular users security experts just so they don't get hacked. They have other problems to worry about. The only proven way of protecting them is to write secure software. But again, that will never happen.

:) Don't get me wrong! I like NoScript. I am just saying that it is a power tool that only people like us will use it. It's like Firebug. Does your girlfriend have Firebug installed?

I installed NoScript on my wife's computer. She's by no means a geek, and she makes do with it.

Also, no, it doesn't really break much of anything since I've used NoScript with that option for quite some time without problems.

I know Giorgio sounds like he's doing PR for a company for as many times as he writes about NoScript, but he deserves to. He really puts so much work into maintaining it and adding great features, and it's easily my number one firefox extension.

NoScript is certainly not like firebug (i use both). I've been using it for months for "technologically savvy" uses, but soon I realized that anybody can benefit of using it - with scripts globally allowed- to increase security while maintaining usability. It is certainly an add-on everybody can benefit from.

don't get me wrong, Giorgio work is highly appreciated, all I am saying is that users don't have to be experts in order to know what sites should be able to use scripts. How do u trust a site? If it looks good? In order to trust the application that you are about to grant some permissions you have to really know what you are doing. In that case, how does this helps the normal user? They have to check the source code? It does help if you are visiting some doggy cracking sites and you expect to be hit any moment so u need to put your shields up, but for normal surfing... I don't know man. The web is changing drastically if you haven't noticed. Websites are almost like desktop applications. Do you have an warning from your Ant-vir every time you try to run an app? No! They try to mitigate the problem before warning you, if there is one.

And what about mashups? I mean, mashups are just combination of a bunch of services. So in order to run the stupid Google Maps you have to approve all websites the mashup is feeding from or interacting with? This is only for experienced surfers and web dev guys. Anyway, again, great work Giorgio. It is always good to get a different opinion. It helps you see the bigger picture sometimes.

As a security expert, I am supposed to preach about Application Firewalls, NoScript, IDSs, etc, but I don't. It is not just black and white. It is all about risk management. You cannot say to someone install this and your problem will be solved. It doesn't work this way.

[...] I choose qmail for my example because of its almost immaculate security records: should you pick a single product to illustrate mail server security risks, you’d bash Sendmail with its several documented vulnerabilities, rather than DJB’s impervious creature. However the article inexplicably morphed “qmail” into GMail, making my point quite obscure (given that GMail is not even a proper mail server, nor exactly a security champion). [...]

Don’t get me wrong. NoScript is one of the best things that have happened to Firefox and my and the rest of the community truly appreciate the work that has bee done. But also, I have to say that normal users will hate it in their guts mainly because it makes their MySpace page not working. We know that we cannot make regular users security experts just so they don’t get hacked. They have other problems to worry about. The only proven way of protecting them is to write secure software. But again, that will never happen.