Re: Requesting security review of IndexedDB API

Thanks Jochen. We’ll forward the request to the Web Sec IG.

-xiaoqian

> On 10 Mar 2017, at 7:31 PM, Jochen Eisinger <eisinger@google.com> wrote:
> 
> Hi,
> 
> please note that WebAppSec isn't doing security reviews for other WGs. That role is part of what the web security IG does: https://www.w3.org/Security/wiki/IG <https://www.w3.org/Security/wiki/IG>
> On Fri, Mar 10, 2017 at 12:26 PM Xiaoqian Wu <xiaoqian@w3.org <mailto:xiaoqian@w3.org>> wrote:
> Hi WebAppSec folks,
> 
> Any progress on this review? We’d like to close the loop if you don’t have any feedback for IDB V2 (before 15 March).
> 
> Thanks.
> 
> -xiaoqian
> 
>> On 9 Feb 2017, at 4:16 PM, Jochen Eisinger <eisinger@google.com <mailto:eisinger@google.com>> wrote:
>> 
>> Here are the meeting notes: https://www.w3.org/2017/01/25-webappsec-minutes.html#item04 <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 <mailto: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 <mailto: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 <mailto:jsbell@google.com>> wrote:
>> I filed https://github.com/w3c/IndexedDB/issues/139 <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 <mailto: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 <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 <mailto:jsbell@google.com>> wrote:
>> On Sat, Jan 14, 2017 at 6:23 AM, Jochen Eisinger <eisinger@google.com <mailto: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/ <https://www.w3.org/TR/IndexedDB-2/>
>> > [2] https://github.com/w3c/IndexedDB/issues/ <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/ <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.
>> >
>> 
>> 
>> 
>> 
>> 
>