On 04/24/2014 12:25 AM, Jonas Sicking wrote:
Even though you could link to resources in local databases, how would
you then extract data and send it to the server? Simply displaying an
image from the database could be surprising/scary to the user, but
doesn't actually extract any sensitive information.
The information leak is akin to CSS :visited attacks a la
http://dbaron.org/mozilla/visited-privacy
In this case the information channel is either in the timing delta of
multiple external resources fetches, missing subsequent external
resource fetches, or as you alternately propose, entirely conditional
resource fetches.
Another solution is to define that sandboxed pages with scripts
disabled can't load from local urls. At least not unless explicitly
allowed by some new sandbox flag.
This seems unintuitive.
I think the simplest/best option is just to not expose/map the indexedDB
URI scheme unless it is explicitly requested. Say as a parameter for
opening the database. An argument against this would be if we thought
it would make sense for a URI access to go and open an IndexedDB
database on its own. Given the versioned semantics of IndexedDB and
general sanity, I don't think we would want that.
This addresses my hypothetical example fairly well since it's explicitly
opt-in and if the flag is well-named, even someone fairly blithely
copying and pasting IndexedDB boilerplate has a fair chance of noticing
"exposeDbViaIndexedDBUriScheme: true". (In my example I think I'm
assuming a competent but naive/not super-experienced with the web
platform and information leakage via side-channels. So something like a
magic backdoor URI scheme that exposes the entirety of the database
without requiring an opt-in would be a big vulnerability they wouldn't
be aware of.)
Andrew
_______________________________________________
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
