Hacker News Reader

Comment by yatsyk | Hacker News Reader

It’s trivial to limit number of created documents in postgres, couchdb or application server though validation, I’m talking about updating document not creating new. In posgres if I update 1mb document used space will not always grow. In couch db situation is different. In case of relation db you have application server with custom logic and validations, couchdb from other side is accessible from outsize.

My idea that it’s very hard to create safe couchdb based system and most recommendations limited to setup nginx proxy and authenticate users which is not enough.

View on HN

> It’s trivial to limit number of created documents in postgres, couchdb or application server though validation, I’m talking about updating document not creating new. In posgres if I update 1mb document used space will not always grow. In couch db situation is different. In case of relation db you have application server with custom logic and validations, couchdb from other side is accessible from outsize.

It is? It's unclear to me why I'm allowing 10 updates to a (largish, 10MB! Use a file or store it in S3!) document per-minute, but not 10 creates. Maybe I'm building Google Docs? Except I'd want old revisions, so those are creates. Plus 10 Mb is a huge spreadsheet. But sure lets roll with it. Actually Couch does not keep old versions of documents around, only old revision numbers. When a document is updated, the old version becomes eligible for compaction (basically garbage collection). So your attacker has to be fast enough to outrun the compactor, while being slow enough to not get temporarily banned from your service. It seems like less effort to me to use this power to flood your network I/O, which is almost certainly lower than your disk I/O. Or just choke your Postgres server on it's 100Mb/s disk I/O for updates + whatever is required to maintain your indexes.

I'm not actually advocating for Couch over Postgres. In my mind Postgres should be the default choice, and you switch to something else if you have a reason. For Couch, the biggest reason is sync is built in, in such a way that you can leverage it for your own applications with minimal effort. In my experience sync can be devilishly hard for non-trivial cases, so depending on your app, that can be pretty compelling.

But so far you seem to be focused on DOS attacks your not going to find separate advice for Postgres vs Mongo vs Couch, because the backing system doesn't matter. The attacks and mitigations are identical no matter the back-end, namely stop the traffic before it consumes your resources.

Couch is not equivalent to mongo or relational because it accessible to clients if we want synchronisation. Securing app server is manageable problem and there is huge number of resources how to do it correctly.

In case of couch I've not seen any secure open-source example.

I'm not focused on DOS attacks, I'm just proposing different attack vectors.

Is it trivial? Let’s say you have a back end and an app that lets you post comments, like this site. How do you stop someone from spamming comments? Each comment is represented by a row in a table so the space will grow.

If you need to limit the number of items it is trivial. You need to write something like `has_many :things, :before_add => :limit_things` in app server or create constraint in sql.

Spam prevention is not trivial but mostly solved problem. You can find a lot of articles about this topic.

But creating secure couchdb looks like very non-trivial.

Yeah... that's a Rails callback, not an SQL constraint, and can't be relied upon in the face of multiple simultaneous requests. Which kind of demonstrates my point. With a custom API, you have to understand your system, it's requirements, and it's limitations. You can't just read a blog post on "securing your webapp" and assume it's good.

Couch is no different. You have to understand Couch, you have to understand it's features and limitations, and build your system within those constraints.

You seem to be asserting because Couch is designed to be internet connected it can't be secure. If that's true, then I guess every customer on IBM Cloudant (Couch as a service), Realm (another database designed for mobile sync), and Firebase (Google database as a service) are all in trouble and just don't know it yet.

Security for all systems is non trivial. Thinking it is assures your system is not secure.

I'm not asserting that couch is unsecure, I need such database but the problem that I can't see any resource that could help me design secure production system.

You can check even trivial rails blog or todo example from some book and it will be limited in scope but more or less secure. I'm having hard time to find secure couchdb example.

> Security for all systems is non trivial. But not equally hard.

If you use firebase you should understand that you getting vendor lock-in and in some cases you can spend much more money, but for some types of projects this platform is ok for me.

Same with couchdb, I understand that if I get replication with client, I need to pay by reorganising data or may be spend more resources to make system secure. There is no free lunch.

You are comparing apples to oranges. Again, are you imposing a hard constraint on the number of comments someone can make?

With the example o gave you could have a constraint in CouchDB achieve the effect but there are simply other examples one could use.

No I'm not assuming constraint on the number of comments. First example shows how easy limit number created objects. Spam prevention is other topic not so trivial but mostly solved problem.

Reply on news.ycombinator.com