PouchDB and security

[Lubo Slivka]

Hi,

I am currently evaluating PouchDB for my next project. I am really happy functionality wise - the PouchDB team is doing great job.

My current (and only) dilemma is related to security. I am considering having documents that are personal to the signed in user in PouchDB and replicating both ways between client and server. The user can then use a good bulk of the application even when offline. Of course I would not be storing and replicating passwords, credit card numbers and other very sensitive information.

The online sources that I have found (such as https://code.google.com/p/html5security/wiki/WebSQLDatabaseSecurity) make me paranoid when considering PouchDB. To further my paranoia I was unable to find any security-related articles for PouchDB. 

Some basic questions pop into my mind:

- What prevents malicious user with tampering with PouchDB database which then gets replicated to the server? Can this be a breeding ground for DoS attacks when bad data gets replicated to the server?

- In case site contains XSS vulnerability, is there anything that would prevent attacker replicate client's database over to their own CouchDB? Indeed, when XSS happens its over with or without PouchDB. However PouchDB replication seems to make getting hold of personal user data incredibly simple (one call to replicate if I understand it correctly).

Since I'm not a web and security expert, I'm looking for advice / expert explanation here. It may very well be that I am misunderstanding some core concepts or completely missing out on important stuff. 

I would greatly appreciate any guidance, experience and expert opinions from members of this group.

Thank you very much,

Lubo

[no...@nolanlawson.com]

Very interesting question, thanks for bringing it up.

- What prevents malicious user with tampering with PouchDB database which then gets replicated to the server?

Zilch. On Chrome anyway, you can easily go into the file directory and find both a LevelDB database (for IndexedDB) and SQLite databases (for Web SQL) that you can open up and view directly. So if someone has access to your user's computer, they have access to the local files.

- In case site contains XSS vulnerability, is there anything that would prevent attacker replicate client's database over to their own CouchDB? Indeed, when XSS happens its over with or without PouchDB.

The best "security" in this case is that you cannot enumerate all IndexedDB/WebSQL databases in a consistent cross-browser way (although the developer tools expose some browser-specific APIs IIRC). But of course that's not terribly secure; an attacker could just guess the database name or know it in advance.

In the native app world, the solution for the longest time has been SQLCipher. In the web world the best you can do is the following:

1) Use Web Crypto on those browsers that support it.

2) Use filter-pouch to encrypt documents as they are put into the database and decrypt them as they are retrieved.

The nice thing about this solution is that the files would be encrypted on both the user's device and when sent to the remote CouchDB, so even you would not be able to unlock them. However, if the user lost their password, they would be SOL unless you came up with a fancier scheme.

Cheers,

Nolan

[step...@shimaore.net]

> - What prevents malicious user with tampering with PouchDB database which
> then gets replicated to the server?

You should assume the user manipulates the PouchDB content.
On the server side you should use a per-user database, and validate
updates both ingress to that database (for consistency) and (more
importantly) ingress to any database(s) that might replicate or import
from the per-user database.

In the security model I use, the user can manipulate their server-side
per-user database's content (except for design documents), therefor that
content is actually the one I validate when it is pushed to a separate
database.

In other words the security boundary is set at the server-side
user-database, and the PouchDB replica is included in the "insecure"
area along with the per-user database.

> Can this be a breeding ground for DoS
> attacks when bad data gets replicated to the server?

Can you describe a scenario where the data could be used for Denial of
Service (which in my book is a completely type of threat and needs to be
mitigated using regular tools for HTTP/HTTPS protection)?

> Indeed, when XSS happens its over with or without PouchDB. However PouchDB
> replication seems to make getting hold of personal user data incredibly
> simple (one call to replicate if I understand it correctly).

Personal information should be stored encrypted using client-side
(in-browser) encryption to address this and similar concerns regarding
other users having access to the same browser, etc.
S.

--
tel:+33643482771
http://stephane.shimaore.net/

[Dale Harvey]

It would be easier to talk about security in the context of an attack you are looking to mitigate

PouchDB doesnt have much implications on XSS, if a remote attacker can run code on your browser, the difficulty between calling db.replicate(myserver) and a script that dumps an database to a remote server is trivial, the only mitigations to xss are the same whether pouch is involved or not.

As the previous replies mentioned, you should definitely consider data being replicated to the server untrusted, the database per use scheme gives an easy way to compartmentalise data that can only be accessed by the correct authenticated client.

--
You received this message because you are subscribed to the Google Groups "PouchDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pouchdb+u...@googlegroups.com.
To post to this group, send email to pou...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pouchdb/20141013122603.GA10976%40shimaore.net.

For more options, visit https://groups.google.com/d/optout.

[Lubo Slivka]

Thanks Stephane, I found this very useful.

What I had in mind regarding the DoS 'thing' is: can malicious user craft their local DB so that when replicated to server it will trigger a lot of expensive processing that will overwhelm the server? 

Lubo

[Johannes Jörg Schmidt]

A note about filter-pouch: As I understand the Note on query() in this case the decrypted plain content would be stored in the view index. So either filter-pouch or persistent views cannot be used without exposing data to anybody who has access to the computer, when the view is persisted to disk.

@nolan, am I right?

--

You received this message because you are subscribed to the Google Groups "PouchDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pouchdb+u...@googlegroups.com.
To post to this group, send email to pou...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pouchdb/23c892cd-dcdc-45cd-a2f4-7c9dbd55da34%40googlegroups.com.

[step...@shimaore.net]

Hi Lubo,

> What I had in mind regarding the DoS 'thing' is: can malicious user craft
> their local DB so that when replicated to server it will trigger a lot of
> expensive processing that will overwhelm the server?

As long as they can replicate and query views, an attacker wouldn't have
to "craft" a local database, but simply use the APIs -- so PouchDB in
itself isn't the point there. :}
S.

[Lubo Slivka]

Thank you all for replies - the answers helped me gain better understanding and provided new perspectives.

Hopefully some of the information mentioned in this 'thread' will eventually make it into the official PouchDB documentation to prevent unfortunate misunderstandings.

Have a nice day,

Lubo

[no...@nolanlawson.com]

No, that's not quite right. Maybe I should make the docs clearer.

If you use a new PouchDB() where you call .filter(), then it will decrypt when it sends stuff to CouchDB. So CouchDB will see data in the clear.

If you access the same local data where you DON'T call .filter(), and then replicate that to CouchDB, then CouchDB will only see encrypted data. Hence remote map/reduce will not work correctly.

You have the option of doing both, depending on whether you think it's important to encrypt the remote data or not.