To further illuminate the problems with Google Gadgets that Tom Stripling spoke about at the OWASP conference, I asked him to type up the details so that we could all take a look at it. I think this is a fairly thorough writeup. Obviously there is some more work to be done here, but ultimately, I think this proves the point:
First of all, here is the Google documentation on inlining, if you’re
My original goal was to CSRF a module onto someone’s page, then run another CSRF attack that inlined it, and then go to town. Google has thwarted my early efforts, but I’m not convinced that it isn’t possible.
Google has a parameter called “_et” that is set to a random value and required on every change to the iGoogle page. Without this value, you can’t submit a valid request to load a module, so it prevents basic CSRF.
It turns out that the parameter also shows up on the gmodules.com domain for certain “approved” gadgets. So, I was going to steal this parameter with AJAX and use it force a module on someone’s page.
The initial attack would involve someone following a link to the page you identified that allows XSS on gmodules.com. A link like this:
This gadget (which is never meant to actually end up on someone’s page) loads an AJAX request to get the page for another (approved) gadget, steals the _et param and tries to submit a request to google.com that loads the gadget.
So right now, I still can’t cross over from gmodules.com to google.com without user interaction. Still, the user interaction is pretty weak. They provide a preview page that will load a module with one click:
And then another click to inline the module. By the way, don’t load that on your real google account. It actually does send your cookies offsite. Feel free to download, play with, or publish any of these gadgets. Here’s another one that just does a basic phishing attack:
That’s the basics of where I’ve gotten so far. I’ll keep you posted if I figure out that _et issue.
So yes, in theory, anything sensitive you have on Google is once again at risk. This is based off the original hole discussed where Google felt the hole was intended behavior. No apology needed, Google. Great work by Tom Stripling!