- From: Brad Hill <hillbrad@gmail.com>
- Date: Tue, 3 Sep 2013 13:38:25 -0700
- To: Daniel Veditz <dveditz@mozilla.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAEeYn8h3ZuqU5+W+VAnqR8m6eo=JG64-kAwbqojK+-7bW-iwZA@mail.gmail.com>
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 > >
Received on Tuesday, 3 September 2013 20:38:53 UTC