CSP 1.0 changes will block inline styles in certified apps

[Paul Theriault]

(bcc dev-b2g)

TLDR: Not urgent, but in certified apps, we need to move away from <style> tags or style attributes in HTML since these will be blocked once we have a CSP 1.0 compliant implementation on Firefox OS.

The currently CSP implementation on b2g18 does not block inline styles in certified even though the default policy says it does [1]. This is since our old CSP implementation did not support inline style blocking, but changes landing in FF21 will bring our CSP parser into line with the 1.0 spec (bug 783049). The old CSP parser will remain in the codebase, and only be turned on in Firefox OS based on a preference value (bug 858787) - and obviously only once we actually take this code into a release. So its not urgent, but I wanted gaia devs to be aware this change is coming, because currently a quick glance at the certified apps in Gaia shows that they will break with this restriction. No inline styles means:

- No <style> tags in HTML: http://mxr.mozilla.org/mozilla-central/gaia/search?string=%3Cstyle%3E&find=.html&findi=&filter=^[^\0]*%24&hitlimit=&tree=gaia
- No style attributes on elements: http://mxr.mozilla.org/mozilla-central/gaia/search?string=style%3D&find=.html&findi=&filter=^[^\0]*%24&hitlimit=&tree=gaia

So all styles need to be in CSS files, and all style changes done by manipulating the element.style in script, not by injecting style tags or attributes into HTML.

Any concerns, questions etc, please raise them.

- Paul

[1] https://developer.mozilla.org/en-US/docs/Apps/CSP#Default_Policies

[Andrew Sutherland]

On 04/07/2013 08:31 PM, Paul Theriault wrote:
> Any concerns, questions etc, please raise them.

This is known to you, but for completeness and the benefit of everyone,
the e-mail app's current HTML mail sanitization strategy is not
compatible with this change. The sanitized HTML e-mail messages live in
an iframe in our origin so that we can listen for click events and
manipulate the HTML to 'activate' remote images and embedded images (via
window.URL.createObjectURL) and thus is subject to our CSP.

A workaround of causing the document to properly live in its own origin
is possible, but will require activating script in the iframe so that we
can communicate with it. As long as we are able to use CSP to constrain
JS to our code provided for this purpose in the iframe, this will not
result in a loss of protection.

The ideal solution, from discussion with security people, is to allow
iframe sandboxes to effectively provide an nsIContentPolicy that allows
us to disable remote content fetches so we can stop having to sanitize
our HTML to accomplish the same result. No bug has been filed on this
at this time, nor standardization effort undertaken, although it would
be great for us to get the ball rolling. I assume the most important
part is to come up with a proposal that could actually get standardized
and is broadly applicable.

Andrew

[Tim Chien]

<style> tag was added in the System app to prevent FOUT. Not being able to
do that will hurt start-up experience of apps. Not a big deal though.

> Any concerns, questions etc, please raise them.
>

> - Paul
>
> [1] https://developer.mozilla.org/en-US/docs/Apps/CSP#Default_Policies

> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
>
>


--
Tim Guan-tin Chien, Senior Front-end Dev., Mozilla Corp. (Taiwan)

[Ismael González]

Cristian may correct me but homescreen will not work with this policy, as you can't write an element.style to insert the touch coordinates to move it. There is no way to do it via external CSS file.

--Ismael González / @basiclines

> > dev-...@lists.mozilla.org (mailto:dev-...@lists.mozilla.org)

> > https://lists.mozilla.org/listinfo/dev-gaia
> >
>
>
>
> --
> Tim Guan-tin Chien, Senior Front-end Dev., Mozilla Corp. (Taiwan)
> _______________________________________________
> dev-gaia mailing list

> dev-...@lists.mozilla.org (mailto:dev-...@lists.mozilla.org)
> https://lists.mozilla.org/listinfo/dev-gaia
>
>

[Ismael González]

Forget about my last comment, i've misunderstood some explanations :D

--Ismael González / @basiclines

[Donovan Preston]

On 4/7/13 9:35 PM, Andrew Sutherland wrote:
> The ideal solution, from discussion with security people, is to allow
> iframe sandboxes to effectively provide an nsIContentPolicy that
> allows us to disable remote content fetches so we can stop having to
> sanitize our HTML to accomplish the same result.

I just want to say that this would be extremely useful for many use
cases and I would love to see this happen.

Donovan

[Lucas Adamski]

Direct remote content loading is unfortunately not the only attack vector. Lots of XSS are laundered via some intermediate storage. So you'd have to have a sandbox to prevents loading of all external (to page) data, which is fairly useless.
Lucas.

[Donovan Preston]

Hmm. That seems pretty useful to me. Why do you think it is useless?

D

[Lucas Adamski]

Well, because if you already have a page that never loads any potentially tainted external data (via network or indirectly via db, localstorage, cookies, web activities, etc.) then its impervious to XSS. :)

Unless our clock app loads stuff from the network or consumes web activities, I don't really lose sleep about enforcing CSP on it (beyond maybe future-proofing).
Lucas.

[Donovan Preston]

Sure. But aren't we talking about sandboxing arbitrary code that may try
to load external content over the network or one of the local external
sources you mention, but then denying access to that external content?

What I was saying would be useful would be to have a sandbox that I
could toss arbitrary html into, and that would deny access to any
external anything that it tried to load, including the local external
sources you mentioned.

D

[Lucas Adamski]

Maybe I'm confused about the specific use-case here. Sounds to me like you're talking about scenarios for iframe sandbox: http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/
Lucas.

[Donovan Preston]

Thanks a lot for the link. I was aware that something like this existed,
but wasn't sure of the details. I'm pretty sure it's what I was wanting.

D

[Donovan Preston]

While the iframe sandbox is very close to what I want, after researching
it and testing, it appears that it does not prevent external images from
loading (needed to prevent web bugs which spammers may use to know
whether you looked at an email)

Also, it may be interesting to have a sandbox which allows running
scripts but does not allow those scripts to do things which access
network resources or the local data sources that you mentioned.

(The use case is sanitizing html embedded in email)

[Jonas Sicking]

I think we should simply add "style-src: inline" to the default policy for
privileged and certified apps.

I think creating a CSP rule which prevents use of innerHTML would be a more
effective protection mechanism than forbidding all inline style.

/ Jonas

> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
>
>

[Ian Melven]

Hi,

style-src: unsafe-inline to be pedantic ;)

which innerHTML threats are we particularly worried about ? arbitrary element injection ? inline scripts via injecting <script> tags, setting event handlers, etc.
_should_ still be blocked by a CSP that prevents inline scripting. Restricting use of <base> has also been brought up as
something CSP 1.1 should do.

i do think your 'block innerHTML' CSP directive idea is worth exploring though - that's why i want to understand exactly what we'd be
addressing via it.

thanks,
ian

[Jonas Sicking]

On Mon, Apr 29, 2013 at 1:24 PM, Ian Melven <ime...@mozilla.com> wrote:
>
> Hi,
>
> style-src: unsafe-inline to be pedantic ;)

Yes, thanks.

> which innerHTML threats are we particularly worried about ? arbitrary element injection ? inline scripts via injecting <script> tags, setting event handlers, etc.
> _should_ still be blocked by a CSP that prevents inline scripting. Restricting use of <base> has also been brought up as
> something CSP 1.1 should do.

Oooh, base is a really good point. I wonder if that should be disabled
by default even. It seems very scary. Especially considering how
rarely it is used on modern web pages, the reward/risk ratio of
disabling it by default seems very good.

> i do think your 'block innerHTML' CSP directive idea is worth exploring though - that's why i want to understand exactly what we'd be
> addressing via it.

Mostly as a defense-in-depth mechanism. Basically it seems like using
innerHTML to inject content into a page will commonly be part of an
attack that uses multiple weaknesses or bugs in order to cause XSS or
other privilege escalation.

I.e. if we have a bug in our script blocking code, or in our CSS
src-limiting code, then it seems like using innerHTML would be a good
way to exploit that.

Another scenario could be a DoS because an injected <div
class="submitButton"> lays out on top of the real submit button
because there's a CSS rule om a stylesheet that uses a .submitButton
selector to position elements.

And even something trivial as making the SMS app look ugly by sending
a text message with "<b>text here</b>".

During gaia development we found several accidental uses of .innerHTML
which resulted in various degrees of harm to the user. But no (or
almost no) "correct" uses of .innerHTML. So the risk of having the
feature enabled very heavily outweighed the value we got out of it.

/ Jonas

[Julien Wajsberg]

Le 30/04/2013 03:46, Jonas Sicking a écrit :
>
>> i do think your 'block innerHTML' CSP directive idea is worth exploring though - that's why i want to understand exactly what we'd be
>> addressing via it.
> Mostly as a defense-in-depth mechanism. Basically it seems like using
> innerHTML to inject content into a page will commonly be part of an
> attack that uses multiple weaknesses or bugs in order to cause XSS or
> other privilege escalation.
>
> I.e. if we have a bug in our script blocking code, or in our CSS
> src-limiting code, then it seems like using innerHTML would be a good
> way to exploit that.
>
> Another scenario could be a DoS because an injected <div
> class="submitButton"> lays out on top of the real submit button
> because there's a CSS rule om a stylesheet that uses a .submitButton
> selector to position elements.
>
> And even something trivial as making the SMS app look ugly by sending
> a text message with "<b>text here</b>".
>
> During gaia development we found several accidental uses of .innerHTML
> which resulted in various degrees of harm to the user. But no (or
> almost no) "correct" uses of .innerHTML. So the risk of having the
> feature enabled very heavily outweighed the value we got out of it.
>

If the values injected are correctly and systematically sanitized, there
is really no harm in using innerHTML. That's why in the SMS app we
recently started a small tested templating micro-library that sanitize
all inputs by default. Ideally all innerHTML uses should be done through
this micro-library, which makes it easier to audit (because I obviously
agree that all uses of innerHTML should be audited).

Disabling innerHTML is imho a false good idea. Even if I like the idea
of defense-in-depth, and if I agree that all uses of innerHTML should be
reviewed and removed if it's not necessary.

--
Julien

[Fabrice Desre]

On 04/30/2013 06:49 AM, Julien Wajsberg wrote:

>
> If the values injected are correctly and systematically sanitized, there
> is really no harm in using innerHTML. That's why in the SMS app we
> recently started a small tested templating micro-library that sanitize
> all inputs by default. Ideally all innerHTML uses should be done through
> this micro-library, which makes it easier to audit (because I obviously
> agree that all uses of innerHTML should be audited).
>
> Disabling innerHTML is imho a false good idea. Even if I like the idea
> of defense-in-depth, and if I agree that all uses of innerHTML should be
> reviewed and removed if it's not necessary.

Using innerHTML in Gaia may be ok, but I would not expect all 3rd party
apps to be that safe.

Fabrice
--
Fabrice Desr�
b2g team
Mozilla Corporation

[Ian Melven]

re sanitization, the general opinion of the security folks I've spoken to here is that
it's quite difficult to get right in _all_ cases.

relevant to this thread : http://www.slideshare.net/x00mario/the-innerhtml-apocalypse

cheers,
ian

----- Original Message -----
From: "Julien Wajsberg" <jwaj...@mozilla.com>
To: "Jonas Sicking" <jo...@sicking.cc>
Cc: "Ian Melven" <ime...@mozilla.com>, dev-...@lists.mozilla.org, "Frederik Braun" <fre...@mozilla.com>, "Paul Theriault" <pther...@mozilla.com>
Sent: Tuesday, April 30, 2013 6:49:39 AM
Subject: Re: [b2g] CSP 1.0 changes will block inline styles in certified apps

If the values injected are correctly and systematically sanitized, there
is really no harm in using innerHTML. That's why in the SMS app we
recently started a small tested templating micro-library that sanitize
all inputs by default. Ideally all innerHTML uses should be done through
this micro-library, which makes it easier to audit (because I obviously
agree that all uses of innerHTML should be audited).

Disabling innerHTML is imho a false good idea. Even if I like the idea
of defense-in-depth, and if I agree that all uses of innerHTML should be
reviewed and removed if it's not necessary.

--
Julien

[Ian Melven]

Hi,

thanks for the exposition :)

re <base> I must plug http://lcamtuf.coredump.cx/postxss/ again, which is where I first saw it, this also touches
on a few of the things you mentioned as well as some more interesting cases.

https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#base-uri is
the current proposal for handling <base>. Disabling <base> by default has definitely been discussed and there seems to be some
support for it, also some concern about breakage - as you say, <base> does seem to be rarely used (and CSP
is not heavily adopted on sites as of yet), so the intersection of the two seems likely to be quite small.

in general CSP hasn't been concerned with DoS issues or 'defacement' issues (ie making the page look ugly/crazy),
but i'll bring up the idea of blocking innerHTML on the WG list, i'm curious what folks will think :)

thanks,

ian


----- Original Message -----
From: "Jonas Sicking" <jo...@sicking.cc>
To: "Ian Melven" <ime...@mozilla.com>
Cc: dev-...@lists.mozilla.org, "Paul Theriault" <pther...@mozilla.com>, "Frederik Braun" <fre...@mozilla.com>
Sent: Monday, April 29, 2013 6:46:28 PM
Subject: Re: [b2g] CSP 1.0 changes will block inline styles in certified apps

On Mon, Apr 29, 2013 at 1:24 PM, Ian Melven <ime...@mozilla.com> wrote:
>
> Hi,
>
> style-src: unsafe-inline to be pedantic ;)

Yes, thanks.

> which innerHTML threats are we particularly worried about ? arbitrary element injection ? inline scripts via injecting <script> tags, setting event handlers, etc.
> _should_ still be blocked by a CSP that prevents inline scripting. Restricting use of <base> has also been brought up as
> something CSP 1.1 should do.

Oooh, base is a really good point. I wonder if that should be disabled
by default even. It seems very scary. Especially considering how
rarely it is used on modern web pages, the reward/risk ratio of
disabling it by default seems very good.

> i do think your 'block innerHTML' CSP directive idea is worth exploring though - that's why i want to understand exactly what we'd be
> addressing via it.

Mostly as a defense-in-depth mechanism. Basically it seems like using
innerHTML to inject content into a page will commonly be part of an
attack that uses multiple weaknesses or bugs in order to cause XSS or
other privilege escalation.

I.e. if we have a bug in our script blocking code, or in our CSS
src-limiting code, then it seems like using innerHTML would be a good
way to exploit that.

Another scenario could be a DoS because an injected <div
class="submitButton"> lays out on top of the real submit button
because there's a CSS rule om a stylesheet that uses a .submitButton
selector to position elements.

And even something trivial as making the SMS app look ugly by sending
a text message with "<b>text here</b>".

During gaia development we found several accidental uses of .innerHTML
which resulted in various degrees of harm to the user. But no (or
almost no) "correct" uses of .innerHTML. So the risk of having the
feature enabled very heavily outweighed the value we got out of it.

/ Jonas

> ----- Original Message -----
> From: "Jonas Sicking" <jo...@sicking.cc>
> To: "Paul Theriault" <pther...@mozilla.com>
> Cc: "Ian Melven" <ime...@mozilla.com>, dev-...@lists.mozilla.org
> Sent: Monday, April 29, 2013 1:11:00 PM

> Subject: Re: [b2g] CSP 1.0 changes will block inline styles in certified apps
>
>
>

[Jonas Sicking]

On Tue, Apr 30, 2013 at 6:49 AM, Julien Wajsberg <jwaj...@mozilla.com> wrote:
> Le 30/04/2013 03:46, Jonas Sicking a écrit :
>>

>>> i do think your 'block innerHTML' CSP directive idea is worth exploring though - that's why i want to understand exactly what we'd be
>>> addressing via it.
>> Mostly as a defense-in-depth mechanism. Basically it seems like using
>> innerHTML to inject content into a page will commonly be part of an
>> attack that uses multiple weaknesses or bugs in order to cause XSS or
>> other privilege escalation.
>>
>> I.e. if we have a bug in our script blocking code, or in our CSS
>> src-limiting code, then it seems like using innerHTML would be a good
>> way to exploit that.
>>
>> Another scenario could be a DoS because an injected <div
>> class="submitButton"> lays out on top of the real submit button
>> because there's a CSS rule om a stylesheet that uses a .submitButton
>> selector to position elements.
>>
>> And even something trivial as making the SMS app look ugly by sending
>> a text message with "<b>text here</b>".
>>
>> During gaia development we found several accidental uses of .innerHTML
>> which resulted in various degrees of harm to the user. But no (or
>> almost no) "correct" uses of .innerHTML. So the risk of having the
>> feature enabled very heavily outweighed the value we got out of it.
>>
>
>

> If the values injected are correctly and systematically sanitized, there
> is really no harm in using innerHTML. That's why in the SMS app we
> recently started a small tested templating micro-library that sanitize
> all inputs by default. Ideally all innerHTML uses should be done through
> this micro-library, which makes it easier to audit (because I obviously
> agree that all uses of innerHTML should be audited).
>
> Disabling innerHTML is imho a false good idea. Even if I like the idea
> of defense-in-depth, and if I agree that all uses of innerHTML should be
> reviewed and removed if it's not necessary.

Would it make sense to use DOMParser or range.createContextualFragment
instead? It seems to me that using .innerHTML in unsafe ways is very
easy to do by accident. If we always use
range.createContextualFragment instead then hopefully people will
think twice.

Please keep in mind that avoiding security issues are really
important. For now I don't think that we can count on people updating
the OS particularly often, if at all. So fixing security issues will
be dramatically harder than on the web. For now even harder than for
Firefox desktop.

/ Jonas

[Julien Wajsberg]

Le 30/04/2013 19:43, Ian Melven a écrit :
> re sanitization, the general opinion of the security folks I've spoken to here is that
> it's quite difficult to get right in _all_ cases.
>
> relevant to this thread : http://www.slideshare.net/x00mario/the-innerhtml-apocalypse
>

Thanks, that's a very interesting read.

That's why it's especially important to do this sanitization in one
place only.