W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2016

On the Content Security Policy Violations due to Same Origin Policy

From: Dolière Francis SOME <doliere.some@inria.fr>
Date: Tue, 15 Nov 2016 11:52:38 +0100 (CET)
To: public-webappsec@w3.org
Cc: hillbrad@fb.com, dveditz@mozilla.com, Nataliia Bielova <nataliia.bielova@inria.fr>, Tamara Rezk <tamara.rezk@inria.fr>
Message-ID: <1031074963.19008471.1479207158293.JavaMail.zimbra@inria.fr>
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 
Received on Tuesday, 15 November 2016 12:12:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:21 UTC