- From: Joshua Bell <jsbell@google.com>
- Date: Wed, 8 Feb 2017 16:17:09 -0800
- 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>
- Message-ID: <CAD649j4eEr8KjQXNvdjjVtmpF1w7X-c5fCiszVdxTves+_VBBQ@mail.gmail.com>
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