No sql injection in meteor.js application

M E T E O R ( H T T P S : / / B L O G . D E S I G N V E L O P E R . C O M / C A T E G O R Y / M E T E O R / )

NoSQL Injection in Meteor.js Application
FYI:
This is one of two topics of our 2nd Meteor Meetup on July 9th, 2016. The author is Son Le, a young talent member of Designveloper.
Those who were not able to attend our 2nd Meteor Ho Chi Minh meetup (https://blog.designveloper.com/2016/07/11/2nd-meteor-ho-chi-minh-meetup-review/)
at July 9th could nd all about NoSQL Injection in Meteor.js Application – one of the main topics (https://blog.designveloper.com/2016/08/02/how-to-deploy-
and-scale-your-meteor-apps/) of the meetup – in this blog.
Before digging into every facet of this post, you are required to have a fairly good background of Meteor (https://www.meteor.com/) and MongoDB
(https://www.mongodb.com/), which is the most widely used NOSQL database. If you are a Meteor-novice, no worries! You can discover more about this full-
stack JavaScript platform for developing single-page, real time web and mobile apps at Meteor.com (https://guide.meteor.com)
Now, are you ready to get what you missed at our Meetup?
SQL INJECTION
SQL Injection is de ned as a code injection technique, used to attack data-driven applications, in which nefarious SQL statement are inserted into an entry eld
for execution. (Source: Wikipedia)
In other words, SQL injection is a technique where malicious users inject SQL commands into an SQL statement to change it and compromises the security of a
web application with SQL database.
There are 4 common forms of technical implementations of SQL injection:
Incorrectly Filtered Escape Characters with this line of code:
statement = "SELECT*FROMusersWHERE name = '" + userName + "';"
Incorrectly Type Handling:
B y Va n D o ( h t t p s : // b l o g . d e s i g n v e l o p e r. c o m / a u t h o r / v a n d o / ) o n A u g u s t 6 , 2 0 1 6

statement := "SELECT*FROMuserinfoWHEREid=" + a_variable + ";"
Blind SQL Injection:
SELECT*FROMbookreviewsWHEREID='Value(ID)';
Second order SQL injection
I am going to give you an example of Incorrectly Filtered Character. Here I want to get a user data with username Peter and password “$PWQ”, the query looks
something like this:
// query
SELECT * FROMusers
WHERE username='peter’
AND (password=('$PWD'))
If I use a “weird” input, for example:
// input
' OR '1'='1’
The result query is:
// result
SELECT * FROM users
WHERE username='peter' AND (password='' OR '1'='1')
As you can see, the condition (password=” OR ‘1’=’1′) is always true. That’s why the result query is always successful. By this way, attackers can get any
arbitrary user data, given the username.
NOSQL INJECTION
Now, although NoSQL is still a popular attacking technique, it’s no longer as widespread as it used to be. Many modern apps use NoSQL databases such as
MongoDB for its simplicity and speed. Unlike SQL in which queries use STRINGs as the control mechanism, NoSQL queries use OBJECTs instead. With NoSQL
Injection, instead of injecting STRINGS as parameters, attackers use SUB-OBJECTs as parameters to inject database queries.

The SQL statement that we used above to query the user login details will be written like this in MongoDB:
db.users.find({username: username, password: password});
As mentioned before, attackers can use subobjects as parameters to inject to NoSQL database queries, for example:
db.users.find({
username: “peter”,
password: { $gt: “” }
})
In the above query, the $gt operators stands for “greater than”. The password is not validated to ensure that it is string. Therefore, when the JSON document is
deserialized, that eld may contain anything but string that can be used to manipulate the structure of the query. You can get that what the query does is
comparing the password of “peter” with an empty string, so this condition is always true.
In MongoDB, there’re many similar operators, like $gt that attackers can take advantage of, such as: $gte (greater than or equal to), $lt (less than), $lte (less
than or equal to), $ne (not equal to), $nin (matches none of the values speci ed in an array), etc.
NOSQL INJECTION IN METEOR APPLICATION
Here comes the Meteor part. Typically the default data layer of Meteor applications in MongoDB, which puts Meteor apps in the risk of being exploited using the
NoSQL Injection technique. Let’s get into one demo application for testing NoSQL Injection: meteor-shop. you can clone the app from
https://github.com/sonlexqt/meteor-shop (https://github.com/sonlexqt/meteor-shop). This web application is written in Meteor. Please follow the instruction in
README.md le for how to setup and run the app in your local machine.

In the scope of Meteor, attackers usually take advantage of publication functions and methods. For example, you can see that in the publication.js le we have
this publication function:
// Get the products, filtered by their vendor
Meteor.publish("products-by-vendor", function(slug){
return Products.find({"vendor.slug" : slug})
});

We (as developer) are expecting the slug information to be a string, but haven’t check for that condition. So whatever input can be injected into this function,
which makes it vulnerable to NoSQL Injection. For example. an attackers can do this (in browser console) to get all the documents in the Products collections:
Meteor.subscribe(“products-by-vendor”, { $ne: null })
Products.find().fetch() // Now all products in the database are shown !
You can take a look at the server/publication.js le and meetup.js le. Those les contain some examples to help you play around with NoSQL in the demo app.
SOLUTION TO THE PROBLEM
Through those example above, hopefully you can see the potential of NoSQL Injection being a threat to apps using NoSQL databases. So how do we prevent
this problem?
Fortunately, it’s pretty easy in the scope of Meteor to prevent the app from being attacked by NoSQL Injection. In general, there’s only one thing to keep in mind:
Never completely trust user inputs. We must always get them validated before passing them as parameters to publication functions and methods. Meteor has
a handy package which do the exact same thing called check (https://atmospherejs.com/meteor/check). This package will allow us developers to check if the
input parameter match the de ned type. So, one can’t inject a JavaScript object as parameter to a function which requires a string, for example.
The check package is quite useful but what if your project has so many publication functions/methods that you don’t know if their parameters have been
checked or not? Then here comes audit-argument-check (https://atmospherejs.com/meteor/audit-argument-checks) and check-checker
(https://github.com/East5th/check-checker), those package will throw warnings if there’re methods that haven’t been checked by the check package.
Wrapping Up!
Walking through this blog, we’ve discovered more about NoSQL Injection:
How it works and some examples
How to prevent it in general and in the scope of Meteor
So, did you nd some great information of your own in this blog? What am I missing? Let me know in the comments and I’ll add it in!
If you enjoyed this post, I’d be very grateful if you’d help it spread by emailing it to a friend, or sharing it on Twitter or Facebook. Thank you!

No sql injection in meteor.js application

More Related Content

What's hot (20)

Viewers also liked (14)

Similar to No sql injection in meteor.js application (20)

More from Designveloper (20)

Recently uploaded (20)

No sql injection in meteor.js application