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

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".

> 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.

Cheers,
Brian

Received on Wednesday, 25 February 2015 18:33:52 UTC