I recently read this article on NoSQL injection:
I thought to myself how bad can one possibly exploit this. Turns out its real bad!!!
If the attacker use $lookup in an aggregation, it can pull ALL the data from ANY collection, not only the collection the query is executed on. Thus if you don’t secure your aggregation queries and an attacker injects a $lookup stage into a pipeline, even in deeply nested $facet pipeline, your entire database is exposed.
I’ve gone through some trouble to lock up collection names and I scan all pipeline queries on the server before executing an aggregation. I’m not aware of a quick fix, please let me know if there is. The $lookup stage in aggregation is not widely used but one must understand its use to protect against this.
Check out tutorials on how to prevent SQL injection. Same thing as NoSQL injection. As far as i know though, you must implement good validation checking and maybe limit the size of input strings. Also prevent special characters where not needed.
Yes. I understand. But its not always that simple. Sometimes you want to send filter objects and so on for the client to “explore” the data in various ways. It can be very powerful if the client change the query pipeline through the ui.
Guess the easiest mistake to make here is that a developer can assume he exposes only one collection to the user through an aggregation on that same collection - the client’s own data - when infact you are exposing the entire database if not careful…
1 Like
I think it’s good to call this out, but the underlying issue here is lazy coding. If a Mongo query object is allowed from the client then you’re asking for trouble. It’s always better to only allow sanitised meta-objects which can be fully validated - at its simplest that’s “perform query #99”.