Re: Avoiding syncronous manifest requests in EPR

Yes, I agree the spec should provide clarity on these points.

Re compat: Well, first off I'd just say that EPR overall is opt-in.
There's a certain amount of work web devs will need to do if they opt-in to
EPR, which involves creating a manifest and setting the response header
pervasively.  But if they don't opt-in, there's no compat burden, though I
guess you could say that implementation of EPR on a site outside of their
control could break their links.

In terms of the NODATA concept specifically, you'd potentially see breakage
if a site links to or frames another site AND all of the following
conditions are met:
  - It's a navigation (as opposed to a resource request).
  - It's a request with querystring, hash or POST data.
  - No EPR policy was previously fetched / cached locally that would
otherwise allow the resource load.

It would probably still be more common to see breakage simply due to sites
that *do* implement EPR and in doing so intentionally block access to
resources.

I think it's also important to set the right expectations about who might
want to use EPR.  There are some scenarios where EPR is extremely useful /
valuable.  That would be:

   - Application platforms that build on the web, offer powerful
   functionality (eg: webcam access), and rely solely on CSP to offset the
   risk.  EPR would provide a different lockdown mechanism that would be more
   palatable to developers in some circumstances.

   - Sensitive and somewhat isolated web apps.  The perfect example: a web
   admin console

At the opposite end of the spectrum, EPR would not be a great option for
large public web sites that look more like a smorgasbord of linkable
content, eg: cnet.com.

Dave

On Tue, Nov 4, 2014 at 9:05 PM, Devdatta Akhawe <dev.akhawe@gmail.com>
wrote:

> On 4 November 2014 12:38, David Ross <drx@google.com> wrote:
> > 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
> <snip>
>
> > 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
>
> I think these are the two things at odds here: there is the extra work
> for the developer but, I think, that also makes the limitations more
> clear. And the option you propose which I worry has this hard to
> define guarantee of "we protect against reflected XSS, but only if
> payload is in one of the ... or someone tricked the user to copy paste
> the URI or someone tricked the user to bookmark"
>
> I personally prefer the former, because I think that a spec shouldn't
> have caveats like these. But I understand your points too. In either
> case, the spec should make limitations clear.
>
> IIRC, you have been testing a prototype implementation: any sense of
> compatibility issues, if any, if we go the NODATA root?
>
> cheers
> Dev
>
> >
> > 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
> >> >
> >
> >
>