Black Box Meteor - Package Scanning

Written by Pete Corey on Apr 24, 2015.

An interesting side effect of Meteor’s packing system is that all packages used in a project are visible to the client. Open up a browser and take a look at the global Package object:


For a simple project, you may see results like this:

["underscore", "meteor", "json", "base64", "ejson", "logging", "reload", "tracker", "random", "retry", "check", "id-map", "ordered-dict", "geojson-utils", "minimongo", "ddp", "insecure", "mongo", "autoupdate", "meteor-platform", "autopublish", "webapp", "deps", "reactive-dict", "session", "livedata", "jquery", "htmljs", "observe-sequence", "reactive-var", "blaze", "ui", "templating", "spacebars", "launch-screen"]

So what are the consequences of this? Immediately, we see that this application is using autopublish and insecure. A malicious user could quickly couple a search for autopublish or insecure with a search for any globally defined Collections:

Object.keys(window).filter(function(key) {
    return window[key] instanceof Meteor.Collection;

Or just directly look through the Mongo collections published to the client:


In a fraction of a second, a malicious user can see if your application is overpublishing, or vulnerable to arbitrary Mongo modifications through the autopublish and insecure packages.

But what about other packages? What if a malicious user is aware of a vulnerability in an existing Meteor package. Using the Package object on the client, that user can quickly check to see if an application is making use of that package, and is therefore vulnerable.

One sidenote is that the Package object does not include the version of the package being used. If a malicious users knows that a vulnerability exists in some version of a package but not in other versions, they would not immediately know if your application were vulnerable to their exploit.

So what can you do to protect your application? First, in nearly all cases your production application should not being using autopublish or insecure. Remove those packages. After that, always be sure to keep your packages updated to ensure that you’re not shipping code that may contain known flaws or vulnerabilities.

Discover Meteor - Mentoring Session

Written by Pete Corey on Apr 20, 2015.

Last week I stumbled upon Sacha Greif’s Crater post about becoming a Discover Meteor tutor. I decided that this would be a great opportunity to flex my teaching muscles and help others learn about Meteor!

I’ve scheduled a Hangout at 9:00 AM, Pacific Time, this Wednesday morning (4/22). We’ll be going over the Templates chapter of Discover Meteor (Chapter 3). We’ll spend the first 40 minutes going through the chapter, followed by a 20 minute block set aside for questions and answers. If you’re interested, check out the CodeBuddies event and sign up. See you then!

Black Box Meteor - Method Auditing

Written by Pete Corey on Apr 15, 2015.

When using Meteor methods, a surprising amount of information can be passed down to the client. Let’s considering the following method definitions:

    sharedMethod: function() {
        console.log('This is a shared method.');
        if (Meteor.isServer) {
            console.log('This is behind a server guard.');

if (Meteor.isServer) {
        serverMethod: function() {
            console.log('This is a server method.');
        hiddenMethod: function() {
            console.log('This is a hidden method.');

With these methods set up, open your browser’s console and take a look at the method handlers exposed to the client:


Along with a few others, you’ll see the handler for sharedMethod. You won’t see serverMethod or hiddenMethod because both of these methods were defined entirely behind a server guard.

Take a look at the source of sharedMethod:


You’ll notice that you can see all of the method’s contents, including any permission checks and validation that may or may not be taking place. You can see the call to serverMethod! It’s important to realize that unless you’re being careful, even server guarded blocks will be passed down to the client within client visible method handlers.

All methods can be called from the client, even methods that the client should have no knowledge of:‘sharedMethod’, ...);‘serverMethod’, ...);‘hiddenMethod’, ...);

It’s not enough to try to hide your methods on your server. Always be sure to do proper validation, sanitation and authentication before taking any action in a method.

I highly recommend taking a look at Sacha Greif’s three part latency compensation series (An Introduction to Latency Compensation, Advanced Latency Compensation, and Two-Tiered Methods) over at Discover Meteor to better understand how to use and protect your Meteor methods.