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

Hi Stefano, 

It is good to hear from you ! 

>>Hi, Francis.<< 

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

Thanks for taking a look at our work ! 

>>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.<< 

Regarding the optimality of our solution, you are right, and we agree that an origin-wide CSP can be very liberal on some pages, because they probably load content and resources from different domains. 
However, if you have 2 same-origin pages (parent and iframe), and you require them to directly interact, having the same CSP for the 2 pages is the best solution. Otherwise, you run into the inconsistencies we pointed out. 
So, by origin-wide CSP, we mean whenever you have 2 same origin pages that are nested, and which can directly interact, you should also have the same CSP for them. 

>>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! << 

Right ! The problem is really the relation between those two policies. 
1. Either one needs 2 same origin nested pages to directly interact, in which case, having the same CSP for those 2 pages is the best solution. 
2. Or direct interaction between the 2 same origin pages is not the desired feature. In this last case, the 2 pages can have different CSPs, relevant to the content and resources that they embed. Nevertheless, as we suggested in the proposed solution, one should then sandbox the page which is embedded as iframe. This will create a different origin for the iframe, and then prevent direct interactions between the parent and the iframe. If later on, the 2 pages need to exchange messages, one can still use methods like postMessage. 

>>Best regards, 
>>-- 
>>Stefano 

Thanks again for the comments and suggestions. 
Our paper has been accepted to WWW 2017. 
The reviewers have made very interesting comments and suggestions too. 
We are currently working on the final version of the paper. 

Best, 
Tamara, Nataliia and Francis 

----- Original Message -----

> From: "Stefano Calzavara" <calzavara@dais.unive.it>
> To: "Dolière Francis SOME" <doliere.some@inria.fr>
> Cc: public-webappsec@w3.org, hillbrad@fb.com, dveditz@mozilla.com, "Nataliia
> Bielova" <nataliia.bielova@inria.fr>, "Tamara Rezk" <tamara.rezk@inria.fr>
> Sent: Tuesday, November 15, 2016 7:16:21 PM
> Subject: 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 differen t 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, enfor cing 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
>