- From: Brian Smith <brian@briansmith.org>
- Date: Mon, 17 Nov 2014 17:56:54 -0800
- 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