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

https://blog.sqreen.io/mongodb-will-not-prevent-nosql-injections-in-your-node-js-app/?utm_content=buffer25729&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

by ecares • 10 years ago

36 23 10 years ago

blog.sqreen.io

overcast3• 10 years ago

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

ecares2• 10 years ago

So do I

hashkb• 10 years ago

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

overcast3• 10 years ago

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.

raverbashing• 10 years ago

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

It's the same thing here

ralfn2• 10 years ago

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.

starptech3• 10 years ago

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

ralfn2• 10 years ago

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

taylorwc• 10 years ago

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?

ecares2• 10 years ago

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.

dozzie• 10 years ago

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.

wcarron• 10 years 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.

virmundi• 10 years ago

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 --

starptech3• 10 years ago

"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.

mnarayan01• 10 years ago

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.

asher_2• 10 years ago

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.

asher_2• 10 years ago

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>] }

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

Related Stories