Starting in 1996, Alexa Internet has been donating their crawl data to the Internet Archive. Flowing in every day, these data are added to the Wayback Machine after an embargo period.
Starting in 1996, Alexa Internet has been donating their crawl data to the Internet Archive. Flowing in every day, these data are added to the Wayback Machine after an embargo period.
TIMESTAMPS
The Wayback Machine - https://web.archive.org/web/20161013185217/http://www.securiteam.com:80/securitynews/6Z00L0AEUE.html
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.
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.
