W3C home > Mailing lists > Public > public-web-security@w3.org > August 2011

Re: lcamtuf on the subtle/deadly problem with CSP

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 31 Aug 2011 00:50:53 -0700
Message-ID: <CAJE5ia8YH1F_rPcS6ROf+k7zWuZkrCmGEoGoCh2XB-k1PkBXgQ@mail.gmail.com>
To: Daniel Veditz <dveditz@mozilla.com>
Cc: "sird@rckc.at" <sird@rckc.at>, "Hill, Brad" <bhill@paypal-inc.com>, "public-web-security@w3.org" <public-web-security@w3.org>
On Wed, Aug 31, 2011 at 12:04 AM, Daniel Veditz <dveditz@mozilla.com> wrote:
> On 8/30/11 10:33 PM, Adam Barth wrote:
>> It seems like we could let folks specify paths in addition to schemes,
>> hosts, and ports.
>> script-src http://example.com/js
> We've talked about exactly that in the past. I'm fine with it, iirc
> we dropped it because people were already complaining about
> "complexity".

Yeah, I agree that the main cost is complexity.  The main question is
whether this problem is actually "deadly" or whether lcamtuf is being


>> CSP is still behind vendor prefixes in the two
>> implementations I'm aware of, so making non-forwards compatible
>> changes is probably still fine.
> If we cared enough we could make it forwards compatible by creating
> "script-src2" which old implementations would ignore, and make new
> implementations honor script-src if script-src2 is not present. But
> then sites that want to be compatible with both old and new (and
> take advantage of the path feature) have to enumerate their script
> sources twice.
> I'm not seriously suggesting we do that.
> If we support path prefixing for script-src I'd want all the
> content-load directives to support it for consistency. I also would
> really like to avoid introducing regexp and instead limit this to
> simple string prefix matching. I'd be fine allowing full-path match
> down to the filename; someone requested that at one point. I think
> in practice it would make policies too large (and again complex),
> but if we're halfway there no harm in going the rest of the way.
> -Dan Veditz
Received on Wednesday, 31 August 2011 07:51:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:19 UTC