Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

   


   


   

















      :: Security-alerts
Security-Alerts mailing list archive (security-alerts@yandex-team.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[security-alerts] FW: XSS vulnerabilities in Google.com



> -----Original Message-----
> From: Watchfire Research [mailto:security-research@xxxxxxxxxxxxx] 
> Sent: Wednesday, December 21, 2005 4:06 PM
> To: bugtraq@xxxxxxxxxxxxxxxxx
> 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.
> 




 




Copyright © Lexa Software, 1996-2009.