Today RSnake revealed a cross site scripting vulnerability affecting Google Gadgets in the gmodules.com domain.
This XSS hole allows anybody to store his/her own web content, including JavaScript code, anywhere and to have it rendered and executed in the context of the gmodules.com domain, with no further validation of sort.
RSnake responsibly reported his finding to Google before resorting to public disclosure, but the G guys answered that this behavior is "by design" and won't be fixed.

What does it mean?
For the average user, such a vulnerability means that phishers can effectively exploit a site owned by Google as a free hosting facility, making quite impractical blacklisting and/or shutting down the scam: don't forget Firefox's built-in anti-phishing blacklist is provided by Google itself.

For NoScript users, it means that if you allow gmodules.com to execute scripts, you're trusting not just Google, as you may misled to believe, but everyone in the cyberworld -- even the most evil hackers like my RSnake friend ;) -- to run his/her code inside your browser.

The bottom line is: until Google security crew changes its mind and decides to rethink or remove this "feature", do not whitelist gmodules.com -- even better, mark gmodules.com as untrusted.
If you absolutely need scripts from the gmodules.com domain, e.g. to use those so called mapplets (another nifty Web 2.0 marvel), just "Temporarily allow" it and cross your fingers.

This entry was posted on Friday, August 17th, 2007 at 8:50 pm and is filed under Google, Security, NoScript. You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.

@xvcefj :gmodules.com and google.com, even being both Google domains and resolving to the same pool of hosts, do serve different content and deserve different levels of trust.
While gmodules.com serves user-generated content including scripts from perfect strangers, www.google.com serves (or should serve, pending other XSS vulnerabilities) only scripts from Google.

Maybe they're hosting it on a separate domain so that there is nothing to xss? Thats how browsers work dumbass, all web security is domain based. If I host my website ffdsokjfsld.com on the same host as you, I can put javascript on there. does that mean hackademix.net is vulnerable to xss? no. because that would be stupid.

@Tyokm:
This is XSS, because everybody (nice guys and evil criminals) can put their scripts in the very same domain with no check.
Moreover, they can change those scripts at any time, because they're served from their own sites but rendered in the gmodules.com context.

As you said, all web security domain based.
This means that I can decide to trust mozilla.org because I know they wouldn't do me any harm (or at least, they could do much more harm with their browser than their site) and decide I don't trust some b3stw4r3z.ru website because l33t sp33ch gives me severe headaches.
This is especially true for NoScript users, who don't want to execute a script unless they trust (or believe they can trust) its origin.

What should I do with gmodules.com then?
When you've got to decide if trusting a certain group of principals or not, the criterion must be "the group can be trusted as much as its least trustworthy member".
Since gmodules.com as a domain can deliver scripts from any party, even the evilest, nobody in its mind could ever trust it at all.

Even blogspot.com offers a different domain for each publisher, so I can choose to trust sirdarkcat.blogspot.com and distrust kuza55.blogspot.com (or the way around), though they're probably hosted on the same physical facility and definitely by the same service provider. Not a perfect solution, since to many users www.blogspot.com and www1.blogspot.com are the same site, but better than nothing.

So, coming to sirdarckcat's question, "is there any solution (from the Google side) for this?"
My answer is yes.
Other than providing an unique subdomain for each widget/module publisher (a la blogspot), which is probably quite inconvenient and not necessarily effective for the average user (see above), Google could:

Let publishers serve their widgets from their own hosting places (e.g. churchwidgets.com or flyingspaghettimodules.ru)

Provide publishers with a bootstrap API to be included his/her own domain, transforming the XML widget definition into HTML content when it's served.

Provide consumers (i.e. the sites which will embed the widgets/modules) with a script that creates the iframe and loads it with the widget's bootstrap script from its hosting location (much like AdSense works).

The "one domain/one trust choice" principle would be honored: I can decide to distrust churchwidgets.com and welcome flyingspaghettimodules.ru ;)
The only downside, other than a slightly more complex setup, is that "XSS by design" (i.e. different modules from different parties interacting -- or better said, hacking each other -- as they were the same application, inside the same domain) wouldn't obviously work, but this would be easily overcome if widgets wanting to be "mashed up" provide a JavaScript API to be included with a

@Matt:
thanks for the info, but as you said it doesn't help because you cannot reliable associate a trust principal with the domain name yet.
And we can easily modify RSnake's original PoC to demonstrate how we can inject our code in the 2nd level domain and in any of these pseudo-subdomains: