Re: On the Content Security Policy Violations due to Same Origin Policy

Hi, Francis.

Thanks for sharing the paper, it's quite an interesting work! Also, thanks
for citing our own paper :-)

Your paper shows that the interaction between CSP and SOP is not
straightforward, I really think most of your findings are relevant and
potentially dangerous in practice. However, I also think the proposed
solution to the problem is sub-optimal. Enforcing the same CSP on an entire
origin means that all the pages on that origin are subject to the same
content restrictions. If you want to make these pages work correctly, the
origin-wide CSP should be the "union" of the individual page-wide CSPs.
This means that, to strenghten your website against the attacks you discuss
in the paper, you are also overly liberalising the content restrictions in
the whole website.

I think that, if you want to properly address these issues with the tools
presently available in CSP, the best solution is a (painful) compilation
and scrutiny of CSP policies for all pages which are going to be embedded
inside CSP-protected web pages on the same origin. As you point out in the
paper, it's not obvious which conditions one desire on the relation of the
two policies. Probably more research is needed to find a more robust - yet
practical - solution to the issues you identified. Nice work anyway!

Best regards,
--
Stefano

On 15 November 2016 at 11:52, Dolière Francis SOME <doliere.some@inria..fr>
wrote:

> Dear WebAppSec WG members,
>
> we are researchers at INRIA working on web application security and we
> have recently
> found an inconsistency between the Same-Origin Policy and the Content
> Security Policy
> that may lead to violations of CSP. We discuss this inconsistency and show
> examples
> of websites that may suffer from it in our paper:
> https://arxiv.org/abs/1611.02875
>
>
> Besides the inconsistency between  CSP and SOP, the paper has two other
> important
> contributions that may be of interest for the WebAppSec WG:
>
> 1. A CSP inclusion algorithm for Embedded Enforcement (
> https://w3c.github.io/webappsec-csp/embedded/)
>
> Thanks to the pointers given to us by WebAppSec WG co-chairs, we have
> found that
> Mike West has already started a draft on CSP: Embedded Enforcement that
> may help to
> mitigate  violations due to inconsitencies : it suggests that an embedded
> iframe is required to
> enforce a required CSP or a more restricted version of it. This policy
>  does not have an
> CSP inclusion algorithm to check whether a CSP is more restrictive than
> another one.
> We propose such algorithm in our paper (see Appendix 10.1 on p 10)
>
> 2. Inconsistency of CSP and HTML5 specifications for srcdoc iframes which
> are sandboxed.
>
> We have found out that when an iframe is included as srcdoc with a sandbox
> attribute
> with only “allow-scripts” value, CSP and SOP become inconsistent. CSP
> required that
> that CSP of the parent page is enforced in the srcdoc iframe (
> https://www.w3.org/TR/CSP11/#processing-model-iframe-srcdoc)
> however according to SOP, this iframe gets a different origin since the
> value “allow-same-origin”
> is not present.
>
> We found out that different browsers have different implementations for
> this scenario (see
> Section 5 of our paper).
> Gecko-based browsers (Mozilla Firefox) give preference to HTML5, and does
> not enforce
> a CSP of the parent page in the iframe when “allow-same-origin” is
> absent. We have reported
> this issue to Mozilla (bug number 1305076) since we thought it’s a bug in
> their implementation.
> Webkit-based and Blink-based browsers (Chrome, Chromium, Opera) instead
> give preference
> to CSP, enforcing a CSP of the parent in srcdoc iframe in any case.
>
> However, we believe that such case is not properly described in the
> specifications of CSP and
> HTML5 and this is the reason it’s implemented differently in browsers. We
> believe that applying
> the CSP of the parent page to its srcdoc iframe makes sense because they
> are considered same
> origin. However, when the srcdoc iframe is sandboxed without “allow-same-origin”,
> the origin of
> the iframe is different and cannot communicate to the parent page.
>
> Do you think that CSP should still apply to sandboxed srcdoc iframes
> without “allow-same-origin”?
>
> Best regards,
> Dolière Francis Somé,  Nataliia Bielova, Tamara Rezk
>