- From: Adam Barth <w3c@adambarth.com>
- Date: Fri, 22 Jun 2012 16:16:32 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg <whatwg@lists.whatwg.org>
On Fri, Jun 22, 2012 at 4:10 PM, Ian Hickson <ian@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
Received on Friday, 22 June 2012 23:17:39 UTC