bugtraq - XSS vulnerabilities in Google.com

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <0FF3BDA8C55900469FA6011BEFC06F4340CE57@2WFILEMAIL.israel.ottawa.watchfire.com>
Date: Wed, 21 Dec 2005 15:05:50 +0200
From: "Watchfire Research" <security-research@...chfire.com>
To: <bugtraq@...urityfocus.com>
Subject: XSS vulnerabilities in Google.com

//=====================>> Security Advisory <<=====================//

---------------------------------------------------------------------
XSS vulnerabilities in Google.com
---------------------------------------------------------------------

--[ Author: Yair Amit , Watchfire Corporation http://www.watchfire.com
--[ Discovery Date: 15/11/2005
--[ Initial Vendor Response: 15/11/2005
--[ Issue solved: 01/12/2005
--[ Website: www.google.com 
--[ Severity: High

--[ Summary

Two XSS vulnerabilities were identified in the Google.com website, 
which allow an attacker to impersonate legitimate members of Google's 
services or to mount a phishing attack.
Although Google uses common XSS countermeasures, a successful attack 
is possible, when using UTF-7 encoded payloads.

--[ Background

Google's URL redirection script
---------------------------------------------------------------------

The script (http://www.google.com/url?q=...) is normally used for 
redirecting the browser from Google's website to other sites.

For example, the following request will redirect the browser 
to http://www.watchfire.com :
	- http://www.google.com/url?q=http://www.watchfire.com 

When the parameter (q) is passed to the script with illegal format 
(The format seems to be: http://domain), a "403 Forbidden" page 
returns to the user, informing that the query was illegal. 
The parameter's value appears in the html returned to the user.

If http://www.google.com/url?q=USER_INPUT is requested, the text in 
the "403 Forbidden" response would be:
	- "Your client does not have permission to get URL 
	/url?q=USER_INPUT from this server."

The server response lacks charset encoding enforcement, such as:
* Response headers: "Content-Type: text/html; charset=[encoding]".
* Response body: "<meta http-equiv="Content-Type" (...)
charset=[encoding]/>".

Google's 404 NOT FOUND mechanism
---------------------------------------------------------------------

When requesting a page which doesn't exist under www.google.com, a 
404 NOT FOUND response is returned to the user, with the original 
path requested.

If http://www.google.com/NOTFOUND is requested, the following text 
appears in the response:
"Not Found
The requested URL /NOTFOUND was not found on this server."

The server response lacks charset encoding enforcement, such as:
* Response headers: "Content-Type: text/html; charset=[encoding]".
* Response body: "<meta http-equiv="Content-Type" (...)
charset=[encoding]/>".

--[ XSS vulnerabilities

While the aforementioned mechanisms (URL redirection script, 
404 NOT FOUND) escape common characters used for XSS, such as <> 
(triangular parenthesis) and apostrophes, it fails to handle 
hazardous UTF-7 encoded payloads.

Therefore, when sending an XSS attack payload, encoded in UTF-7, the 
payload will return in the response without being altered.

For the attack to succeed (script execution), the victim's browser 
should treat the XSS payload as UTF-7.

--[ IE charset encoding Auto-Selection

If 'Encoding' is set to 'Auto-Select', and Internet-Explorer finds a 
UTF-7 string in the first 4096 characters of the response's body, 
it will set the charset encoding to UTF-7 automatically, unless a 
certain charset encoding is already enforced. 

This automatic encoding selection feature makes it possible to mount 
UTF-7 XSS attacks on Google.com.

--[ Solution

Google solved the aforementioned issues at 01/12/2005, by using 
character encoding enforcement.

--[ Acknowledgement

The author would like to commend the Google Security Team for their 
cooperation and communication regarding this vulnerability.