I have to say that sort of stuff put me off Rails a bit. If you compare to Django for example for code execution vulnerabilities it's Django 0, Rails 11. Though Django has maybe 1/3 to 1/2 as many users as Rails it's still enough for it to be pretty well tested out.
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.
I agree with you about the grating self-satisfaction of a certain vocal set of commenters, and have argued in the past myself that there is no "magic" in Rails, but I think what people really mean when they say "magic" as related to a chunk of software, is that it has so many layers of abstraction that its function is obscured.
All software deals in layers of abstraction, which makes it easier to reason about general function, but obscures specific function. All users of all software must make a constant trade-off between assuming abstractions are functioning properly and personally verifying their function, and all software must decide where the line between too little abstraction and too much obscurity should be drawn. When people talk about the "magic" in Rails, they mean that Rails has drawn that line quite far toward the abstraction side, which is true.
There are some abstractions that are a net positive for security, and some that hinder it. While I don't agree with the condescending attitude of your parent and the many similar commenters, who seem to think no software they've ever written or integrated with has ever had a security issue, I think it is fair at this point to say that the level of abstraction in Rails' handling of user data has been a hindrance to its security. I think that is probably also a fair thing to say about most pieces of software that have ever handled potentially-malicious user data.
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 philosophy and nature of the features Rails provides are what causes these security vulnerabilities. Auto-magic features are prone to this sort of exploitation.
I'm just saying Ruby is good at enabling DWIM and Rails has taken it and run with it to the point of magical thinking.
It's very hard for an app developer to test for vulnerabilities such as this one which seem to involve a combination of contributory factors. When magical stuff is constantly willing to help the app developer out in the background, it's very difficult to get a handle on what our true attack surface is.
The initial bug in Ruby/Rails is striking in its stupidity.[1] You can send something to Ruby/Rails in a session cookie which, when unmarshalled, stores into any named global variable in the namespace of the responding program. It's not a buffer overflow or a bug like that. It's deliberately designed to work that way. It's like doing "eval" on untrusted input. This was on YC years ago.[2] Why was anything so idiotic ever put in Ruby at all?
Something like this makes you suspect a deliberate backdoor. Can the person who put this into Ruby/Rails be identified?
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.
You're getting downvoted because security issues are far from unique to Ruby on Rails. Are you aware of any web frameworks with a pristine security history?
Rails has a special track record for convenient magic implicated in security vulnerabilities.
Another commenter gave a good example theory implicating a convenient-but-questionable out of the box behavior of Rails: https://news.ycombinator.com/item?id=28537562
The good news is Rails has been slowly moving away from the magic over the years - it used to be a lot worse.
reply