Hey all! Excited to deliver a new Meteor Case Study: Learn how our friends at Any Run built the world’s most popular malware sandbox tool using Meteor.js.
And they’re just getting started. Find it on the blog.
Hey all! Excited to deliver a new Meteor Case Study: Learn how our friends at Any Run built the world’s most popular malware sandbox tool using Meteor.js.
And they’re just getting started. Find it on the blog.
Great case study, thanks!
Can someone elaborate on this bit:
The lack of websocket protection and connection between the front-end and a back-end that allows crawlers to automatically download all the data directly from the websocket without visiting the front-end part.*
Is this some security vulnerability I wasn’t are of, or just a window for DDOS?
I think they are right. This is not a security vulnerability per se; unfortunately, this is a possible exploitation of Meteor applications based on how Meteor works.
What they mean to say is that you can build a system that so to say emulates a browser so as to connect to a Meteor server directly via DDP. This application then can invoke methods and run subscriptions at will. These invocations and subscriptions will yield data, i.e. data can be leeched in an automated way, and there is not much we could do about it.
Even if data is only accessible to registered users, an attacker can, under circumstances, sign up, and implement a log-in in their client emulator.
DDP rate limiter may stand in the way, but with a trial and error / simple binary search the exact pace of limiting can be detected from the outside, and the data leecher can take that pace/rate into account.
I realized this a couple of months ago already. Truth be told, the same is true for probably nearly all web-based systems, i.e. data can be extracted the same way via REST calls.
Very good points; for a while we’ve been running automated testing and load profiling for our methods and publications using just the CLI. One really doesn’t need a browser for this.
But yeah, it should not come as a surprise to anyone. It hardly deserves a mention. Any web service is exploitable in the same way. The protocol matters less.
What does work is rate limiting the login attempts to prevent outsiders from breaking in and reading your data at will. It’s just that you can’t prevent your own users from doing that, with the data they have access to.
PS. I knew Any Run but had no idea it was built with Meteor. It’s quite a sophisticated service. Well done them, well done Meteor!