W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2013

Re: [webappsec] CSP: are blob uri's really just origin='self'?

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Tue, 3 Sep 2013 13:48:13 -0700
Message-ID: <CAPfop_3sfzTyBQQS=HJKkor6ighmhFpScNKhYCnD9vHQ6kqfqw@mail.gmail.com>
To: Brad Hill <hillbrad@gmail.com>
Cc: Daniel Veditz <dveditz@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Should we add filesystem: URIs to that list? I think there was a claimed
Chrome extensions' CSP bypass due to filesystem: URIs at this year's
AppSecEU: http://is.gd/mq1GLQ


On 3 September 2013 13:38, Brad Hill <hillbrad@gmail.com> wrote:

> We had an action item for some time to clarify this, that we dropped.  I'd
> propose something like the following:
> Inline-content
> --------------------
> Certain URL schemes, including but not limited to javascript:, data: and
> blob:, and the srcdoc attribute of iframe, refer to content that is
> delivered inline with the body of another HTTP response, rather than a
> resource representation independently retrieved with an identifiable
> origin.  Such schemes have special processing rules:
> 1)  Schemes designating inline content are ignored if listed directly as a
> scheme-source, and are excluded from the "*" match rule.
> 1) For most directives, all resources designated by these schemes are
> considered equivalent to the 'self' origin, and allowed if 'self' is
> specified, either by keyword-source or by the host-source production
> matching the resource's own origin.
> 2) For the script-src directive, all resources designated by these schemes
> do not match unless the 'unsafe-eval' keyword-source is specified.
> I wonder if we need to consider similar for style-src?  Is it 'self' or
> 'unsafe-inline'?
> -Brad Hill
> On Tue, Sep 3, 2013 at 11:05 AM, Daniel Veditz <dveditz@mozilla.com>wrote:
>> On 8/30/2013 2:05 PM, Brad Hill wrote:
>> > I started writing CSP tests for workers, and realized that the blob:
>> > scheme can be used to circumvent inline-script and eval protections. You
>> > can grab text out of the DOM or any string, use createObjectURL() and
>> > run it as script, so long as 'self' is in the policy.
>> Where we go wrong is in section where matching rules allow "*"
>> to match all schemes. We'd be better off treating is as implied by the
>> syntax in 3.2.2:
>> According to the syntax the "*" is part of the "host" production, which
>> has an optional scheme part. Elsewhere in the matching rules if the
>> scheme is not present then the scheme must match the document's scheme;
>> as an exception we also allow https: to match documents which have a
>> http: scheme. Currently if you specify * it will match ftp, gopher, aim,
>> file, and anything that might get invented after the page author
>> specifies their policy.
>> -Dan Veditz
Received on Tuesday, 3 September 2013 20:49:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:34 UTC