Re: Avoiding syncronous manifest requests in EPR

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
>

Received on Tuesday, 4 November 2014 19:21:23 UTC