- From: Michal Zalewski <lcamtuf@coredump.cx>
- Date: Fri, 21 Jan 2011 17:39:10 -0800
- To: Daniel Veditz <dveditz@mozilla.com>
- 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>
> 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? Well, if the author of the website can't get the policy spec in the right place, he won't get any protection. I'm really not arguing in favor of <meta> policies, though; I just think they *can* be done safely with minimal diligence - and so if we allow them for site owners who can't control HTTP headers (I'm positive this happens in some commercial and enterprise settings), they only stand to benefit from this. For users who can modify HTTP headers, they are a more robust approach, but having both (with <meta> honored only if headers are not present) does not strike me as a horrible trade-off. There is a labored argument to be made that this group of users may be confused and resort to <meta> when not needed, but a concise and well-written spec can help with this by giving strong and well-justified guidance. Since the superiority of one approach over the other is one of the points discussed here, I think it's useful not to be too principled about this detail, as there is a reasonable middle ground that does not cause insurmountable security problems, does not reduce the effectiveness of the mechanism in most uses, and does not introduce excess complexity in single-policy-spec cases. /mz
Received on Saturday, 22 January 2011 01:40:06 UTC