- From: Daniel Veditz <dveditz@mozilla.com>
- Date: Fri, 21 Jan 2011 17:19:56 -0800
- To: Michal Zalewski <lcamtuf@coredump.cx>
- CC: Devdatta Akhawe <dev.akhawe@gmail.com>, gaz Heyes <gazheyes@gmail.com>, Giorgio Maone <g.maone@informaction.com>, Brandon Sterne <bsterne@mozilla.com>, public-web-security@w3.org, Lucas Adamski <ladamski@mozilla.com>
On 1/21/11 2:47 PM, Michal Zalewski wrote: >> The <meta> tag raises the issue of what to do if the policy is found >> after something that should have been covered by the policy. Ignore >> the policy (too late!), ignore the violation (injected scripts win), >> maybe reparse the document from the beginning and hope there weren't >> earlier violations that matter? Not insurmountable, but definitely >> will add to the complexity of the spec. > > Yes, that's a problem if you allow multiple <meta> tags to specify a > single valid policy. In Adam's proposal, the policy must appear in a > single tag, which allows you to simply ignore all subsequent <meta>s > that would broaden the policy (and it can't be narrowed down, ruling > out the risk of policy deployment errors that accidentally give too > much access because of this parsing precedence). The issues I raised above assume a single <meta> policy statement. I've seen plenty of hacked pages that start with an injected <iframe> or <script>. What do you do if you encounter the policy <meta> after that? You might argue that if the page suffered from such an injection (admittedly a different problem than XSS) the server hack might also be able to modify HTTP headers and thus subvert CSP. Maybe, maybe not; depends on the site technology and the attack. At the very least external CSP policies add an additional hurdle the attackers would have to deal with. -Dan Veditz
Received on Saturday, 22 January 2011 01:21:07 UTC