Google Chrome and the 404
Thursday September 4, 2008 at 5:49 am CST
Posted by Tad Heppner
One of the features included with Google’s new Chrome web browser is the ability to show suggestions for navigation errors. This feature is intended to replace certain traditional 404 error messages with the additional option to search Google’s web search engine for phrases that are parsed out of the incorrectly entered web address that returned the 404 message.
In the past an issue with this has brought to light when a similar technology was first introduced with the Google Toolbar 5 browser plug-in.
The HTTP method GET is frequently used to pass form data from one page to the next for further processing. When using the GET method this data is appended to the URL delimited by a preceding question mark character.
Ex..
http:// [somewebsite] /accountinfo.php?user=Jdoe&session=12345678
In the above example accountinfo.php would be passed the parameter USER containing a value of JDOE as well as a parameter SESSION containing a value of 12345678.
To help explain some of the privacy concerns that may be associated with a 404 hijack lets take a scenario in which a web server is undergoing maintenance and a URL that normally would display a valid web document is returning a 404 error.
In this case a user is logged into [somewebsite] as user jdoe with a session ID of 12345678. After logging in the user selects the account information option on [somewebsite] and is directed to http:// [somewebsite] /accountinfo.php?user=Jdoe&session=12345678
In this example [somewebsite] is under maintenance and the server hosting the accountinfo.php document is generating a 404 message.
The Chrome browser instead of displaying the 404 message generated by [somewebsite] will display a custom error that contain links to search links that redirect to Google’s web search.

A side effect of hijacking the original 404 while maintaining the original URL is that if any of these links that are clicked or when the search button is pressed the browser will send the above mentioned data (USER containing a value of JDOE as well as a parameter SESSION containing a value of 12345678) to google.com as part of the referrer field of the HTTP headers of the created query.
In this case the user may not have intended or be fully aware that the user and session values are transmitted to Google’s servers.
>>>>>>>>>>>>>>>>>>>>>>>>>Update Sept 4, 2008<<<<<<<<<<<<<<<<<<<<<<<<<<<
It has been reported by one of our fellow McAfee researchers that when the Google 404 page is initially rendered an image file is requested from Google (exact path may very depending on localized build of Chrome). This http request also contains the referrer value referenced in the initial post. The result of this discovery is that no action is actually required from the end user for the information to be sent to Google. By the time the Goggle 404 page is displayed the information has already been transferred to Google.

September 4th, 2008 at 13:27
It has been reported by one of our fellow McAfee researchers that when the Google 404 page is initially rendered an image file is requested from the Google http://www.google.com/chrome/intl/en/images/logo_sm.jpg (exact path may very depending on localized build of Chrome). This http request also contains the referrer value referenced in the initial post. The result of this discovery is that no action is actually required from the end user for the information to be sent to Google. By the time the Goggle 404 page is displayed the information has already been transferred to Google.