W3C home > Mailing lists > Public > public-web-security@w3.org > January 2011

Re: XSS mitigation in browsers

From: Daniel Veditz <dveditz@mozilla.com>
Date: Fri, 21 Jan 2011 17:19:56 -0800
Message-ID: <4D3A30BC.7020004@mozilla.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:25 UTC