Re: ACTION-149, srcdoc, blob, data, etc.

On 11/18/2013 4:02 PM, Brad Hill wrote:
> This is a proposal to resolve ACTION-149 about how to handle special URI
> types indicating content created as part of another HTTP request.

The result of this policy seems reasonable, but it is somewhat complex
for web authors to keep in mind. It is nice for authors who use these
features not to have to call them out, but it does mean authors who have
no clue what these are may have to watch out for them nonetheless.

>  1. If the scheme portion of the URI is "data:",  "javascript:" or
> another construct that allows direct encoding of content, return DOES
> NOT MATCH unless the 'unsafe-inline' keyword source is present.  

In my proposal you wouldn't have to add 'unsafe-inline'. Not a whole lot
of practical difference, but in the specific case when your page's XSS
only allowed for attribute injection there would be no way to inject
<script src=data:> and injected onmouseover= wouldn't work with my proposal.

>  2. If the scheme portion of the URI is "filesystem://", "blob://" or
> another scheme referencing content may have been dynamically created by
> same-origin script in the current or a previous execution context,
> return DOES NOT MATCH unless the 'unsafe-eval' keyword source is present. 

These seem safely equivalent, and forcing authors to specify
'unsafe-eval' might make them think more about potential problems than
adding blob: to the policy would.

> When evaluating policy for an iframe generated from the srcdoc attribute
> instead of a URI, return DOES NOT MATCH unless a source expression
> equivalent to the  'self' keyword is present.

Sure. The important thing with srcdoc is that the iframe inherit the
parent's content security policy otherwise it's a pretty easy CSP bypass.

> For purposes of discussion on tomorrow's call, Dan Veditz had an
> alternate proposal that i believe is equivalent to:

Fair characterization as long as we're talking about URL-looking things
like data: and blob:. I considered "srcdoc" as a separate issue (but I
assumed your proposed handling of it).

-Dan Veditz