Changing the security model for "chrome" URLs

[Adam Barth]

Hi chromium-dev,

If you don't work on DOMUI in Chrome, please feel free to skip this message.

Several folks have asked if we can change the security model for
"chrome" URLs, such as chrome://newtab/. Currently, these pages are
pretty locked-down from a security point of view. They've effectively
sandboxed so that an XSS vulnerability in one page cannot spread to
other DOMUI pages or to the web. Unfortunately, this tight security
policy is a headache for folks who author these pages. As an example,
the new HTML settings page can't use pushState to create elegant URLs
in the omnibox because pushState has a security check in it and DOMUI
pages fail all security checks.

I'm working on a change to adjust the security model of these pages to
let them use features like pushState while retaining most of the
mitigations we have now. If you've authored or plan to author a DOMUI
page, I'm interested in your feedback on this page to make sure this
change meets your needs. Here's the plan:

1) "chrome" URLs will be able to access other "chrome" URLs that have
the same "host", much like how http URLs work. For example,
chrome://newtab/foo will be able to access chrome://newtab/bar but
will not be able to access chrome://history/foo. (Currently, we block
"chrome" URLs from accessing anything.)

2) "chrome" URLs will no longer be able to display "file" URLs.
Currently, chrome://newtab/ can create an iframe to
file:///etc/passwd. We originally enabled this feature so that the
New Tab Page can have hyperlinks to file URLs, but it turns out the
New Tab Page already needs a fancier way to link to pages to handle
"about" URLs properly. Rather than having "about" URLs be a special
case, we're going to lump "file" URLs and "about" URLs together.

3) No non-"chrome" URLs will be not be able to display "chrome" URLs.
We already prevent almost all pages from iframing/linking to "chrome"
URLs, but we miss a few edge cases. After this change, we should nail
all the edge cases.

This design aims to make "chrome" URLs more like regular web URLs.
The only difference is that "chrome" URLs will have restrictions on
who can display them (load them in iframes, hyperlink to them, etc).

Let me know if that doesn't work for you.

Thanks!
Adam

[Brett Wilson]

Sounds good to me.

Brett

[Chris Masone]

On Mon, Nov 29, 2010 at 9:28 AM, Adam Barth <aba...@chromium.org> wrote:

Can http:// URLs redirect to them in any way?

 

This design aims to make "chrome" URLs more like regular web URLs.
The only difference is that "chrome" URLs will have restrictions on
who can display them (load them in iframes, hyperlink to them, etc).

Let me know if that doesn't work for you.

Thanks!
Adam

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
   http://groups.google.com/a/chromium.org/group/chromium-dev

[Adam Barth]

Nope. More precisely, if they can, it's a bug.

Adam

[Chris Silverberg]

Sounds good to me (dom-ui settings).

[Zelidrag Hornung]

Adam,

I surely welcome change 1), but we have couple of scenarios on ChromeOS side that could end up broken:

2) Cellular modem activation page (chrome://mobilesetup) displays an iframe that is hosted from file:/// schema. We might have similar issues with pages hosted from partner/OEM partition (i.e. product registration). The same page also contains another iframe served from http: schema.

3) Would we be able to host an http schema based iframe within chrome: page? We have couple of places where this is used in ChromeOS right now. These pages also rely on HTTP5 messaging mechanism functioning between them.

On Mon, Nov 29, 2010 at 9:28 AM, Adam Barth <aba...@chromium.org> wrote:

[Adam Barth]

On Tue, Nov 30, 2010 at 11:38 AM, Zelidrag Hornung
<zeli...@chromium.org> wrote:
> Adam,
> I surely welcome change 1), but we have couple of scenarios on ChromeOS side
> that could end up broken:
> 2) Cellular modem activation page (chrome://mobilesetup) displays an iframe
> that is hosted from file:/// schema. We might have similar issues with pages
> hosted from partner/OEM partition (i.e. product registration). The same page
> also contains another iframe served from http: schema.

I understand that the security considerations for ChromeOS are
different, but I'm inclined to say that you should find another
solution rather than having an iframe to a file URL. IMHO, ChromeOS
would be better off if it disabled file URLs entirely.

Iframing an http URL from a chrome URL is almost certainly a bad idea.
What happens if there's a network attacker? What happens if the
frame tries to framebust? How does the user tell the difference
between trusted browser UI and untrusted UI from the network?

> 3) Would we be able to host an http schema based iframe within chrome: page?

You will be able to, but I suspect it's not a good idea. Why not use
CORS instead? That's much safer because you know that what you
receive from the network is just data.

> We have couple of places where this is used in ChromeOS right now. These
> pages also rely on HTTP5 messaging mechanism functioning between them.

What is HTTP5?

Adam

[Zelidrag Hornung]

inline:

On Tue, Nov 30, 2010 at 1:01 PM, Adam Barth <aba...@chromium.org> wrote:

On Tue, Nov 30, 2010 at 11:38 AM, Zelidrag Hornung
<zeli...@chromium.org> wrote:
> Adam,
> I surely welcome change 1), but we have couple of scenarios on ChromeOS side
> that could end up broken:
> 2) Cellular modem activation page (chrome://mobilesetup) displays an iframe
> that is hosted from file:/// schema. We might have similar issues with pages
> hosted from partner/OEM partition (i.e. product registration). The same page
> also contains another iframe served from http: schema.

I understand that the security considerations for ChromeOS are
different, but I'm inclined to say that you should find another
solution rather than having an iframe to a file URL.  IMHO, ChromeOS
would be better off if it disabled file URLs entirely.

file: schema is already severely limited to only few folders on ChromeOS. We won't be able to completely shut it down yet, but eventually I hope that we will. We could potentially expose access to the assets though a special data source. It would be surely an extra work for us, but what the heck.

 

Iframing an http URL from a chrome URL is almost certainly a bad idea.
 What happens if there's a network attacker?  What happens if the
frame tries to framebust?  How does the user tell the difference
between trusted browser UI and untrusted UI from the network?

The scenarios that we have require interaction between ChromeOS and predefined external entities (web sites for google product registration, cellular plan activation portal). We need to pass information between the browser process and such pages in both directions. This is achieved through a wrapper chrome: page that is used as a proxy between such sites and the native ChromeOS-specific code in the browser process. Such pages expose a predefined API which uses HTML5 messaging to send data:

   browser <---> chrome: wrapper page <---> targeted site

Such UI surfaces should be wrapped in a non-tab elements (i.e. popup HTML dialog), so users won't even see their URLs and would be perceiving them as part of ChromeOS not some random web locations.

 

> 3) Would we be able to host an http schema based iframe within chrome: page?

You will be able to, but I suspect it's not a good idea.  Why not use
CORS instead?  That's much safer because you know that what you
receive from the network is just data.

> We have couple of places where this is used in ChromeOS right now. These
> pages also rely on HTTP5 messaging mechanism functioning between them.

What is HTTP5?

I meant to say HTML5 messaging. 

[Adam Barth]

On Tue, Nov 30, 2010 at 4:04 PM, Zelidrag Hornung <zeli...@chromium.org> wrote:
> inline:
> On Tue, Nov 30, 2010 at 1:01 PM, Adam Barth <aba...@chromium.org> wrote:
>> On Tue, Nov 30, 2010 at 11:38 AM, Zelidrag Hornung
>> <zeli...@chromium.org> wrote:
>> > Adam,
>> > I surely welcome change 1), but we have couple of scenarios on ChromeOS
>> > side
>> > that could end up broken:
>> > 2) Cellular modem activation page (chrome://mobilesetup) displays an
>> > iframe
>> > that is hosted from file:/// schema. We might have similar issues with
>> > pages
>> > hosted from partner/OEM partition (i.e. product registration). The same
>> > page
>> > also contains another iframe served from http: schema.
>>
>> I understand that the security considerations for ChromeOS are
>> different, but I'm inclined to say that you should find another
>> solution rather than having an iframe to a file URL.  IMHO, ChromeOS
>> would be better off if it disabled file URLs entirely.
>
> file: schema is already severely limited to only few folders on ChromeOS. We
> won't be able to completely shut it down yet, but eventually I hope that we
> will. We could potentially expose access to the assets though a special data
> source. It would be surely an extra work for us, but what the heck.

That's what we do on other platforms.

>> Iframing an http URL from a chrome URL is almost certainly a bad idea.
>>  What happens if there's a network attacker?  What happens if the
>> frame tries to framebust?  How does the user tell the difference
>> between trusted browser UI and untrusted UI from the network?
>
> The scenarios that we have require interaction between ChromeOS and
> predefined external entities (web sites for google product registration,
> cellular plan activation portal). We need to pass information between the
> browser process and such pages in both directions. This is achieved through
> a wrapper chrome: page that is used as a proxy between such sites and the
> native ChromeOS-specific code in the browser process. Such pages expose a
> predefined API which uses HTML5 messaging to send data:
>
>    browser <---> chrome: wrapper page <---> targeted site
> Such UI surfaces should be wrapped in a non-tab elements (i.e. popup HTML
> dialog), so users won't even see their URLs and would be perceiving them as
> part of ChromeOS not some random web locations.

That's even worse. If the content framebusts, the attacker gets to
control UI surfaces that look like native browser UI and not like a
web page.

>> > 3) Would we be able to host an http schema based iframe within chrome:
>> > page?
>>
>> You will be able to, but I suspect it's not a good idea.  Why not use
>> CORS instead?  That's much safer because you know that what you
>> receive from the network is just data.
>>
>> > We have couple of places where this is used in ChromeOS right now. These
>> > pages also rely on HTTP5 messaging mechanism functioning between them.
>>
>> What is HTTP5?
>
> I meant to say HTML5 messaging.

Ah. It seems better to use CORS so that your interaction with
untrusted content is limited to data only. If we need to show web
content to the user, we should use some sort of UI element with an
address bar (either a tab or a popup window). That's how the user
knows that this UI comes from the network.

[Lei Zhang]

Can you file a bug to track the progress of this change?

On Mon, Nov 29, 2010 at 9:28 AM, Adam Barth <aba...@chromium.org> wrote: