This doesn't surprise me, and I'm not even an experienced Rails developer.
I think a big part of the problem is that there are a ton of gems that are simply hobby projects that gained traction and became popular. They were originally architected by enthusiasts, rather than experts. Some of these projects may also have been abandoned by their authors, but still in use because they may be the only way to accomplish a complex task or integration. You can't expect stuff like that to be very secure. You just have to think carefully about whether the risks of using them are worth the gains made from not having to implement the functionality yourself.
The problem isn't that rails is insecure (it is, but that isn't the point.) The problem is that rails by definition attracts developers who don't really like developing.
If the entire USP of your platform is that it cuts corners you'll see it put to use by people who either don't care or don't know any better.
I'm not saying there aren't good rails developers, but in my experience they are a minority.
Yeah, I don't really understand about this, especially the security aspect of Gems.
Every piece of externally-maintained code is a security risk, surely? You are implicitly trusting the maintainer of that Gem to not hide bad things in their code. And every Gem that they depend on. If the Gems are old and the maintainer is unpaid and doing other stuff, how sure can you be that they're still vetting all contributions for security? Or that they haven't handed over the maintenance to someone you no longer trust? Or that the maintainer hasn't succumbed to economic pressure and included some malicious code in their Gem?
Or do you have to manually review every single line of code in every dependency yourself? That seems like a lot of work... I would definitely prefer to write my own code for a feature than review 1000's of sloc of someone else's code to spot any problems.
I get that the core Rails codebase gets security-reviewed regularly, but does that happen for Gems? And is it methodical and thorough, or is it just "lots of eyeballs"? And if so, is there a threshold of Gem popularity below which there aren't enough eyeballs to spot problems and the Gem should be considered insecure?
And if you do spot a problem, do you report it and hope the maintainer has time to do something about it? Or do you write a PR and submit it, hoping they accept it? Doesn't that then mean you're maintaining someone else's code base? Again, I would massively prefer to write and maintain my own code than maintain someone's else code (or wait for them to fix a problem that they may no longer care about).
How do you build a secure application for something as trusted as Github while gleefully incorporating all this third-party code?
> but the best-known Rails sample code is all vulnerable.
Rails is moving so fast now that most sample code is very outdated. Take authentication for example, there's at least 5 different plugins, all favoured as the best way to authenticate in rails at one time or another. Totally hopeless for a newbie to dig out which is the solution to go with, or at least it's a few days trial and error, trying out tutorials here and there. I've done a few rails projects on and off and each time I come back there's tons of new stuff, which is really great, but I would personally like to have more batteries included or "blessed" official plugins because I don't spend all my time in rails land, and it's hard to keep track of all the new goodies.
Anything you implement to replace the functionality missed by not using Rails will be, statistically, just as insecure. Arguably, even more-so because you will no doubt lack the peer review a large project like Rails benefits from.
so maybe some novice developers write an app using the generators and scaffolding baked into Rails, and as a result they get a security vulnerability that a more experienced developer might have avoided by doing extra work, and you say that's not a security problem in Rails?
Young man, do not take that flippant tone with me (raps ruler on desk). Those novice developers failed to RTFM. If you want a framework that produces secure applications for inexperienced developers who do not read the fine manual, you are setting a laudable goal for Rails, but I hardly think that “Secure even for people who are 1. novices and 2. compound their ignorance by refusing to RTFM” is synonymous with “security problem.”
If you open your history book to when Rails was first becoming popular, there were many people grumbling that because it was built on top of a dynamic language that it was vulnerable to all sorts of bugs caused by novice developers getting their types wrong. The argument at the time was that Rails provided a certain type of freedom and power at the expense of certain safeguards. The same argument was played out when people started noticing that monkey-patching run amuck caused certain problems.
I agree with you that this is a design choice. If you want to say that you disagree with the choice as it was originally made, I agree with that too. I won’t say that I would have made a different choice back when that feature was first baked in, I did not write the framework. But here we are today, and it seems like a very good time to make a different choice.
What makes you think RoR was built by people with no understanding of security? Rails was one of the first frameworks to do things right (CSRF protection comes to mind).
I'd add security to that list. Rails' most notorious vulnerability was the result of an on-by-default feature that 90% of developers never even needed. I'm not suggesting that Rails is inherently insecure or that Sinatra/Rack cannot be exploited, but less unnecessary code leaves less potential for vulnerabilities; this is especially true in the Ruby world where many developers are eager to `gem install` anything with a few stars on github.
It would be interesting to see an analysis of the number and severity of Rails security issues as compared to similar frameworks with similarly sized user-bases. I would be happy to be convinced by _actual and relevant data_ that Rails has an unusual problem with security.
But until then, to me, the people complaining about Rails security sound a lot like the people that complain about Windows security. When you have a product that's used by a whole lot of people, then there's going to be a lot of incentive to find security holes and a whole lot of people using the product in sometimes hard to predict ways. This does not necessarily mean that the product is inherently less secure than alternatives, it just means it's popular.
I don't like the gist of your post. You are giving Rails way too much of a pass and assigning too much blame to GitHub. A framework should not be "insecure by design". Period. GitHub engineers are likely about as good as they get and still missed it. That's less an indictment of GitHub engineering and more so poor decision-making on the Rails side.
I respect your work Ken but I disagree with you on this.
Rails is just a web framework and does provide developers who use it with the ability to use it securely or insecurely. In this case, the shipped default leaned more toward convenience than security. There are tradeoffs involved.
GitHub provides codebase hosting to thousands of projects, some of which are private. They have a large public attack surface. And they're business which takes money. And they're probably making millions. This should imply certain things to it's management team. It's reasonable to assume they'd take security very very seriously. Perhaps not need bank-like level security, but still, pretty well up there.
Any Rails app developer has had the ability to unilaterally go into their own codebase and fix/close any security vulnerabilities. This same ability does not exist for users of the GitHub webapp. (Of course, we could choose not to use GitHub, but that would be good neither for GitHub or the user.)
That said, security is hard and getting it 100% right 100% of the time is probably impossible. And I love GitHub, and think they get more things right than wrong, enough of the time, that I'll give them the benefit of the doubt.
Yes, given we have seen issues in Core Ruby libraries (only recently updating the CSV lib), in Rails, in Ruby Gems, in Rack, it seems to pervade the Ruby Community.
I personally have been turned off from it. Not that they have security issues, everyone does, it's the time required to roll out changes basically requires not just updating a library, but updating your framework since the line between your code and the framework can be extremely blurred.
This means that if you have multiple rails sites with limited or no timely dev support you may not be readily able to upgrade your site to resolve issues.
This is why I took down my personal blog I had built in rails since I didn't want to be exposed to these issues and didn't have the time or desire to uplift the site onto more recent versions of rails.
The vulnerability is that Rails is insecure by default. That used to be the case for a lot of things, then finally people noticed how the real world works, and started fixing them. Apparently the Rails developers have actively resisted the lesson everyone else already learned.
My point is that Rails does not take the high road of providing better, sane, secure defaults for people to build their applications.
While the proposed solutions in the issues I linked to were denied, it doesn't mean there shouldn't be some solution added to Rails. This is definitely a case of convenience favored over security.
I think a big part of the problem is that there are a ton of gems that are simply hobby projects that gained traction and became popular. They were originally architected by enthusiasts, rather than experts. Some of these projects may also have been abandoned by their authors, but still in use because they may be the only way to accomplish a complex task or integration. You can't expect stuff like that to be very secure. You just have to think carefully about whether the risks of using them are worth the gains made from not having to implement the functionality yourself.
reply