Re: Avoiding syncronous manifest requests in EPR

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

Received on Sunday, 9 November 2014 06:14:58 UTC