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

Re: XSS mitigation in browsers

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Fri, 21 Jan 2011 17:39:10 -0800
Message-ID: <AANLkTim057OCtM+xm+b5w=KSa8kRqv=8Zt0gFuM9J+WM@mail.gmail.com>
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.

Received on Saturday, 22 January 2011 01:40:06 UTC

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