W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2017

Re: Requesting security review of IndexedDB API

From: Joshua Bell <jsbell@google.com>
Date: Wed, 8 Feb 2017 16:17:09 -0800
Message-ID: <CAD649j4eEr8KjQXNvdjjVtmpF1w7X-c5fCiszVdxTves+_VBBQ@mail.gmail.com>
To: Jochen Eisinger <eisinger@google.com>
Cc: "tink@tink.uk" <tink@tink.uk>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Ali Alabbas <alia@microsoft.com>, "Xiaoqian(Cindy) Wu" <xiaoqian@w3.org>
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.
>> >
>>
>>
>>
>>
>>
Received on Thursday, 9 February 2017 00:17:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:22 UTC