You receive an email message from an attacker containing a web page as an attachment, which you download.
You open the now-local web page in your browser.
The local web page creates an <iframe> whose source is https://mail.google.com/mail/.
Because you are logged in to Gmail, the frame loads the messages in your inbox.
The local web page reads the contents of the frame by using JavaScript to access frames[0].document.documentElement.innerHTML. (An Internet web page would not be able to perform this step because it would come from a non-Gmail origin; the same-origin policy would cause the read to fail.)
The local web page places the contents of your inbox into a <textarea> and submits the data via a form POST to the attacker's web server. Now the attacker has your inbox, which may be useful for spamming or identify theft.
There is nothing Gmail can do to defend itself from this attack. Accordingly, browsers prevent it by making various steps in the above scenario difficult or impossible. To design the best security policy for Google Chrome, we examined the security policies of a number of popular web browsers.
Safari 3.2. Local web pages in Safari 3.2 are powerful because they can read the contents of any web site (step 5 above succeeds). Safari protects its users by making it difficult for a web page from the Internet to navigate the browser to a local file (step 2 becomes harder). For example, if you click a hyperlink to a local file, Safari won't render the local web page. You have to manually type the file's URL into the location bar or otherwise open the file.
Internet Explorer 7. Like Safari 3.2, Internet Explorer 7 lets local web pages read arbitrary web sites, and stops web sites from providing hyperlinks to local files. Internet Explorer further mitigates local-file based attacks by stopping local web pages from running JavaScript by default (causing step 5 to fail). Internet Explorer lets users override this restriction by providing a yellow "infobar" that re-enables JavaScript.
Opera 9.6. Instead of letting local web pages read every web site, Opera 9.6 limits local web pages to reading pages in the local file system (step 5 fails because the <iframe>'s source is non-local). This policy mitigates the most serious attacks, but letting local web pages read local data can still be dangerous if your file system itself contains sensitive information. For example, if you prepare your tax return using your computer, your file system might contain last year's tax return. An attacker could use an attack like the one above to obtain this data.
Firefox 3. Like Opera, Firefox 3 blocks local web pages from reading Internet pages. Firefox further restricts a local web page to reading only files in the same directory, or a subdirectory. If you view a local web page stored in, say, a "Downloaded Files" directory, it won't be able to read files in "My Documents." Unfortunately, if the local web page is itself located in "My Documents", the page will be able to read your (possibly sensitive) documents.
When we designed Google Chrome's security policy for local web pages, we chose a design similar to that used by Opera. Google Chrome prevents users from clicking Internet-based hyperlinks to local web pages and blocks local web pages from reading the contents of arbitrary web sites. We chose not to disable JavaScript with an "infobar" override (like Internet Explorer) because most users do not understand the security implications of re-enabling JavaScript and simply re-enable it to make pages work correctly; even those that do understand frequently wish to override the warning, e.g. to develop web pages locally.
There is more to the security of local web pages than simply picking an access policy. A sizable number of users have more than one browser installed on their machine. In protecting our users, we also consider "blended" threats that involve more than one browser. For example, you might download a web page in Google Chrome and later open that page in Internet Explorer. To help secure this case, we attach the "mark of the web" to downloaded web pages. Internet Explorer then treats these pages as if they were on an "unknown" Internet site, which means they can run JavaScript but cannot access the local file system or pages on other Internet sites.
Other blended threats are also possible. Consider a user who uses Google Chrome but has Safari set as his or her default browser. When the user downloads a web page with Google Chrome, the page appears in the download tray at the bottom of the browser window. If the user clicks on the downloaded file, Google Chrome will launch the user's default browser (in this case Safari), and Safari will let the page read any web page, bypassing Safari's protections against step 2 in our hypothetical attack. Although this scenario is also possible in other browsers, downloading a file in those browsers requires more steps, making the vector less appealing to attackers. To mitigate this threat, we recently changed Google Chrome to require the user's confirmation when downloading web pages, just as we do for executable files.
In the future, we hope to further restrict the privileges of local web pages. We are considering several proposals, including implementing directory-based restrictions (similar to Firefox 3), or preventing local web pages from sending sensitive information back to Internet sites (blocking step 6 above), as proposed by Maciej Stachowiak of the WebKit project. Ultimately, we'd like to see all the browser vendors converge on a uniform, secure policy for local web pages.
