I would like to hear from someone at MDG what’s MDG’s position on Sikka. Is it absolutely necessary to have the package if you don’t anyone to bring down your site willy nilly. Or is it more like you’re fine without it but if you do X, Y, or Z then you do need it.
If it’s an absolute requirement to have then why not bake it into core?
I ask because we’re going to start a project in the next few months here at my company. In the current state of affairs there’s no way I’ll be able to recommend using Meteor knowing that I’ll have to end the presentation with “There’s one caveat though, Meteor has a hole which allows anyone to bring down your app at any time. But don’t worry there’s a package called meteorhacks:sikka which patches it.”
As well respected as Arunoda is in the Meteor community, I know the reaction I’m going to get from the suits.
The suits are going to be ROTFL saying “Let me get this straight… you want us to bet an app that’s going to cost hundreds of thousands of dollars, just to get it out the door, on this framework which is so insecure that for the app to stay up it needs a hack from who knows who in who knows where? Good one.”
The platform shouldn’t be evaluated in isolation. The strength of Meteor is in the community as much as it is in the core platform. Sikka isn’t a “patch” to an issue with Meteor, its new functionality that restricts a specific set of use cases.
Some of us may not want that, but most of us will.
This is no different from anything else. You wouldn’t use Meteor without including IronRouter, so why even bother mentioning that its third party?
Actually, you can do without iron router. And there’s a difference between a package that is nice to have and a package so critical that without it anyone can bring your site down.
I would like MDG to chime in on this because maybe the issue is blown way out of proportion. Maybe it’s not the case that you either use this or anyone can take down your site with a simple loop.
Your company also can’t use Windows PCs, because they can get viruses, and you’d need some hack from some guy named “Kaspersky” or something to get rid of them.
It’s probably best Arunoda and his team are independent of MDG. It’s also clear they are the unrivaled top talents in Meteor. I don’t care what he or his company is called or where they are located or whether they are an official part of MDG or not. Your executives may have those xenophobic biases still, but the current way software is built is using open source meritocracies rather than rigid top-down fiefdoms. And so if “a hack from who knows who in who knows where” is what the platform relies on to remain functioning that is normal today. Whether another company is able to put a veneer over that or not is illusory, and the Internet tends to dispel these illusions anyway.
Security is an imperfect science. Exploits and remedies appear from any source at any time and must be constantly kept up with. It’s too big and dynamic a field to be perfectly organized especially with an emerging technology. We all just learn to keep our eyes open and help each other out so the bad guys don’t prevent other progress. Because everything is open source many eyes can be looking at the solution. Naturally the exploit code needs to be kept scarce until the defenses have been established.
What I would tell the “suits” is that Meteor is blessed with a genius programmer & team who is solving the problems of the platform and distributing those solutions either free as open source or for a minimal fee. Whether that programmer works for “an established firm” or not doesn’t matter in the open source era. There is a cost to being on the cutting edge of technology but there are enough benefits balancing that. I also believe if Meteor was under specific attack MDG would be an effective resource in addressing it as well. Any other system you look at it detail will have its own specific attack vectors and its own Arunoda’s (perhaps not as good) addressing them within their communities.
No one ever got fired for buying IBM. If your executives are afraid of being fired for not buying IBM, go ahead and have them buy IBM instead. (And don’t let them dig too deeply into how IBM actually builds things today.)
This reminds me of meteor for Windows. So many people where against MDG putting resources into making it happen. “They can just use a VM and code in Linux, what’s the problem? If they can’t be bothered to do that then who cares, let those idiots miss out.”
And now "MDG shouldn’t use resources to fix this vulnerability. If executives at big companies see this as a problem then who cares, let those idiots miss out. "
And that’s if there really is a serious problem. Again, it could be that the issue is blown away out of proportion.
Actually, you can do without iron router. And there’s a difference between a package that is nice to have and a package so critical that without it anyone can bring your site down.
Sure, and you can do without Sikka also by writing your own version.
Lots of things can and will bring your site down. Sikka is one of a million little solutions to an infinite number of problems. Be glad that someone addressed this particular one, rather than ignoring it like most platforms do.
Sure, you can also roll out your own version of Meteor…
Look, I don’t have a problem with me using sikka (depending on MDG’s position I probably will), but people without fanboy hats will see it differently. And just like with Windows, I don’t think the position should be “if Meteor having a well known whole that can be patched with a third party tool is a problem for executives then let those idiots miss out”.
I feel there is a bit too many “emotional” replies here. I get it, but it might not be fair. For my part, it is a normal and legit question by manuel. The reply’s I’m seeing so far are a little bit like it’s wrong to ask questions like this. It isn’t . Better one question too many, than one too few.
I’m not in a “suits” environment anymore, but how manuel describes it, is exactly how those environments will react. Lets’ not judge, but give some proper advice on how to deal with the situation if we can. He isn’t the one who created the environment He has to work with it.
And as he said, it is indeed totally different than anything related to Iron Router And for the record, not every app uses IR or routers in general. Don’t assume because you do everybody else does
I think it is a valid point since just today a dev that I know was concerned about this, and thinking about changing Meteor to MEAN. That being said, my opinion is that it was a little obvious that Meteor would have this type of problem since we’ve being using this all the time.
The fact that most people don’t stop to think that if you can test you methods from chrome console you can also bring a site down with multiple requests, for example. Looking from the bright side is always better, and then @arunoda ‘chocked’ us with that video. Well, he is correct, we obviously need to care abouts this.
I can create a dos attack in other language and bring websites down if they are not prepared, as some hackers already did with sites that I’ve worked on. It would be great to have a package like Sikka in core, even because they know better how to deal with things internally. But again, this flaw was already a clear thing to me and my team.
Good one, makes total sense to me. So maybe the question is more if there is anything special about a Meteor stack (e.g., something that other stacks have figured out in a different way), or is it just that this is inherent to internet apps in general and is normally “handled” outside of the app-context? if so, than it seems Sikka just is handy, to provide such tooling inside the app, not so much a solution for something that is lacking in Meteor?
I’ve used to work at Videolog, and we had about 14 mi users a month. When we migrated from v2 to v3, (PHP to PHP), we forgot to control video counts limit, an ajax post that we had to other server. The end was obvious, we had shit videos with millions of views, because someone used that to gain more views. The first solution was a simple one, verify the cookie. And then we’ve done some things like blacklists.
So I agree with you that have a package like Sikka is handy, because it’s taking a responsibility that anyone should have when building a production app. We are just not realizing that Meteor works different. The standards methods that we use to protect against ddos, like cloud flare, are mostly ready to deal with http requests. But when you are able to build a site with DDP and client/server connection, you must set the security here too.
I think that we should be concerned if somehow (please someone try this, rs) we could change Allow/Deny, overwrite methods, disable/enable packages and that stuff. This would be a Meteor security problem, no doubts.
These kind of threats are pretty common to all other frameworks as well. So, if you switch to some other framework. You also got this problem. I don’t think, most frameworks has official support for these kind of issues.
So, this is not only for Meteor.
So, you got one point to talk to your boss.
Then, our projects are not typical open source Meteor projects. MeteorHacks is not a consulting firm. We 100% works on projects like this and improve Meteor experience. So, you can expect good support from us. May be our projects are good as core projects. We do fixes for crucial issues under few hours after it has been reported.
So, you may got another point to talk to your boss.
I don’t want to speak for MDG, but it’s probably a bit early for them to have a real position on this. They’ll probably want the package to be used by the community for a couple months at least to see what the consensus is.
I think @manuel’s initial question is more about Meteor’s susceptibility to dos-like attacks more than it was about Sikka itself. The question sounds more like to me as:
Are all meteor apps powerless against dos-like attacks and browser-console loops against the server, or should we be concerned on a per-package / per-feature basis.
And yes, I think a tech-stack’s ability to withstand/subvert certain attacks is a valid concern. Meteor is not our typical request/response framework and a lot of what’s going on is abstracted behind the meteor magic. So our typical tools of the trade become useless. One may need to know what tools are available, and if no such tool is offered in core, what we should look out for when selecting a tool from a third party contributor.
And that’s the fact. None of us know how to shop for a meteor dos-firewall, rate limiter, throttler etc.
There are a couple of alternatives on atmosphere now (including Sikka) and I sincerely don’t know how to assess their strengths/weaknesses since I don’t have any baseline to compare against.
Also, I should mention that this is a more serious subject than it may sound to many.
Two years ago, we needed to shut down a 2-year-old startup, an online marketing research business, due to long-standing and heavily destructive, although hardly noticeable, trolling/gaming activity that lasted for months that we just could not keep up the fight against any more. That cost a lot of money not to mention the jobs and hopes lost to so many innocent partners and employees.
Pretty much every webserver relies on 3rd party software to increase security, from firewalls to antivirus software. Without them the server would be vulnerable. So you could make the same point with operating systems.
The problem with the enterprise environment is trust in change and innovation. It’s the same reason why many of those environments are afraid of software updates and are still on IE8.
If you can’t convince your executives of the benefits, the issue won’t be that meteor isn’t secure, it’ll be skepticism in the maturity of the framework (which they’ll have for every ‘new’ framework/stack). They need to see that company x or y have used it successfully first.
I think what ticks people of about the OP’s message is that you see this as a ‘hole’ in meteor that needs to be patched. It needs work to make an app secure, this is true for every framework/stack. Without specific work from the programmers or 3rd party ‘plugins’, every system is insecure.
Anyway, I’m glad we’ve got Sikka so we don’t have to do the work ourselves. Thanks Arunoda
I agree with @serkandurusoy - this isn’t really about Sikka, although it is a welcome solution.
I’m more worried that many in-production Meteor apps right now can be easily DOSed using @arunoda’s method, which seems to be trivial and I hope is disclosed responsibly eventually. It’s only a matter of time before people start ‘testing it out’ on real apps, which would be really bad for Meteor’s reputation.
If this is the case, I feel that a way of preventing this should be in core, or be maintained in an official package, and we definitely shouldn’t be waiting a couple of months as @sacha suggests. Maybe more like a couple of days if this is a serious vulnerability.
Or am I missing something - is this less serious than it sounds?
I think, we need to think this in a different way.
We should not ask or expect every possible feature thing to be in the meteor core.
It’s really impossible to do that and I think Meteor already has a lot in the core.
What we need some very mature set of packages in the community where we can trust.
Here’s why I say this:
MDG has limited resources.
Bring a package into core means, in order to update it they need to do a release. I don’t think that’s smart and prevent quick release cycles (specially when the package is being developed).
We need to prove we’ve a strong community.
We need to have options - like, Iron Router, Route Core, Flow Router, etc
When we are doing this, we need to face two problems mainly. I don’t have direct answers for them.
A) Quality of the project
How do we check the quality of the project? May be we can form some advisory panel who checks the quality of packages and give some rating based on some guidelines. And get the public opinion as well.
I heard atmosphere will get something like this and they’ll build some scoring system and so on. Actually, we don’t need such at the beginning. Let’s start something, then we can see what we need.
B) Maintainability of the project
Some people do these projects in their spare time. Do they have enough time to maintain this project? How do we make them motivated to maintain the project? This is a big issue to solve. (I don’t think it’s easy)
I heard Sam from Velocity say, they have some limited time to work on the project. That’s true. They got to do their jobs and find a living. I hope this is true with most of the projects.
For this specific problem, we can do some fixes in core.(That means, Sikka as a PR) But, I personally don’t like to send PRs. I think that’s a waste of time for projects like this. Since, we never know what’s gonna work and what we need to do.
By maintaining it as a separate project, we all can try out and find the best ways to deal with this. We can do quick iterations.
After sometime later, once the project get matured we can decide to add it to the core. Even when I prefer it will be something like mdg:sikka not something comes directly with the release. Then, we can add features without doing a new Meteor release. We don’t even need to add this to core, if we’ve a solution to problem “A”.
Corporate acceptance aside, it’s only a matter of time before script kiddies start messing with Meteor sites. It baffles me how so many people here don’t see it as a problem.
Actually the exact topic had been brought up many times at the old meteor-talk google group and there was not much interest except for one specific ddos prevention related thread where the official response was around the premise of “use this.connection to get the IP and rate limit your methods around that”.
Other than that and a few other threads, the topic used to get dismissed rather quickly, and by everyone!
So I’m glad now we’ve got to terms with it and seeking solutions, thanks to @arunoda’s incredible talent and contribution and I really like to reiterate that what we should be discussing here is not who’s responsible for doing what. Rather than that, we should be discussing the best practices, problems, possible solutions, and what should be done when anyone comes around to do that, either in core or as a package.
. Better one question too many, than one too few.
