
MongoDB will not prevent NoSQL injections in your Node.js app - ecares
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
======
starptech
"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](https://github.com/hapijs/joi). Someone who
doesn't validate his payload and pass it up to the driver should not be
surprised.

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

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

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

~~~
overcast
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.

~~~
untog
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.

~~~
overcast
I mean free "open source", SQL databases.

~~~
untog
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.

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

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

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

