Re: Avoiding syncronous manifest requests in EPR

Adding a DOM-accessible value is tricky.  The admin now needs to put an
inline security script at the top of every single bit of HTML markup they
serve that could potentially be vulnerable to XSS.  It's already burdensome
enough that they need to apply the X-EPR header pervasively.  And if they
don't get the script right then the injected XSS payload can win the race.
 (The similar example to this I've seen is framebusting script.  I can only
imagine it would be painful to emulate that model.)  I'd prefer to just
avoid all this and have the browser take care of the problem via a standard
mechanism.

Regarding the attack based on XSS in the path...  Don't let the perfect be
the enemy of the good.  EPR is already pragmatic in the sense that it won't
protect against XSS that is on an entry point, persistent XSS, etc.  While
XSS in the path definitely exists, I haven't seen that it is pervasive
enough for me to worry about not covering it in this case.  I also think
that there are some simple extensions we can make to the NODATA rule if we
wanted to further harden against this threat.

I worry more about making sure we have something that is compatible,
performant, and usable rather than something that is capable of mitigating
all conceivable XSS / XSRF attacks.  If we don't get compat, perf, and
usability right, this approach is 0% effective because EPR just won't be a
thing.

Dave

On Sat, Nov 8, 2014 at 10:14 PM, Devdatta Akhawe <dev.akhawe@gmail.com>
wrote:

> To clarify my concern:
>
> Imagine I have an app that has the following routing config :
>
> map.connect('/options/*path', controller='options', action='path_options')
>
> The way this works in my imaginary framework is that /options/foobar
> will call options.path_options with the argument path set to the value
> in the URI. So the path of the argument is part of the input to the
> controller.
>
> Now, lets say this app turns on EPR and the browser sees a navigation
> to /options/<script>alert</script>
>
> The browser will see the X-EPR header in the response but it doesn't
> have a manifest. The NODATA trick will not block the payload here, if
> I am not wrong. And, worse, I don't see a mechanism to protect this
> pattern with the NODATA trick; the mechanism I proposed where the
> app can check status of manifest checks does provide the possibility
> of protecting such apps.
>
> This pattern is actually not that uncommon. For example,
> mail.google.com/mail/u/*user_id/ is an input in GMail, wikipedia is
> en.wikipedia.org/path/*article
>
> Arguably, this is not that big a concern and XSS in such routes are
> uncommon, but I worry about standardizing something that has this
> issue.
>
>
> cheers
> Dev
>
>
> On 6 November 2014 15:46, David Ross <drx@google.com> wrote:
> > 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
> >> >> >
> >> >
> >> >
> >
> >
>