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 14:37:41 -0800
Message-ID: <4D3A0AB5.4010402@mozilla.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
CC: Michal Zalewski <lcamtuf@coredump.cx>, 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 1:47 PM, Devdatta Akhawe wrote:
> Michal Zalweski wrote:
>> I think we're splitting hairs here. Both approaches could be safely
>> combined by allowing HTTP headers to specify policy, in which case
>> meta is ignored (which rules out injection woes completely); or meta
>> to be interpreted if HTTP header is not present (in cases where site
>> owner can't manipulate server settings). But either way, with minimal
>> diligence and properly defined parsing rules, the risk in both cases
>> is pretty low.
> How about instead allowing the meta tag policy to only make the policy
> more restrictive than the one defined in HTTP headers? (following my
> previous suggestion).

In an earlier draft when we allowed both headers and <meta> tags
this is exactly what we did. We removed <meta> to simplify the
proposal and more strongly separate policy from document but I don't
think we feel all that strongly about it.

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.

-Dan Veditz
Received on Friday, 21 January 2011 22:38:47 UTC

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