W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2015

Re: [REFERRER] policy inheritance via javascript: URI and new document

From: Jochen Eisinger <eisinger@google.com>
Date: Tue, 28 Apr 2015 14:13:50 +0000
Message-ID: <CALjhuidyWvvhmFp62cpWSTbUa0J3wQDm0zXYHfq-n=2A8cXn=w@mail.gmail.com>
To: Sid Stamm <sid@mozilla.com>, "mkwst@google.com" <mkwst@google.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, WebAppSec WG <public-webappsec@w3.org>
+Mike West <mkwst@google.com> to grab his attention

Since we can deliver a referrer policy via CSP, I guess it would be great
if they both behaved the same

On Tue, Apr 28, 2015 at 4:12 PM Sid Stamm <sid@mozilla.com> wrote:

> On Mon, Apr 27, 2015 at 12:40 PM, Jochen Eisinger <eisinger@google.com>
> wrote:
> > What does CSP do, if a page with a policy that disallows plugins creates
> an
> > about:blank pop-up, can the pop-up run plugins?
>
> The CSP spec is also not clear about this.  I expected that in Firefox
> we'd block the load since the CSP is bound to the principal (the
> referrer policy is not).
>
> Test code below my signature. I tested in Firefox and Chrome using a
> javascript:-based image loader.  In Firefox, CSP blocks both the "load
> here" and the "load in _blank" images.  In Chrome, they're both the
> same since _blank is ignored for javascript: schemes.
>
> -Sid
>
> ---
>
> <?php
>   header("Content-Security-Policy: default-src * 'unsafe-inline';
> img-src 'none'");
>   $image = "https://www.w3.org/Icons/w3c_home";
>   $script = "javascript:(function() {var
> x=document.createElement('img'); x.src
> ='$image';document.body.appendChild(x);})();";
> ?>
> <html>
>   <body>
>     <a href="<?=$script?>">Open here</a>
>     <br/>
>     <a href="<?=$script?>" target="_blank">Open there</a>
>   </body>
> </html>
>
Received on Tuesday, 28 April 2015 14:14:18 UTC

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