Re: [w3c/IndexedDB] API to enumerate databases (#31)

> Google Chrome have also removed their webkitGetDatabaseNames()

Their reason for removing it is quite clearly spelled out at that link and it has nothing to do with security/privacy.

> Imagine a family where the boy is gay and registered on a gay website with the family computer. If the website want to store user's private information in a IndexedDB, but secretly with a database name from a derived key of the login/password of the user. With your new feature, it's possible for the father with little JavaScript knowledge to list the databases and to discover that his son is registered on this gay website.

This is pretty much FUD.

Let's say the son registers at "https://www.gaybook.com/" and it stores some information in a local IndexedDB.

Every browser already lets you natively list which websites have data stored on your local machine, and "https://www.gaybook.com/" would show up in that list already.

If this API is added, it doesn't really change the situation. The father now *could* know ahead of time to open a tab to "https://www.gaybook.com/" so he's executing javascript in the "https://www.gaybook.com/" origin and list all the databases...  but he already had the native ability to list databases in the browser.

Any time an attacker has physical access to the machine you've already lost. The only protection for this concern is to user different user accounts, encrypted home directories, etc etc. 

> There is a big buzz around PWA, and if it's the future, this mean all websites will store more data inside IndexedDB to prevent offline problem. So, if the website is well designed, each user on a device will have a separate database with random names. With your new feature, it's possible for a JS Coder / XSS attack to connect to theses private database to steal theses information.

The bug in this scenario is the XSS attack itself, not the DB feature.

If the website is well enough designed to have truly unguessable names for each user's DB (probably not!), then it's probably also well enough designed to not have this XSS vulnerability.

In the presence of the XSS attack, the user's data is already vulnerable whether or not this convenience method exists.

> WebCrypto API permit to generate keys, to prevent extraction and to store directly the CryptoKey inside IndexedDB. This is really useful, but this need to be stored inside a unguessable random database name. This random name is only known by the server and sent to the client if the login/password are correct. With your new feature, this break this security design and make WebCrypto sign/verify features useless.

Again, you are assuming an XSS vulnerability here. You are also assuming "security by obscurity" which should not be a technique used by any truly secure website.

---

Let's define for a moment that XSS-vulnerable web sites are broken.
Do you have any concerns for attacks that this API would truly *enable* on a non-broken website, and not simply make a little more convenient?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/31#issuecomment-339057026