Paid Advertising is
ha.ckers sla.cking
Where you should disclose your vulnerabilities. Go read RFPolicy if you want to do responsible disclosure, and go here for when all else fails. 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
CSRFing iGoogle
Posted by: tx
Date: November 02, 2007 03:03PM

So I'll assume you've read pdp's post about the CSRF vuln in gmail: (fixed I believe).

I wanted to explore some more google csrf stuff, here is what I found:

First, simple csrf to automatically log somebody out of google:
<img src="">

Nothing fancy there, but it got me hunting for more GET based CSRF vulns. The only thing is, much of anything important with google services is done through POST. And while it's not hard to create a self submitting form with javascript. I wondered if there was a way to do it directly on the google home page (since if a user is viewing their iGoogle home page they are already logged into google and all of it's services).
Initially I tried to put it into an rss feed. No luck there (although you can embed images, good for GET based CSRF).
And then it hit me... iGoogle modules.

(quick break, read this if you haven't yet: )

The modules are on the iGoogle page in their own iframe (to maintain same-domain protection), they can not only run javascript but they can include iframes as well. If you'll note pdp's attack you'll see he embedded an iframe that linked to a page with a form that submitted itself with javascript. Perfect for a module.
So we simply create a simple module with an hidden iframe that points to a page with a form that submits our POST based CSRF to google. An excellent framework for attack, the only trick is we still have to get the user to actually add the module to their page...

or do we?

(I'm using Rsnake's module as an example, it's trivial to create these things, especially now that they've even included an editor )

This url : will add rsnake's module (which pops up a simple alert) to your google home page.
and yes we can call it in an image tag without user interaction.
We can even put it in an rss feed:
<?xml version="1.0"?>
<rss version="2.0">
    <title>CSRF PoC</title>
      <title>Read me!</title>
      <description><![CDATA[uh oh, you shouldn't have read this.<img src=""> !]]></description>
      <pubDate>Tue, 04 Sep 2007 05:06:37 +0000</pubDate>

It's only a short leap to image what happens if someone were to spoof a currently popular module, title it similarly, and include a small iframe to completely pwn somebodys google (mail|documents|spreadseet) account. What's more, the attack could change daily if the attacker so chose since they still control everything that is being delivered to the user.

I'm sure there is way more that can be discovered...

As an addendum, yes noscript will protect you from both javascript posted form and potentially any POST based CSRF so long as the attackers module is hosted on an untrusted site.
A small exception to this, is if the user has in their trusted sites (a reasonable thing if they have other modules on their iGoogle page as many do).
Google provides a convenient proxy for gmodules here: h+tp://
As long as all request are prepended with the proxy url the POST CSRF will be[trusted]->[trusted]

So that means, another reason not to trust

BTW, I'd love some confirmation on this if you want to test it out yourself.

EDIT: I've found that the url to add a module only works about 90% of the time, I believe that the en variable may be a kind of token for the request (although it's not limited to a specific account). If the token changes with any regularity it can always be found by querying and pulling the link from there.

-tx @

Edited 1 time(s). Last edit at 11/02/2007 03:25PM by tx.

Options: ReplyQuote
Re: CSRFing iGoogle
Posted by: rsnake
Date: December 10, 2007 05:29PM

I love it. Just sooooo love it. Any other theories on what the en var is? Maybe it's tied to a datacenter or something?

- RSnake
Gotta love it.

Options: ReplyQuote
Re: CSRFing iGoogle
Posted by: tx
Date: December 12, 2007 03:36PM

@rsnake: like I wrote in comments here: it's actually the et (or _et) variable that is the issue. And it's some sort of token. It's not tied to your google account, it's tied most likely to browser cookies (that are shared across accounts). For instance if you log in to google you get a value for et. if you then log out and log into another account, using the same browser, the et token will still have the same value. Meaning that one malicious user on a shared browser (for example at an internet cafe) can potential CSRF anyone else who uses that browser. Clearing cookies seems to be the only way to change your _et value.
I'm still trying to figure out if I can control it indirectly somehow.

-tx @

Edited 1 time(s). Last edit at 12/12/2007 03:52PM by tx.

Options: ReplyQuote

Sorry, only registered users may post in this forum.