Re: Requesting security review of IndexedDB API

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