MongoDB will not prevent NoSQL injections in your Node.js app | Hacker News Reader

MongoDB will not prevent NoSQL injections in your Node.js app

blog.sqreen.io

36 pointsecares23 comments

"NoSQL means Not-injectable, right?" makes no sense for me. It doesnt matter which type of database technology you are using. As any other database there are security roles. No mongodb query should be executed as an admin. You can restrict that up to document level. You can even create read-only views. You should always validate you payload. Use e.g Joi https://github.com/hapijs/joi. Someone who doesn't validate his payload and pass it up to the driver should not be surprised.

This isn't injection at all. No commands other than the find are being performed. Little Bobby Tables (Little Bobby Collections?) will not have any luck here.

In addition to the fact that you can't execute arbitrary commands with this example, the example itself is flawed. If the programmer's intention was to exclude "secret projects" from all searches, then they should have written the query to do that. They didn't, and allowed multiple other ways of accessing those records.

Writing some code that does something different to what you intended it to do is not a NoSQL injection, it's just bad code.

To expand on this..

You could use $exists, $gt, $eq, $ne, $in, $nin, regex, and all kinds of other ways to query what you want.

If the programmer wanted to exclude "secret projects" the query should have had a form similar to

{ $and: [{ type: { $ne: 'secret projects' }}, <rest of query>] }

Every time I read these MongoDB articles, I question why RethinkDB didn't rise up.

So do I

We all ran back to Postgres and realized life wasn't so bad?

Meh, MySQL is by far the dominant in that sector. RethinkDB is exactly what I need for most of my projects, relational, real time, document storage.

By "that sector" you mean SQL databases as opposed to NoSQL? I'm finding Postgres' JSON column types to be very useful in working with NoSQL-y document structures.

I mean free "open source", SQL databases.

At least Postgres has proper SQL support and can handle CHECK constraints.

I'd argue that Postgres doesn't belong just in that sector, then, given that it can be used for many of the roles Mongo/Rethink are used in.

I'm rewriting all of my large amount of RethinkDB client code using PostgreSQL right now (including using their JSONB and LISTEN/NOTIFY functionality), and loving it.

Well, do PostgreSQL magically prevents SQL Injection attacks if you pass unsanitized data to it?

It's the same thing here

Yes both have query languages that are not native to your application (i.e. to your application it is data, such as a string or a json). But that is design flaw of SQL and MongoDB and does not apply to all databases.

That kind of issue has nothing to do with Mongodb. He could even use RethinkDb.

That is wildly inaccurate. RethinkDB provides client drivers that model the rethinkdb queries in Javascript, so data and query are not combined into some horrible JSON query language (MongoDB) or horrible string based language (SQL). Input data is treated as is. No part of it will ever be interpreted as a query unless you decide to eval() your input data.

Get informed: http://rethinkdb.com

Yes, but you can also pass the payload to the filter function and allow injecting custom conditions.

r.table('users').filter(<here>).run(conn, callback);

of course if you use the chainable syntax

r.table('users').filter(r.row("age").eq(30)).run(conn, callback);

you can prevent it but that's not the point. It has nothing to do with Mongodb.

Noob question. I get that this is a problem and what it could do, but wouldn't doing simple checks and validations of any client input solve this problem?

Not a noob question ;) As stated in the presentation at the end of the article, data validation is one of the methods to prevent such attacks. Soon, there will be a new article offering a few methods to reduce risks in this area.

The problems are to a) get to the point when all your input is validated and b) stay there. It's easy to validate some data, it's horribly difficult to validate it all (or rather, it's horribly easy to forget something).

Exactly the same could be said about SQL injection, and its solution is prepared queries with value placeholders, which is an idea over a dozen years old. Apparently MongoDB has not caught up yet with SQL from decade ago.

As another poster replied: Yes, validation is one method to reduce the methods of attacking. Client side is essentially useless in these cases, since they can just bypass the gui by sending HTTP requests (which can then contain the db methods) from the command line.

What is needed is server side validation. Pretty much the same as client side, but most of the time a bit more robust. The problem is validating ALL the input. Like, creating this comment. Validation is really easy for this comment.

But what about something where you upload images? PDFs are well known attack vectors. So are SVGs. How can you be sure there's nothing hiding in those? It's possible. It just becomes increasingly difficult to cover each case.

I find it odd that in 2016 we don't have a better way of centralizing that type of logic better. I don't know of a single framework that will generate front end logic from annotations on a class and then run the logic against the same annotations on the server. Spring gets you half way. Not the rest.

-- edit grammer --

If you're letting users query against a collection using a fairly arbitrary filter, then not having something to ensure they are authorized to view (or update, etc.) the results is almost certainly a mistake. Also describing $gte as a "command" seems misleading; if you could use $where in embedded queries it would maybe be a different story, but since I don't think you can, this seems hyperbolic.

Reply on news.ycombinator.com