[whatwg] <iframe srcdoc> and Content-Security-Policy

Fri Jun 22 16:16:32 PDT 2012

On Fri, Jun 22, 2012 at 4:10 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 7 May 2012, Adam Barth wrote:
>>
>> == Summary ==
>>
>> When creating a srcdoc document, we need to be careful to avoid
>> introducing a Content-Security-Policy loophole.
>>
>> == Details ==
>>
>> Consider a document with the following Content-Security-Policy:
>>
>> Content-Security-Policy: default-src 'none'; frame-src *
>>
>> Now, imagine the following injection vulnerability in index.php:
>>
>> <body>Hello <?=$username?></body>
>>
>> This Content-Security-Policy is supposed to prevent the attacker from
>> being able to inject script into index.php.  However, consider the
>> following value for $username:
>>
>> $username = '<iframe
>> srcdoc="<script>alert(parent.document.cookie);</script>"></iframe>';
>>
>> In this case, we could get in trouble if the user agent doesn't
>> enforce the parent document's Content-Security-Policy on the srcdoc
>> document because the user agent copies the parent document's origin
>> unto the child document.
>>
>> == Proposal ==
>>
>> When creating a srcdoc document, in the same way that we copy the
>> parent document's origin onto the child document, we should:
>>
>> 1) /enforce/, on the srcdoc document, all CSP policies currently being
>> enforced on the parent document.
>> 2) /monitor/, on the srcdoc document, all CSP policies currently being
>> monitored on the parent document.
>>
>> Please see <http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html>
>> for definitions of these terms.
>
> How is this different from the same attack but with:
>
>   $username = '<iframe src="data:text/html,<script>alert(parent.document.cookie);</script>"></iframe>';>

CSP will block this frame unless the site specifies "data:" as a valid
frame-src.

> ..., or:
>
>   $username = '<iframe src="attacker-uploaded-file-without-csp.html"></iframe>';>
>
> ...?

It's a vulnerability to let attacker's upload HTML documents to your
origin.  That's a less common vulnerability that just echoing an
attacker-controlled string.  If the site likes, it can use the
"sandbox" directive from CSP to put attacker-uploaded HTML content
into a unique-origin sandbox.

> That is, why is srcdoc="" special here?

It's special because it's a way of specifying a resource other than
providing a URI for that resource.  If you like, we could consider
this an "inline" resource and block it unless the policy contains
'unsafe-inline', but that seems less useful that just inheriting the
CSP policy the same way we inherit the parent document's origin and
title.

Adam