- From: Michal Zalewski <lcamtuf@coredump.cx>
- Date: Thu, 20 Jan 2011 14:01:29 -0800
- 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. /mz
Received on Thursday, 20 January 2011 22:02:22 UTC