Re: Requesting security review of IndexedDB API

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