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

Re: XSS mitigation in browsers

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Thu, 20 Jan 2011 14:01:29 -0800
Message-ID: <AANLkTincLPk9Ntr6k_-Ne+6iXyCZCPjiUzzkQzK-E-+X@mail.gmail.com>
To: Brandon Sterne <bsterne@mozilla.com>
Cc: Adam Barth <w3c@adambarth.com>, public-web-security@w3.org, Sid Stamm <sid@mozilla.com>, Lucas Adamski <ladamski@mozilla.com>
> I don't think the use of HTML tags instead of HTTP headers is
> well-justified.

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.

> Frame controls, included in Mozilla's CSP proposal as the
> frame-ancestors directive, also seem to have value.  Microsoft would not
> have introduced the X-Frame-Options header if there wasn't a valid use
> case being addressed.

Yes, and FWIW, we are actually pretty unhappy with the limitations of
X-Frame-Options. I had conversations with David Ross to at the very
minimum, include a list of permissible embedding origins; he seemed
receptive. As you ntoe, this still does not solve inherently
clickjackable cases such as the archetypal Facebook "like" button
gadget, though. I think that quite a few solutions were discussed in
the past, but to most vendors, X-Frame-Options seemed like the easiest
way to mitigate the risk.

Received on Thursday, 20 January 2011 22:02:22 UTC

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