Firebase security rule to prevent customers from circumventing usage tracking

Question

We are offering a service that people will embed on their web site and we are hoping to use Firebase as our backend. We would like to base our subscription rates on page views or something similar. Right now we are stumped trying to figure out how to prevent customers from caching our client js code and omitting any portions that attempt to increment a page views counter.

What we need to do somehow is create a security rule that atomically prevents someone from reading from one location unless they have incremented the counter at another location. Any ideas on how to do this?

For example, assuming the following schema:

{
  "comments" : {
    "-JYlV8KQGkUk18-nnyHk" : {
      "content" : "This is the first comment."
    },
    "-JYlV8KWNlFZHLbOphFO" : {
      "content" : "This is a reply to the first.",
      "replyToCommentId" : "-JYlV8KQGkUk18-nnyHk"
    },
    "-JYlV8KbT63wL9Sb0QvT" : {
      "content" : "This is a reply to the second.",
      "replyToCommentId" : "-JYlV8KWNlFZHLbOphFO"
    },
    "-JYlV8KelTmBr7uRK08y" : {
      "content" : "This is another reply to the first.",
      "replyToCommentId" : "-JYlV8KQGkUk18-nnyHk"
    }
  },
  oldPageViews: 32498,
  pageViews: 32498
}

What would be a way of only allowing read access to the comments if the client first incremented the pageViews field? At first I was thinking about having two fields (something like pageViews and oldPageViews) and starting out by incrementing pageViews, reading the comments, then incrementing oldPageViews to match, and only allowing read on comments if pageViews === oldPageViews + 1. However, unless this could be done atomically, the data could get into a corrupt state if the client started the process but didn't finish it.

Here is a codepen trying to test this idea out.

Answer 1

I would suggest a variation of Kato's rate limiting answer : https://stackoverflow.com/a/24841859/75644

Data:

{
  "comments": {
    "-JYlV8KQGkUk18-nnyHk": {
      "content": "This is the first comment."
    },
    "-JYlV8KWNlFZHLbOphFO": {
      "content": "This is a reply to the first.",
      "replyToCommentId": "-JYlV8KQGkUk18-nnyHk"
    },
    "-JYlV8KbT63wL9Sb0QvT": {
      "content": "This is a reply to the second.",
      "replyToCommentId": "-JYlV8KWNlFZHLbOphFO"
    },
    "-JYlV8KelTmBr7uRK08y": {
      "content": "This is another reply to the first.",
      "replyToCommentId": "-JYlV8KQGkUk18-nnyHk"
    },
    "timestamp" : 1413555509137
  },
  "pageViews" : {
    "count" : 345030,
    "lastTs" : 1413555509137
  }
}

Security Rules:

{
  "rules": {
    "pageViews": {
      ".validate": "newData.hasChildren(['count','lastTs'])",
      "count": {
        ".validate": "newData.exists() && newData.isNumber() && newData.val() > data.val()"
      },
      "lastTs": {
        // timestamp can't be deleted or I could just recreate it to bypass our throttle
        ".write": "newData.exists()",
          // the new value must be at least 500 milliseconds after the last (no more than one message every five seconds)
          // the new value must be before now (it will be since `now` is when it reaches the server unless I try to cheat)
        ".validate": "newData.isNumber() && newData.val() === now && (!data.exists() || newData.val() > data.val()+500)"
      }
    },
    "comments": {
      // The comments can't be read unless the pageViews lastTs value is within 500 milliseconds of now
      ".read": "root.child('pageViews').child('lastTs').val() > now - 501",
      ".write": true
    }
  }
}

NOTE : I haven't tested this so you need to play around with it a bit to see if it works.

Also, based on your sample data, I didn't deal with uid's. You need to make sure you're managing who can read/write here.

Answer 2

Justin's adaptation to the throttling code seems like a great starting point. There are a few annoying loopholes left, like forcing the counter to be updated, getting quantifiable metrics/analytics out of your counter (which requires hooking into a stats tool by some means and will be necessary for accurate billing reports and customer inquiries), and also being able to accurately determine when a visit "ends."

Building from Justin's initial ideas, I think a lot of this overhead can be omitted by simplifying the amount the client is responsible for. Maybe something like:

1. Only force the user to update a timestamp counter
2. Employ a node.js script to watch for updates to the counter
3. Let the node.js script "store" the audit data, preferably by sending it to analytics tools like keen.io, intercom.io, etc.

Starting from this base, I'd adapt the security rules and structure as follows:

{
  "rules": {
    "count": {
      // updated only from node.js script
      // assumes our node worker authenticates with a special uid we created 
      // http://jsfiddle.net/firebase/XDXu5/embedded/result/
      ".write": "auth.uid === 'ADMIN_WORKER'", 
      ".validate": "newData.exists() && newData.isNumber() && newData.val() > data.val()"
    },
    "lastTs": {
      // timestamp can't be deleted or I could just recreate it to bypass our throttle
      ".write": "newData.exists()",
        // the new value must be equal to now (i.e. Firebase.ServerValue.TIMESTAMP)
      ".validate": "newData.isNumber() && newData.val() === now"
    },
    "comments": {
      // The comments can't be read unless the pageViews lastTs value is within 30 seconds
      ".read": "root.child('pageViews').child('lastTs').val() > now - 30000",
      "$comment": {
        ".write": "???"     
      }
    }
  }
}

Now I would write a simple node script to perform the count and administrative tasks:

var Firebase = require('firebase');
var ref = new Firebase(URL);
ref.child('lastTs').on('value', heartbeatReceived);
var lastCheck = null;

function heartbeatReceived(snap) {
  if( isNewSession(snap.val()) ) {
    incrementCounter();
  }
  updateStatsEngine(snap);
}

function incrementCounter() {
  ref.child('count').transaction(function(currVal) {
    return (currVal||0) + 1;
  });
}

function isNewSession(timestamp) {
  // the criteria here is pretty arbitrary and up to you, maybe
  // something like < 30 minutes since last update or the same day?
  var res = lastCheck === null || timestamp - lastCheck > 30 * 60 * 1000;
  lastCheck = timestamp;
  return res;
}

function updateStatsEngine(snap) {
  // contact keen.io via their REST API
  // tell intercom.io that we have an event
  // do whatever is desired to store quantifiable stats
  // and track billing info
  //
  //var client = require('keen.io').configure({
  //    projectId: "<project_id>",
  //    writeKey: "<write_key>",
  //    readKey: "<read_key>",
  //    masterKey: "<master_key>"
  //});
  //
  //client.addEvent("collection", {/* data */});
}

The downside of this approach is that if my admin script goes down, any events during that time are not logged. However, the wonderful thing about this script is its simplicity.

It's not going to have many bugs. Add monit, upstart, or another tool to make sure it stays up and does not crash. Job done.

It's also highly versatile. I can run it on my laptop or even my Android phone (as an HTML page) in a pinch.