Re: Requesting security review of IndexedDB API

Here are the meeting notes:
https://www.w3.org/2017/01/25-webappsec-minutes.html#item04

On Thu, Feb 9, 2017 at 1:17 AM Joshua Bell <jsbell@google.com> wrote:

> Any further security feedback for Indexed DB from the phonecall on the
> 25th?
>
>
> On Sun, Jan 22, 2017 at 11:40 PM, Jochen Eisinger <eisinger@google.com>
> wrote:
>
> Thanks!
>
> fyi, we've got the indexed db api scheduled for our next phonecall on the
> 25th
>
> On Fri, Jan 20, 2017 at 7:28 PM Joshua Bell <jsbell@google.com> wrote:
>
> I filed https://github.com/w3c/IndexedDB/issues/139 to track this.
>
> I realized that RegExp can be used as a vaguely similar example. I don't
> think any UA actually serializes the compiled regex, but conceptually they
> could and it would lead to a similar class of problems.
>
> On Tue, Jan 17, 2017 at 10:17 AM, Joshua Bell <jsbell@google.com> wrote:
>
> FWIW, the closest I can find to a "spec" for WASM's behavior is:
>
> https://github.com/WebAssembly/design/blob/master/JS.md
>
> ... which seems to imply that the UA must always store the portable binary
> format, and optionally may store the internal compiled version but that may
> need to be recompiled.
>
> A note still SGTM but I'll wait for others to chime in.
>
>
> On Tue, Jan 17, 2017 at 9:44 AM, Joshua Bell <jsbell@google.com> wrote:
>
> On Sat, Jan 14, 2017 at 6:23 AM, Jochen Eisinger <eisinger@google.com>
> wrote:
>
> Hi & Happy New Year to you as well :)
>
> I'm not sure what the expectations here are, but I wouldn't mistake the
> lack of response as a sign-off :-/
>
> I only briefly skimmed the questionnaire responses. You say that the spec
> doesn't introduce new script loading mechanisms. However, afaik it allows
> for storing compiled WebAssembly binaries in an indexed db that can be
> retrieved and executed at later points in time, no?
>
> In general, what would happen if the user agent gets updated between a
> store of such an object and the retrieval, and the UA no longer can (or
> wants to) understand the old format?
>
>
> That's an excellent question for the WebAssembly folks.
>
> From an IndexedDB perspective it's following the "Structured Clone"
> behavior from HTML when storing/retrieving data. It has no innate knowledge
> of the types being cloned, and no type-specific behavior for values.
>
> (Slight caveat: it can extract keys from a very limited number of
> explicitly named types where the properties are not simple JS properties,
> but that doesn't affect the storage/retrieval)
>
> It seems to me that we should add a note to IndexedDB about version skew
> on stored/retrieved data being something the UA needs to be concerned
> about, and that it must not introduce additional behavior to the operation
> of Indexed DB (i.e. a record can't simply disappear, or fail to be
> retrieved).
>
> (The last I recall from chatting w/ WASM folks we'd agreed that you'd
> always get a module object back out but it may not be usable, although
> that's again outside the bounds of IDB)
>
>
>
>
> Best
> Jochen
>
> On Fri, Jan 13, 2017 at 3:16 PM Léonie Watson <tink@tink.uk> wrote:
>
> On 07/11/2016 13:02, Léonie Watson wrote:
> > Hello WebAppSec,
> Hello again, and belated happy NY.
>
> >
> > The WebPlat WG would like to request a security review of the IndexedDB
> > API specification [1].
> > If it is possible for you to complete the review by 8th January 2017, we
> > would appreciate it. If this does not give you enough time, please let
> > me know.
>
> I don't think we heard from you, so we'll be moving this spec forward on
> the assumption that all is ok from the security point of view. If you
> think it should be otherwise, please let me know? Thanks.
>
> Léonie.
>
>
> >
> > Thanks.
> > Léonie on behalf of the WebPlat chairs & IndexedDB editors
> >
> >  [1] https://www.w3.org/TR/IndexedDB-2/
> > [2] https://github.com/w3c/IndexedDB/issues/
> >
> > Questionnaire responses...
> >
> > 3.1 Does this specification deal with personally-identifiable
> information?
> > No.
> >
> > 3.2 Does this specification deal with high-value data?
> > No.
> >
> > 3.3 Does this specification introduce new state for an origin that
> > persists across browsing sessions?
> > Yes - it defines a storage API, equivalent in persistence behavior to
> > Web Storage's localStorage API.
> >
> > 3.4 Does this specification expose persistent, cross-origin state to the
> > web?
> > Through the use of quota probing (e.g. store data incrementally until
> > QuotaExceededErrors are returned) it may be possible to estimate the
> > amount of storage
> > available on the device, depending on the heuristics the user agent uses
> > to allocate quota to storage APIs and origins. If the storage amount is
> > stable
> > it could be used for fingerprinting. This can be mitigated by decreasing
> > entropy (e.g. binning values to make it more difficult to distinguish
> > users).
> >
> > 3.5 Does this specification expose any other data to an origin that it
> > doesn’t currently have access to?
> > No.
> > As an aside, Indexed DB does not currently allow the storage of Response
> > objects (opaque or otherwise) since they are not currently "structured
> > cloneable".
> > Therefore, storage quota side-channel attacks against cross origin data
> > that affect the Cache API (from Service Worker spec) do not apply; see
> > https://tom.vg/2016/08/request-and-conquer/
> >  for more details.
> >
> > 3.6 Does this specification enable new script execution/loading
> mechanisms?
> > No.
> >
> > 3.7 Does this specification allow an origin access to a user’s location?
> > No.
> >
> > 3.8 Does this specification allow an origin access to sensors on a
> > user’s device?
> > No.
> >
> > 3.9 Does this specification allow an origin access to aspects of a
> > user’s local computing environment?
> > No.
> >
> > 3.10 Does this specification allow an origin access to other devices?
> > No.
> >
> > 3.11 Does this specification allow an origin some measure of control
> > over a user agent’s native UI?
> > No.
> >
> > 3.12 Does this specification expose temporary identifiers to the web?
> > No.
> >
> > 3.13 Does this specification distinguish between behavior in first-party
> > and third-party contexts?
> > The specification allows user agents to restrict access to the database
> > objects to scripts originating at the domain of the top-level document
> > of the browsing
> > context, for instance denying access to the API for pages from other
> > domains running in iframes.
> > (Called out in Privacy/User tracking section)
> >
> > 3.14 How should this specification work in the context of a user agent’s
> > "incognito" mode?
> > Browsers may implement an "memory-backed" store rather than
> > "disk-backed" store in incognito/private browsing mode. This allows the
> > feature to exist and
> > function in such a mode.
> > Note that probing through timing (RAM is usually faster than disk) or
> > quota (memory may be more limited than disk) it may be possible to
> > distinguish this
> > approach; this potentially affects all storage APIs.
> >
> > 3.15 Does this specification persist data to a user’s local device?
> > Yes. "Clear browsing data" for an origin must remove all Indexed DB data
> > for the origin (all databases, and all data and metadata within those
> > databases).
> >
> > 3.16 Does this specification have a "Security Considerations" and
> > "Privacy Considerations" section?
> > Yes.
> >
> > 3.17 Does this specification allow downgrading default security
> > characteristics?
> > No.
> >
>
>
>
>
>
>