Cenzic 232 Patent
Paid Advertising
web application security lab

Cross Site Scripting Vulnerability in Google

Google is vulnerable to cross site scripting. While surfing around the personalization section of Google I ran accross the RSS feed addition tool which is vulnerable to XSS. The employees at Google were aware of XSS as they protected against it as an error condition, however if you input a valid URL (like my RSS feed) it will return with a JavaScript function containing the URL.

If you append the URL of the valid feed with a query string that contains your cross site scripting exploit Google will not sanitize it upon output of the JavaScript (it will upon screen render of the main page, but at that point it is too late). The JavaScript is not intended to be rendered directly, but that’s irrelevant, and can be exploited directly. Because this lives on the http://www.google.com/ domain it is not subject to cross domain policy restrictions that have typically protected Google from these attacks in the past.

Here is a screenshot of the vulnerability:

Cross Site Scripting Vulnerability in Google
(click to enlarge)

If you want to see the vulnerability for yourself click here (this is a benign proof of concept). As I said, this is using the query string from a valid feed to inject the vector. It doesn’t work if you inject it into the Add Content function on the page because the page itself sanitizes the output. Unfortunately for Google this can be intercepted far earlier than the page that does the eventual sanitization. One of the worst parts of this is that it does not require you to be logged in to exploit this cross site scripting vulnerability.

Additionally. in a few seconds of searching, I also found that Google has yet another URL redirection attack in it that can be used for phishing attacks located here (will redirect you to a benign site that demonstrates the attack). Google has been pretty notoriously slow at fixing these sorts of attacks in a timely manner (the last one that was actually being used by phishers was open for nearly a month), but they are really bad, because phishers can easily bounce their traffic off of these trusted domains. People are far more likely to click on a website that says www.google.com than they are to click on a site that says www.wellfsarg0.com or something equally obvious. I understand they are used for tracking purposes, but there are ways around this, like checking against whitelists, or checking against an embedded hash, etc. It’s processor intensive, but it protects the internet community.

Also in a few minutes of checking, id found a CSRF in Google (cross site request forgery) where malicious websites can change the default map search location. This is really not a big deal as far as I can tell besides annoying Google and it’s users, but it’s worth mentioning. Make sure you are logged into Google and then click on the following CSRF to change your default location to the whitehouse. Annoying, but I doubt there is a bigger hole here. The point is that Google definitely has not protected against CSRF, and I am sure there are additional vulnerabilities here that I have not played with since I only spent a few minutes looking at it.

So back to the cross site scripting vector, since that is by far the most dangerous. What are the implications of this attack for Google? Well, for starters, I can put a phishing site on Google. “Sign up for Google World Beta.” I can steal cookies to log in as the user in question, I can use the credentials of the user to screen scrape any of the content off of the www cname, including changing options like adding my RSS feed to your page, or deleting them, etc… I can steal your phone number from the /sendtophone application via an XML RPC (AJAX) call via a POST method, get your address because maps.google.com is mirrored on http://www.google.com/maphp?hl=en&tab=wl&q= etc… the list of potential vulnerabilities goes on and on. The vulnerabilities only grow as Google builds out their portal experience.

Indeed this also could have massive blackhat SEO (Search Engine Optimization) implications as Google sets itself as the authority in page rank (above other sites with more traffic). Its own page is set as a 10 in page rank. Trusting yourself could actually prove to be dangerous in this case, although this is a theoretical attack. Injecting your own links and getting engines to spider it could temporarily dramatically inflate page rank as /ig/ (where the vulnerable function is stored) is not disallowed by Google’s robots.txt file (again this is a theoretical attack and it is easy for Google to de-list violators).

Ultimately, Google cannot be trusted implicitly because of these types of holes, in the same way any major site cannot be trusted implicitly for the same reason. There are too many potential issues in their applications, and your information is definitely not 100% safe when entered there.

This will become particularly relevant at Jeremiah Grossman’s talk at Blackhat next month, where he starts to go into the real issues with cross site scripting, and how dangerous these forms of attack really can be (far beyond what is currently well known). Can you tell I’m excited? I don’t particularly blame Google, as all major websites are vulnerable to this, in my experience, it’s just that with a site’s popularity it becomes exponentially more dangerous and the responsibility to find these issues before the security community increases at the same rate.

24 Responses to “Cross Site Scripting Vulnerability in Google”

  1. kihong Says:

    http://www.google.com/ig/feeds?q=http://ha.ckers.org/blog/feed/?%3CSCRIPT%3Ealert%28document.cookie%29%3C/SCRIPT%3E&page=advdsrch

  2. The Turkey Curse Says:

    XSS- und CSRF-Probleme bei Google…

    Wie das ha.ckers Blog berichtet, findet sich bei Google unter anderem ein XSS-Problem im personalisierten Dienst (siehe Beispiel) und ein lustiges aber harmloses CSRF-Problem in der Suchfunktion von Google Maps (wozu man natürlich eingeloggt sein muss…

  3. Seth’s bl0g » Google.com: è XSS Says:

    […] QUI l’advisory su questa vuln 0-day. […]

  4. Clear Rivers Says:

    nice one:)

  5. perl programmer Says:

    It’s amazing how many sites are vulnerable to the XSS. If the page allows for XSS, phishers can inject their own remotely hosted version of a login page, using dhtml to dynamically change the action of the real google login page. I’ve seen this done on an auction site.

  6. RSnake Says:

    Just for the record, I should clarify… Google was not notified of this exploit prior to full disclosure. As I said, they are notoriously slow (or completely delinquent) in fixing these issues historically. If you need proof click here to see four redirect issues disclosed nearly 6 months ago that are still not fixed. Typically I don’t believe in full disclosure as a release methodology (for instance, if I found a remote vulnerability in Microsoft, I wouldn’t disclose that without giving Microsoft months to release a patch as they have taken their patching process very seriously as of late). However, it takes all but a few days to patch these issues in a website, and Google has not done so, making contacting the vendor a useless excersize to date. The clock is ticking, Google.

  7. shubham Says:

    hi,
    the article on vulnerabilities in google was awsome. I also tested it on my machine and could find some undesirable behaviour.
    I also wanted to know if could download windows XP sp2 from somewhere, that does not check the aunthenticity of the installed windows?
    can u suggest something?
    shubham

  8. blog.dennyroger.com.br » Página personalizada do Google tem falha de segurança, alerta Batori Says:

    […] O blog Ha.ckers.org, responsável pelo alerta original, afirma que o Google já foi avisado sobre a brecha e criou um teste online para exemplificar como a vulnerabilidade funciona especificamente dentro do Google IG. […]

  9. A Moment Of Peace Says:

    Digest - 2006-07-06…

    Cross Site Scripting Vulnerability in Google- http://ha.ckers.org/blog/20060704/cross-site-scripting-vulnerability-in-google/…

  10. RSnake Says:

    When I saw this, I burst out laughing. Pretty funny: all your base are belong to Google

    Meanwhile, let’s invent another fun game. What you say? The Google drinking game:

    Rules: Every time you hear someone say or see someone type the word “Google” everyone takes a drink. For those in need of being really belligerent, you can add in “Gmail” and “Orkut” and any other Google owned web properties too. You’d be surprised how often the word is used. Get your drink of choice and gather round. Let the drinking begin! Try it at your next conference, or corporate dinner party. :) It’s sure to please!

  11. rJonesX Says:

    There are actually quite a few of these aside from the one you pointed out. It is a great PR10 :)

  12. RSnake Says:

    As of 8:50PM July 5th (23 hrs later) the XSS hole appears to be fixed. The redirection hole remains (no surprise there since these are much harder to fix).

  13. Nightrider Says:

    It seems to be Google still dind’t correct the bug. You can also enter other sites using Google’s redirection.

  14. Jackson Says:

    This is awesome - you totally deserve the fox for your cubicle!

  15. ha.ckers.org web application security lab - Archive » XSS Scanning Says:

    […] The first is “Anything that looks like HTML is probably bad.” If you assume that any HTML injection is bad, you are making false assumptions about what is deemed acceptable by that application. Maybe <BR> tags are okay, or even <XSS> tags are okay, but <IFRAME is not programmatically. Secondly, making that same assumption if you are only testing for HTML (because it would stand to reason that HTML is the only way to get JavaScript on a page) you are missing script injection (like the JSON issue Google had), weird encoding methods, blah blah blah. Also maybe they use a whitelist like <XSS> isn’t allowed since it’s not on a whitelist, but <IMG SRC=… is. Eesh! As I said, it makes me wince. […]

  16. kishor Says:

    Did anyone notice this one? It was very obvious one.

    http://wasjournal.blogspot.com/2006/10/orkut-xss-silently-fixed-www.html

  17. Software as Art! » Web Application Security Says:

    […] Web application security现在(2006年)在国内还是一个很“脆弱”的话题,说它脆弱是因为对它重视或者探索的不够。今年7月就有人利用javascript注入在hi.baidu上发现安全漏洞,同样Gmail里面也发现XSS安全问题。 […]

  18. sysghost Says:

    Well it was nice that one of us have a weggie to hem so that they take it more seariously

  19. Bally Says:

    Google is for sure vulnerable. But I think pay pal and other payment site are too. With the internet explorer frame codes and false email id’s.

  20. mp3ler Says:

    hi,
    the article on vulnerabilities in google was awsome. I also tested it on my machine and could find some undesirable behaviour.
    I also wanted to know if could download windows XP sp2 from somewhere, that does not check the aunthenticity of the installed windows?
    can u suggest something?
    shubham

  21. Meteko Says:

    This is an interesting article, i have long thought that google as an internet giant will never have this type of vulnerability as they have employed all the top programmer paying them high salaries to do the job. This article have proven me wrong. Are their programmer sleeping on their job or are they busy counting their revenue?

  22. Tercme brosu Says:

    There are actually quite a few of these aside from the one you pointed out..

  23. Billigflug Says:

    Hey guys,

    I like to say “Thank you”, you did a great job! I read this text very carefully and de facto I agree with your argumentation!
    There are many negative aspects which are not considered by Google!

    It is very easy- even for an amateur- Hacker to infiltrate your system and you have no chance to take a notice of it!
    I recommend to install the new version of Norton or something like that, although you`ll never have 100% securiuty!

    At least I just wanted to say to you, that this text is awesome :-)

  24. brain_damaged! Says:

    Hi! I’m new at hacking, can someone give me xss code(that steals passwords or whatever)
    its urgent