[cap-talk] Ambient authority in the Web Geolocation API

Mark Seaborn mrs at mythic-beasts.com
Tue Nov 24 00:32:09 PST 2009


On Wed, Nov 18, 2009 at 11:28 PM, I wrote:
> I have been trying to come up with a way that the ambient authority in the
> geolocation API might get exploited.  I have come up with a hypothetical
> example but it might be far-fetched.
>
> Suppose FooMaps.com is a mapping site that allows external sites to provide
> custom image-tile overlays.  It allows you to specify a base URL for the
> image tiles as a URL parameter.
>
> So, for example, you would visit
> http://foomaps.com/map.py?overlay=http://bar.com/image.cgi
> and the resulting page would create <img> elements linking back to
> http://bar.com/image.cgi?x=1234&y=4567

(It looks like Gmail mangled the example URLs above when I posted
before, so I'm quoting the non-broken version.)

> If an attacking page from mallet.com wishes to determine the user's
> location, it can create an invisible iframe linking to
> http://foomaps.com/map.py?overlay=http://mallet.com/user-id/image.cgi, and
> mallet.com can infer the user's location based on the HTTP requests it
> receives.

I should clarify what I meant because I got some some feedback saying
my example was busted. :-)

I don't mean to say that it is possible to prevent foomaps.com from
disclosing the user's location to another site.

What I mean is that foomaps.com might start out with with a
URL-parameter feature, and then become vulnerable to a confused deputy
attack if it naively adds a geolocation feature without considering
how it interacts with the earlier URL-parameter feature.  mallet.com
is exploiting the foomaps.com's ambient authority here.  The authority
is ambient because persistent geolocation authorisations are granted
using a same-origin policy, and the authorisations are honoured even
for iframes in current implementations.

Suppose geolocation authorisations followed a password-capability
model instead, using an entirely different API.  When a web app's
request to receive geolocation updates is granted by the user, the
browser would return a token (a string) which the web app can present
to the browser in the future in order to read geolocation data.  The
web app is responsible for stashing this token away somewhere.  It
could save it in a cookie or save it using the newer DOM storage API
-- in these cases, we would still have an ambient authority problem,
because these interfaces are based on ambient authority too.  But the
web app also the option of not using cookies at all, and of saving the
token in a URL-capability (either embedded in the URL-cap, or with the
URL-cap as an index into a server-side store).  Admittedly that is not
ideal because URL-caps have some usability problems.  It is basically
reducing the problem to a previously unsolved problem. :-)

My point is that same-origin-based persistent geolocation
authorisations, like DOM storage, are another kind of ambient
authority *that web apps cannot opt out of using* if they want this
functionality, whereas web apps can opt to use URL-caps instead of
cookies.

The token model may be worth considering because it could allow local
resources to be granted to web apps in the same way as resources on
remote servers.  For example, the following could all be granted using
roughly the same mechanism:

 * camera device
 * geolocation
 * access to quantities of local storage space
 * access to specific local files
 * ability to read the contact list in my e-mail web app

Those resources that are local (the first four) could be implemented
using a local, privileged web server, rather than requiring the
functionality to be built into the web browser.  Web apps that are
granted these resources could communicate with the local web server
using postMessage() on iframes or using Uniform Messaging [1].

Mark

[1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0914.html


More information about the cap-talk mailing list