Why You Should Always Check Your Arguments

Written by Pete Corey on Feb 29, 2016.

Last October, I was lucky enough to attend the first ever Meteor Space Camp! True to its “unconference” roots, the weekend was punctuated by fantastic talks on a variety of Meteor topics, by a collection of amazing Meteor developers.

I decided to give a talk on Meteor security with a heavy focus on the importance of making assertions about user-provided data. The talk was called, “Why You Should Always Check Your Arguments”, and it’s available on Youtube!

Take a look, and be sure to always check your arguments!

Method Auditing Revisited

Written by Pete Corey on Feb 15, 2016.

In the past I’ve written about how a potentially malicious user can view all of the isometrically defined methods in your Meteor application. By inspecting the Meteor.connection._methodHandlers object on the client, they can see all client-side executable instances of your methods, which in most cases are identical to your server-side executable methods. This lets an attacker identify weaknesses in your application security that may lead to an attack.

Meteor.connection._methodHandlers only poses a potential problem for methods defined in a shared location. Methods defined in a server.js file, or within a server/ folder will never be shipped to the client, and won’t appear in the _methodHandlers object.

However, defining methods in server-only locations doesn’t mean your methods are free from prying eyes! Depending on how your application is structured, it may still be possible for an attacker to find and exploit these methods.

Source Snooping

Even if a method is defined in a server-only location, it’s still accessible from the client. For example, if you have a method defined in a server.js file:

  hiddenMethod: function(argument) {
    // Do secret things...

That method can still be called from the client:

Meteor.call("hiddenMethod", argument);

This means that one way of discovering hidden methods within a Meteor application is to simple search the bundled application source for Meteor method calls.

When the Meteor application is minified, the Meteor object is often transformed into some other variable name, so rather than searching for /Meteor\.call("/, it’s better to search for /\.call("/:

For example, in the above screenshot we can see a call to a Meteor method called "increasePostViews". This method is taking two arguments. I wonder if both of those arguments are being checked?

Watching the Wire

An alternative to searching through the source for method calls is to simple watch all of the DDP requests that are sent over the websocket connection. Any calls to Meteor methods will be clearly marked, along with a list of arguments being sent to this method.

As you go about using the application, you can build up a list of Meteor methods, some of which may not have a corresponding handler in the Meteor.connection._methodHandlers object.

In the above screenshot, we can see a call being made to the "upvotePost" method with a single arguments.

Well Kept Secrets

These techniques will only reveal hidden methods that are being called by client-side or shared code. It’s still possible that the Meteor application may have other, completely hidden methods. These methods may be defined on the server, and only called by other server-only code.

In that case, the only way for a curious client to discover those truly hidden methods is make a call to every possible Meteor method to determine if it exists on the server. Thankfully, this kind of brute forcing is totally unfeasible, and would most likely never be worth an attacker’s time.

At the end of the day, it shouldn’t matter whether attackers know methods exist. Even your most secret of methods should be made secure. Always assume that all of your methods will be called by all users, because they can be!

Preparing for the Crater Conference

Written by Pete Corey on Feb 8, 2016.

Are you as pumped about the Crater Remote Conference as I am? There’s an amazing lineup of speakers scheduled, and I can’t wait to hear from each of them.

I’m currently in the process of putting the finishing touches on my talk. I’m planning on speaking about NoSQL Injection in modern web applications, with a heavy focus on MongoDB. I’m planning on doing most of the talk as a hands-on demonstration where we’ll attack a Meteor eCommerce application.

If you don’t have tickets yet, go buy them now!

The threat of SQL injection in modern web applications has been left by the wayside with the rise of NoSQL databases. Unfortunately, a new, but fundamentally similar threat has taken its place: NoSQL injection. Let’s take an in-depth look at this type of attack and the steps we can take to protect ourselves from it. The king is dead, long live the king!