Re: Avoiding syncronous manifest requests in EPR

I like it potentially as an option, but not as the default config.  It
punts more work over to the web dev to make sure that not only do they
include the header everywhere, but they include a (secure) script on all
their content.  And really, there are only a few reasonable actions in the
event that policy needs to be enforced (block, redirect, allow w/o auth)
and the browser itself can easily implement these.

I've seen reflected XSS via path, but it is by far the exception.  I don't
think we need to claim that EPR would mitigate all potential reflected XSS
bugs.  It's also not hard to imagine further defining NO DATA to inhibit
XSS via path while still allowing most valid requests.

Dave

On Tue, Nov 4, 2014 at 11:20 AM, Devdatta Akhawe <dev.akhawe@gmail.com>
wrote:

> Hi David
>
> What do you think about having a DOM accessible value denoting whether
> the current load passed an EPR check or not (i.e., no EPR loaded yet)?
> Then, the page can decide not to render the rest of the page (in head
> or something) if the EPR is not loaded. NO DATA does not appear a high
> assurance mechanism: e.g., for wikipedia, the query params are
> actually part of the URI and something people recommend with RESTful
> design.
>
> Wdyt?
>
> On 3 November 2014 11:45, David Ross <drx@google.com> wrote:
> > One thing that's come up in discussing EPR with the webappsec group is
> the
> > corner case requiring a synchronous request.  Specifically, nobody seems
> to
> > like synchronous requests.  :-)
> >
> > The problematic scenario is involves mitigating XSS on the very first
> > request to a site, when no manifest exists in the EPR manifest cache.
> >
> > (XSRF is already assumed to be impossible to mitigate, but less important
> > here because it requires the user to be auth'd, which won't generally be
> the
> > case until there is also an EPR manifest present.)
> >
> > I believe there are a number of caveats that make the synchronous request
> > not so bad:
> >
> > 1)  The attack we're trying to mitigate (XSS) is only possible on a
> > navigation, not a resource request.
> >
> > 2)  It's essentially just a one-time thing per-domain.  Once a manifest
> is
> > cached there is no need to fetch the manifest synchronously until it
> expires
> > from the cache.
> >
> > 3)  It's only for sites that have opted-in to EPR via a header.  It would
> > not affect existing web sites.
> >
> > Nevertheless, it sounds like a sync request may be a non-starter, so I'm
> > brainstorming some alternatives.
> >
> > Consider this approach:
> >
> > If X-EPR exists on the response
> >   AND it's a navigation (as opposed to a resource request)
> >   AND the navigation was initiated by a web site, not by the user typing
> in
> > the address bar or picking a bookmark
> >   AND no cached manifest exists
> > THEN enforce NO DATA.
> >
> > NO DATA implies the request must not contain data in the querystring,
> hash,
> > or POST body.  Of course the request has already gone out, but the
> response
> > will be blocked (or redirected), not rendered in the browser.
> >
> > With that in place we can do a lazy manifest download, no sync requests
> > necessary.
> >
> > You could undoubtedly point to scenarios where there will be breakage
> with
> > this scheme.  Ultimately EPR is opt-in though.  I think if we walk
> through
> > various scenarios we'll still wind up better off with EPR, and it will
> also
> > be possible for sites to take action to avert any potential breakage.
> >
> > Dave
> >
>