14 DAY TRIAL // More often than not, local Web pages on a user's computer can prove to be the means of a successful Internet attack. While the base of a browser's security model consists of the same-origin policy, meant to prevent websites from reading one another when, for example, they are loading at the same time, the problem is somehow different when it comes to a web page that loads from a local folder and not Internet.
A mailing site such as Gmail can basically do nothing to stop an attack from being successful if the attacker makes his move by sending the user a page to be downloaded on the local machine. On the other hand, any browser includes different security features meant to block in a way or another an attack conducted via the use of local web pages. An article published on The Chromium Blog describes how an attack could take place and also talks about the countermeasures browsers take to prevent it.
Such a potential attack would be based on a scenario that includes about six steps. A user could receive an email message from the attacker, with a web page attached, a page that the user then downloads and opens. The local web page creates an <iframe> which has https://mail.google.com/mail/ as its source, and it loads the messages in the inbox as the user is logged in to Gmail. By means of JavaScript, the page reads the content of the frame and then saves the contents of the user's inbox in a <textarea> that is sent to the attacker. The result is that the user's inbox in its entirety goes to the attacker, who can use it for spamming or other purposes.
Adam Barth, Software Engineer, states in the blog post that the development team for Google Chrome has studied attentively the security policies of other browsers in order to be able to design the best suitable one for their product. According to Barth, the security policy for local web pages Google Chrome features has been designed similarly to that of Opera. This way, the browser prevents users from clicking Internet-based hyperlinks to local web pages, while also not allowing local web pages to read the contents from random sites.
Chrome does not have the JavaScript disabled and an “infobar” override similar to that of Internet Explorer, says Barth. Most users would not be aware of the security implications re-enabling JavaScript would have, yet they would enable it just to make the pages work properly. Moreover, even those users who are aware of the consequences are willing to override the warning when locally developing web pages.
Choosing an access policy is not the only thing the security of local web pages implies, as users usually do not have a single browser installed on their computers. The Google Chrome team has also considered this situation, and has included in their application several security features to prevent attacks that could work through pages downloaded by Chrome and then opened with another browser. Chrome attaches to the downloaded pages a so-called “mark of the web.” Because of this, another browser, like Internet Explorer, for instance, sees these pages as on an “unknown” site, so they will not have access to pages on other Internet sites or to local file system, while still being able to run JavaScript.
If a user has another browser set as the default one, any page downloaded by Google Chrome would then be launched using the default browser. This means that the page would be able to read any other web page, bypassing its integrated security protection, and thus enabling an attack to be successful. The scenario is somehow possible in several browsers, yet the most vulnerable one in this case would be Safari. According to the blog post, Chrome now asks users for confirmation when a web page is downloaded, as it also does when it comes to executable files, a move aiming at minimizing the threat.
Barth also says that the general trend would be to further limit the privileges of the local web pages. The Chrome team has taken into consideration the implementation of directory-based restrictions, the way Firefox 3 has, or blocking the local pages from sending private data to Internet sites, as Maciej Stachowiak of the WebKit project suggested. According to the blog post, the team also hopes that the future would bring users “a uniform, secure policy for local web pages,” to which all browser vendors would adhere.