W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: Entry Point Regulation vs Simpler Solutions (was Re: WebAppSec re-charter status)

From: Eduardo' Vela\ <evn@google.com>
Date: Wed, 25 Feb 2015 19:37:26 +0100
Message-ID: <CAFswPa85yBV0HGLfPv3PaQcvgVOsmkXK8o2C6Xq8rsBbghfC3Q@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Cc: David Ross <drx@google.com>, 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>
On Wed, Feb 25, 2015 at 7:33 PM, Brian Smith <brian@briansmith.org> wrote:

> Eduardo' Vela" <Nava> <evn@google.com> wrote:
> > 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.
>
> With respect to XSS, which types of XSS does EPR prevent? Reflected,
> Stored, DOM? I noticed that in the original announcement, David Ross
> specifically singled out only reflected XSS:
> https://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0009.html.
>
> I can see how EPR would prevent reflected XSS if the EPR policy
> prohibited the user from navigating to resources of their choosing.
> But, it isn't clear to me how EPR can prevent XSS without reducing
> users' ability to navigate to whatever resource they want ("deep
> linking") and that isn't already covered by "X-XSS-Protection: 1;
> mode=block".
>

Yes, it prevents reflected XSS, which for some applications for example
(Google, in specific) correspond to the vast majority of vulnerabilities.

Additionally, XSS filters are not security controls. It's reasonably easy
to bypass any of the browser XSS filters, IE, NoScript or Chrome's within a
couple hours. While they have been getting better over the years, they are
definitely far from being effective controls, and by the looks of it, they
won't be in our lifetime.

> 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.
>
> Great. I'm excited to see Mike West seems to be making progress on
> first-party cookies now.
>
> I appreciate that EPR is very simple to deploy compared to other
> protective measures. AFAICT, the primary issue is whether that
> ease-of-deployment justifies decreased user agency, or whether EPR can
> even work without decreasing user agency and violating the priority of
> constituents HTML design principle.


I agree that's the primary issue being raised. We'll see how it works out :)


> Cheers,
> Brian
>
Received on Wednesday, 25 February 2015 18:38:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:10 UTC