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

Re: [CSP] Clarifications regarding the HTTP LINK Header

From: Brian Smith <brian@briansmith.org>
Date: Mon, 17 Nov 2014 17:56:54 -0800
Message-ID: <CAFewVt7BWFGoRrBkWHHKd3_pEG7fLnjoN8vUgSGPKo2RBCSLgA@mail.gmail.com>
To: Brad Hill <hillbrad@fb.com>
Cc: Ilya Grigorik <ilya@igvita.com>, Anne van Kesteren <annevk@annevk.nl>, Boris Zbarsky <bzbarsky@mit.edu>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Mon, Nov 17, 2014 at 3:14 PM, Brad Hill <hillbrad@fb.com> wrote:
> If I prefetch something that is later denied to be included / transcluded
> into a page via CSP, have I violated the policy?

According to the CSP 1.0 and CSP 2 drafts? No. According to users'
expectations? Yes, I believe so.

> Even if we decide to use CSP for confinement (which it presently makes no
> strong guarantees of)

CSP is already being used for confinement for security-critical
purposes, in Google Chrome's extension mechanism and Mozilla's
packaged app mechanism. (Perhaps this depends on the precise
definition of "confinement" used.)

> is link fetching that happens before the instantiation
> of a resource in the scope of that confinement?

Devdatta brought up the point last week that the CSP drafts do not say
that the browser MUST NOT issue the HTTP (or whatever) request when
they block a fetch due to CSP violation. That is, it is perfectly
legal to make the HTTP request (optionally caching it) and then ignore
it, according to the current wording in the CSP drafts. However, I
think this is a bug that should be fixed.

So, currently, the answer is that prefetching isn't to be blocked by
CSP, because fetching isn't blocked by CSP. However, I hope soon the
answer changes so that prefetching is blocked by CSP because fetching
is blocked by CSP.

> I think an example of an actual vulnerability that we would care about
> addressing would help me reason about this better.

1. Sysadmin applies a blanket policy of "style-src 'self'" at the
network edge, expecting this to prevent the entire site from loading
any untrusted CSS.

2. Web app developer subverts the policy (not maliciously, but just
because they think the policy is dumb) with:
     Link: <https://untrustworthy.example.com/free-animated-cursors.css>;
rel="stylesheet"

3. untrustworthy.example.com lives up to its name (perhaps it is
hacked, or perhaps it is dishonest), and starts serving a malicious
CSS to steal passwords and whatnot (effectively stored XSS).

Granted, the sysadmin should be aware of the Link header and should
have tested whether the attempted restriction works. But, I think it
would be better for CSP to work the way the hypothetical sysadmin
expected, so that this could not happen.

Cheers,
Brian
Received on Tuesday, 18 November 2014 01:57:22 UTC

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