Re: Avoiding syncronous manifest requests in EPR

I've updated the prototype implementation of EPR (
https://github.com/google/epr/) to request manifests asynchronously.  The
new code follows the "NO DATA" scheme described in the first message of
this thread.

On Thu, Nov 13, 2014 at 11:17 AM, David Ross <drx@google.com> wrote:

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