Google - XSS 漏洞 - Google

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:

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

來源
http://ha.ckers.org/

測試
http://0rz.net/601y7

--