Re: Avoiding syncronous manifest requests in EPR

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

Received on Wednesday, 5 November 2014 05:06:36 UTC