# Cookies versus the Chrome sandbox

DevFeed: [Cookies versus the Chrome sandbox](<https://devfeed.tech/articles/cookies-versus-the-chrome-sandbox-21559.md>)

Original publisher: [Read original article](<http://lackingrhoticity.blogspot.com/2011/02/cookies-versus-chrome-sandbox.html>)

Author: Mark Seaborn (noreply@blogger.com)

Published: 2011-02-10T01:34:00Z

Content type: article

Language: en

Sources: [Mark Seaborn](<https://devfeed.tech/sources/mark-seaborn.md>)

Topics: [Chrome](<https://devfeed.tech/topics/chrome.md>), [browser](<https://devfeed.tech/topics/browser.md>), [vulnerability](<https://devfeed.tech/topics/vulnerability.md>), [Exploit](<https://devfeed.tech/topics/exploit.md>), [HTML](<https://devfeed.tech/topics/html.md>)

Tags: [browser](<https://devfeed.tech/tags/browser.md>), [chrome](<https://devfeed.tech/tags/chrome.md>), [cookies](<https://devfeed.tech/tags/cookies.md>), [exploit](<https://devfeed.tech/tags/exploit.md>), [html](<https://devfeed.tech/tags/html.md>), [sandbox](<https://devfeed.tech/tags/sandbox.md>)

## AI overview

The article examines how a Chrome renderer-process vulnerability could allow a malicious site to access login cookies from another site through the interaction of cookies and framed pages. It explains that Chrome's sandbox offers limited cross-site protection in this scenario and discusses mitigation through separate browser profiles or avoiding cookies.

## Source excerpt

Although Chrome's sandbox does not protect one web site from another in general, it can provide such protection in some cases. Those cases are ones in which HTTP cookies are either reduced in scope or not used at all. One lesson we could draw from this is that cookies reduce the usefulness of Chrome's sandbox. The scenario we are exploring supposes that there is a vulnerability in Chrome's renderer process, and that the vulnerability lets a malicious site take control of the renderer process. This means that all the restrictions that are normally enforced on the malicious site by the renderer process are stripped away, and all we are left with are the restrictions enforced on the renderer process by the Chrome browser process and the Chrome sandbox. In my previous blog post, I explained how an attacker site, evil.com, that manages to exploit the renderer process could steal the login cookies from another site, mail.com, and so gain access to the user's e-mail. The attack is made possible by the combination of two features: cookies frames Chrome currently runs a framed page in the same renderer process as the parent page. HTML standards allow framed pages to access cookies, so the browser process has to give the renderer process access to the cookies for both pages. Because this problem arises from the interaction of these features, one site is not always vulnerable to other sites. There should be a couple of ways that users and sites can mitigate the problem, without changing Chrome. Firstly, the user can change how cookies are scoped within the browser by setting up multiple profiles. Secondly, a site can skirt around the problem by not using cookies at all. We discuss these possibilities below. Use multiple profiles: As a user, you can create multiple browser profiles, and access mail.com and evil.com in separate profiles. Chrome does not make this very easy at the moment. It provides a command line option (--user-data-dir) for creating more profiles, but this fea