- From: Eduardo' Vela\ <evn@google.com>
- Date: Fri, 13 Feb 2015 12:44:17 +0100
- To: David Ross <drx@google.com>
- Cc: Brian Smith <brian@briansmith.org>, Devdatta Akhawe <dev.akhawe@gmail.com>, Deian Stefan <deian@cs.stanford.edu>, Martin Thomson <martin.thomson@gmail.com>, Brad Hill <hillbrad@gmail.com>, Jeffrey Yasskin <jyasskin@google.com>, Mike West <mkwst@google.com>, Wendy Seltzer <wseltzer@w3.org>, Dan Veditz <dveditz@mozilla.com>, Mounir Lamouri <mlamouri@google.com>, David Baron <dbaron@dbaron.org>, Anne van Kesteren <annevk@annevk.nl>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAFswPa8Nskg59nRszFr9ytWZ7zZzrVP2F5Lm04cX01+rmidYiw@mail.gmail.com>
Anne asked why EPR solves XSS/CSRF in a way that can't be solved via other means. In specific for XSS. In many situations, CSP is simply undeployable. Even for applications written from scratch, because of the dependencies on widgets/controls that aren't compatible with CSP and aren't interested to be CSP-friendly. As a result, while CSP is a great tool for some sites, it's no silver bullet. For CSRF, first-party cookies resolve the concern quite effectively, however, it requires modifying application logic, and EPR allows someone to deploy this on an existing website almost trivially. On Thu, Feb 12, 2015 at 11:18 PM, David Ross <drx@google.com> wrote: > > To what extent is CSP not solving the defense-in-depth issue > > sufficiently for XSS? It seems to me that with or without EPR, if > > there are serious deficiencies in CSP, we need to improve it. > I'm not sure it's a matter of improving CSP but rather it's just about > providing choice. For example, sites / apps (as well as browser > extensions) have found it's necessary to relax their CSP policies to > support javascript libraries or some particular configuration. EPR targets > some of the same problems as CSP (XSS / XSRF) from a very different angle > (regulating entry points into the applications.) Thus EPR offers a way to > increase security even given pragmatic CSP policy. It just provides > developers more choice in how they secure apps in the real world. > > I would say it's the same thing w.r.t. first-party / same-origin cookies. > EPR just provides developers with another tool they can leverage if it > makes sense to do so. > > Dave > > On Thu, Feb 12, 2015 at 12:53 PM, Brian Smith <brian@briansmith.org> > wrote: > >> David Ross <drx@google.com> wrote: >> > That being said, I think the criticism is a bit unfair. EPR is an >> opt-in >> > feature with an intended audience largely separate from those who might >> wish >> > to prevent deep linking on their web sites. >> >> As Anne noted, the concerns about the *unintended* abuse of EPR, not >> the use by the intended audience. >> >> > EPR helps enable the web platform to support scenarios with very >> stringent >> > security requirements. For example, XSS or XSRF is an unacceptable >> failure >> > mode for sensitive applications. >> >> To what extent is CSP not solving the defense-in-depth issue >> sufficiently for XSS? It seems to me that with or without EPR, if >> there are serious deficiencies in CSP, we need to improve it. >> >> Similarly, it looks like the idea of improved origin restrictions >> cookies as defense-in-depth for CSRF has a lot of support from Google >> [1][2] and Mozilla [3]. Again, it seems with or without EPR, we need >> such independent improvements to CSRF protection. What limitations are >> there to those proposals that would make them insufficient >> defense-in-depth for CSRF compared to EPR? >> >> It seems like the existing/simpler mechanisms I cited are less open to >> abuse that would reduce browser users' agency, and so they seem >> preferable to me, if they offer the same level of benefit as EPR, >> unless there are other significant benefits to EPR that I'm >> overlooking. >> >> Cheers, >> Brian >> >> [1] >> https://mikewest.github.io/internetdrafts/first-party-cookies/draft-west-first-party-cookies-00.html >> [2] >> https://mikewest.github.io/internetdrafts/origin-cookies/draft-west-origin-cookies-00.html >> [3] >> https://github.com/mozmark/SameDomain-cookies/blob/master/samedomain.txt >> >> > (Eg: Administrative consoles) Authors of >> > these sensitive applications sometimes favor implementation as a legacy >> > platform app, a mobile app, or even a command line app over the web app >> > platform simply because of this security consideration. I believe it's >> > important to provide the _option_ for developers to implement EPR to >> better >> > meet their security requirements. >> > >> > Dave >> > >> > >> > On Mon, Feb 9, 2015 at 8:48 AM, Devdatta Akhawe <dev.akhawe@gmail.com> >> > wrote: >> >> >> >> > If I am not mistaken what you are proposing here is your work on DCS >> >> > [2]. I like DCS, but this is a different system. I think that web >> apps >> >> > implementing the enforcement logic, while useful for more complex >> >> > policies, is more difficult than associating a label with >> postMessages >> >> >> >> Forgive me if I gave that impression. That was not my intention. I >> >> actually think the ideas proposed in COWL are definitely what we want: >> >> confinement for things like ads, third-party widgets without the heavy >> >> cost of doing isolation via iframes. I think that was the general >> >> motivation discussed at TPAC too, although maybe I am forgetting >> >> something. So, for example, I am definitely in favor of something like >> >> the workers in the proposal. >> >> >> >> My only concern is whether or not we want to make "specify and >> >> implement DC labels on the web patform" a part of the deliverable. It >> >> seems you definitely want it to be part of the deliverable---but in >> >> that case , I think the text should say this explicitly. I definitely >> >> did not get that when I first read the text and we would have saved a >> >> lot of email :) >> >> >> >> cheers >> >> Dev >> >> >> >> > as a way of expressing security concern. (Because of labels, the >> COWL >> >> > confinement enforcement mechanism also piggy-backs on CSP.) But, more >> >> > importantly, DCS cannot safely allow for a number of use cases that >> COWL >> >> > does. For example, we would not be able to build mashups wherein the >> >> > parties are mutually distrusting. This is because an iframe (or >> worker) >> >> > cannot impose any restrictions on its parent and there is no way to >> >> > impose confinement restrictions on cross-origin contexts. >> >> > >> >> > DCS and COWL have some similarities, but also have different goals, >> so >> >> > it is natural that the approaches differ and excell at different >> things. >> >> > I think they may even be complimentary. But, if it's okay with you, >> >> > Dev, I propose discussing DCS separately to avoid confusion. >> >> > >> >> > Thanks, >> >> > Deian >> >> > >> >> > [1] http://www.scs.stanford.edu/~deian/pubs/stefan:2011:dclabels.pdf >> >> > [2] http://devd.me/papers/dcs-esorics.pdf >> > >> > >> > >
Received on Friday, 13 February 2015 11:45:04 UTC