@sashko It would be really interesting to get feedback on this. Our app is relaunching with a lot more traction (and revenue) expected this week. I wouldn’t want a huge security risk lurking in our system, what are your measures against this and should we follow SkinnyGeek’s recommendations for now?
1 Like
I think it’s correct that, technically, this kind of protection is usually not the job of the hosting platform or the web framework. And Galaxy supports configuring any CDN you like to handle this stuff. Personally I think calling it a security vulnerability is a bit unfair given that, as far as I know, no other framework or hosting platform solves these types of issues automatically.
But, given that Galaxy already does lots of nice things that many hosting platforms don’t do for you, it’s a feature that could exist.
Let’s wait until Monday when everyone comes back to work, and then maybe someone who works on Galaxy can give their input on this - honestly I’m not qualified to talk about the intricacies of production hosting as they are.
2 Likes
This isn’t new. I find it troubling that MDG could provide some basic level of protection against this out of the box, but chooses not to.
Tell me more that you mean by this? What is the basic level of protection that could be provided out of the box? Could it be accepted in the form of a PR on meteor/meteor? (To be clear there isn’t some secret plan to make Meteor apps more vulnerable than they need to be)
Either something like Sikka provides some level of protection or it doesn’t. If it does, then something like that should come out of the box (you may still be attacked in all sorts of ways, but that won’t be one of them) . If it doesn’t, then MDG should say why it’s not worthwhile adding it to your projects.
I think the vulnerability in question is with meteor.loginServiceConfiguration and the fact that it can be spammed easily to overwhelm the server. From what I understand, this isn’t rate limited by default with the tools provided in 1.2 (using Accounts.removeDefaultRateLimit() from what I remember).
I also agree that a general rate limiting service is out of scope for Galaxy.
Tell me more that you mean by this? What is the basic level of protection that could be provided out of the box? Could it be accepted in the form of a PR on meteor/meteor? (To be clear there isn’t some secret plan to make Meteor apps more vulnerable than they need to be)
I don’t have a PR but it’s possible to rate limit meteor.loginServiceConfiguration by default. Also more than happy to re-send the gist to reproduce it.
What specifically does one have to do on CloudFlare to safeguard against this? Simply make sure CloudFlare’s DNS is used? (is the free tier sufficient?)
Is this a concern in Meteor 1.3?
It does come out of the box: http://docs.meteor.com/#/full/ddpratelimiter
It automatically rate-limits logins, and is easy to configure for other methods and subscriptions.
But I don’t think this or sikka rate limits connections, which is the thing in question in this thread.
Note that the Meteor Guide prominently recommends this: http://guide.meteor.com/security.html#rate-limiting
And the Todos example app for the guide has it everywhere: https://github.com/meteor/todos/blob/90d16c8f50fa7aee0dd1f15e1564b40ba4ca750f/imports/api/todos/methods.js#L109
I don’t think Meteor can even theoretically protect against every type of vulnerability by default - there are so many ways to bring down a Node.js server. But I’d gladly accept a PR to limit this particular subscription by default, which is absolutely possible in Meteor 1.2 with DDPRateLimiter.
What else does Sikka do? I’d be happy to integrate it into Meteor core.
1 Like
Yep, I totally agree. In my opinion the method that was exploited is not one you think of (unlike user created methods), and affects every Meteor app (from what I understand). From what I remember calling Accounts.removeDefaultRateLimit() didn’t fix it (though it’s been quite a while since then so i’m not positive).
But I’d gladly accept a PR to limit this particular subscription by default, which is absolutely possible in Meteor 1.2 with DDPRateLimiter.
I wish I had more time but am moving at the moment so i’m pretty swamped.
What else does Sikka do? I’d be happy to integrate it into Meteor core.
It also does rate limiting as well but throws a captcha modal/page if the rate is exceeded. I think one of the largest features is that you can just install it and everything works as opposed to setting up rules for every new method. At the time I had to get it working in minutes as my site was being taking down constantly so it was a quick fix.
Ok maybe the answer is to add a default rate limit on meteor create that can be removed by the developer if they don’t want it.
4 Likes
Exactly.
(need more chars)
Couldn’t agree more. Let’s push this into 1.3!
Anyone got a PR? BTW, this is easily addressed in one’s own app by using DDPRateLimiter.
1 Like
Yep, also listed in the Meteor docs and the guide.
1 Like
Relating to security vulnerabilities, I was about to post a reminder that Meteor is registered with HackerOne, but I guess not anymore?
It turned out that we got almost exactly zero useful reports from HackerOne, and paid them some money for it. security@meteor.com has been much more useful!
3 Likes
I have submitted what I thought to be security vulnerabilities to MDG in the past (like 2 times) via security@meteor.com and both times they got back to me in less than 2 hours. I’ve only had positive experiences with the current system.
4 Likes