Today RSnake revealed a cross site scripting vulnerability affecting Google Gadgets in the 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 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 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 -- even better, mark as untrusted.
If you absolutely need scripts from the domain, e.g. to use those so called mapplets (another nifty Web 2.0 marvel), just "Temporarily allow" it and cross your fingers.

On a side note, U.N. site is still vulnerable to defacement...

11 Responses to “Don't Trust Google's XSSploding Gadgets”

  1. #1 xvcefj says: resolves to
    how then do we mark gmodules as a NoScript untrusted site without having to do the same to the entire google domain?


  2. #2 Giorgio says:

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

  3. #3 Aerik says:

    @xvcefj :

    Go to about:config, enter noscript.untrusted and add to the end of it yourself.

  4. #4 sirdarckcat says:

    The following sites use scripts:

    -> Google Pages (
    -> Google Desktop (
    -> iGoogle (

    Any way, is there any solution (from the Google side) for this?
    I mean, I can't think a way Google can enable users to create their own modules if it's not this way..

    I think that as a "Phishing" attack, there's a more dangerous vector using,,, domains..

    Any way, this "feature" can work extremely easy as a "defacement" attack against iGoogle, or Google Pages, and as a DoS to the SO, if you use Google Desktop.

    1.- Don't use gadgets with Google desktop.
    2.- Don't use gadgets with Google pages.
    3.- Don't use gadgets with iGoogle.
    4.- Don't use gadgets at all :P

    The second and third point can be avoided using NoScript, but the first one.. well.. Google Desktop is just evil.


  5. #5 Tyokm says:

    Lamest. Hack. Ever.

    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 on the same host as you, I can put javascript on there. does that mean is vulnerable to xss? no. because that would be stupid.

  6. #6 ·¨-=[WHK]=-¨· » Archive » Los “gadgets” de Google como herramienta de “phishing” says:

    [...] Don’t Trust Google’s XSSploding Gadgets [Giorgio Maone]. [...]

  7. #7 Giorgio says:

    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 context.

    As you said, all web security domain based.
    This means that I can decide to trust 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 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 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 as a domain can deliver scripts from any party, even the evilest, nobody in its mind could ever trust it at all.

    Even offers a different domain for each publisher, so I can choose to trust and distrust (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 and 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:

    1. Let publishers serve their widgets from their own hosting places (e.g. or
    2. 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.
    3. 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 and welcome ;)
    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


    tag, which is however the cleanest way to do that.

  8. #8 Matt says:

    Actually, Google does provide a unique subdomain for many, if not all, of the modules. When I opened up Noscript while on iGoogle, I saw a lot of "", "", etc.

    Not overly helpful- I have no idea which module is coming from "", and it would take a lot more trial and error than I have patience for to figure it out.

  9. #9 Giorgio says:

    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:

  10. #10 Los “gadgets” de Google como herramienta de “phishing” « says:

    [...] Don’t Trust Google’s XSSploding Gadgets [Giorgio Maone]. [...]

  11. #11 Shadow Security Blog » Blog Archive » Los “gadgets” de Google como herramienta de “phishing” says:

    [...] Don’t Trust Google’s XSSploding Gadgets [Giorgio Maone]. [...]

Bad Behavior has blocked 972 access attempts in the last 7 days.