Re: Requesting security review of IndexedDB API

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