- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 8 Sep 2016 13:28:07 +0200
- 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. Fair. -- https://annevankesteren.nl/
Received on Thursday, 8 September 2016 11:28:43 UTC