|
Brought to you by:
Suppliers of:
|
|
|
| |
| 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. |
| |
Credit:
The information has been provided by Yair Amit (Watchfire Research).
|
| |
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 victims 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.
|
| Subject:
|
I AM IN TROUBLE |
Date: |
26 Dec. 2005 |
| From: |
MACABEE |
With the vunerability identified in gmail, I wonder if someone is not using ma data for somethin sinister. I have always doubted the security of all webmail and this news has confirme that no webmail account is safe for use.
Well google bothers, I hope you fix the vunerabillty. |
|
| Subject:
|
interesant bug |
Date: |
15 Jan. 2006 |
| From: |
Guide_Shen |
| So interesant this bug, but how i can exploit this bug? |
|
|
|
|
|
|
