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

Makes sense.


On Tue, Sep 3, 2013 at 1:48 PM, Devdatta Akhawe <dev.akhawe@gmail.com>wrote:

> 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
>
>
> -dev
>
>
> 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 3.2.2.2 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
>>>
>>>
>>
>