W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2016

Re: On the Insecurity of Whitelists and the Future of CSP

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 8 Sep 2016 13:28:07 +0200
Message-ID: <CADnb78ged8e_xxnAmDZyxowFmRSRGTVGzyZQ9fA8Ty5Zvasj5Q@mail.gmail.com>
To: Artur Janc <aaj@google.com>
Cc: Christoph Kerschbaumer <ckerschbaumer@mozilla.com>, "Hodges, Jeff" <jeff.hodges@paypal.com>, W3C Web App Security WG <public-webappsec@w3.org>, craig.francis@gmail.com
On Thu, Sep 8, 2016 at 1:16 PM, Artur Janc <aaj@google.com> wrote:
> An attacker with an XSS can set any cookie they want to make the exfiltrated
> data visible across the whole top-level domain, so they're not bound by
> flags on any existing cookies.

That depends on whether or not we offer ways to restrict cookie APIs.
(I think there's a proposal for that somewhere.)

> I'm not saying that preventing exfiltration is a priori bad or impossible.
> However, it's something that we're nowhere near solving, and even if it's
> solved it will not make cross-site scripting much less of a concern for most
> applications. Compare this to the goal of preventing malicious script
> execution in the first place, which we're close to achieving with nonces +
> trust propagation with 'strict-dynamic' (at least for most classes of XSS
> that we currently see).
> If we can improve the situation there (e.g. give developers more powerful
> features to execute trusted scripts while disallowing injected ones) then
> we're simultaneously solving the exfiltration issue because an attacker
> without script execution cannot easily extract the data from the DOM in the
> first place. And on top of it, we're addressing the other current risks of
> XSS, such as persistent access to the compromised origin, and so on. I think
> it's a powerful signal that we should be focusing efforts on that area.


Received on Thursday, 8 September 2016 11:28:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:57 UTC