9 ms·
MongoDB will not prevent NoSQL injections in your Node.js app
- overcast 10y agoEvery time I read these MongoDB articles, I question why RethinkDB didn't rise up.
- ecares 10y agoSo do I
- hashkb 10y agoWe all ran back to Postgres and realized life wasn't so bad?
- overcast 10y agoMeh, 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 10y agoBy "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 10y agoI mean free "open source", SQL databases.
- williamstein 10y agoI'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.
- raverbashing 10y agoWell, do PostgreSQL magically prevents SQL Injection attacks if you pass unsanitized data to it? It's the same thing here
- ralfn 10y agoYes 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.
- starptech 10y agoThat kind of issue has nothing to do with Mongodb. He could even use RethinkDb.
- ralfn 10y agoThat 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 http://rethinkdb.com
- starptech 10y agoYes, 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.
- taylorwc 10y agoNoob 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?
- deleted 10y ago[deleted]
- ecares 10y agoNot 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 10y agoThe 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 10y agoAs 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 10y agoI 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 --
- starptech 10y 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 https://github.com/hapijs/joi. Someone who doesn't validate his payload and pass it up to the driver should not be surprised.
- mnarayan01 10y agoIf 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_ 10y agoThis 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_ 10y agoTo 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>] }