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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed Dec 21 12:58:21 2005
From: security-research at watchfire.com (Watchfire Research)
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.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051221/fa702bcd/attachment.html
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: google_xss_211205.txt
Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051221/fa702bcd/google_xss_211205.txt

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ