The smell of late night coffee, having to update Ruby on Fails yet again, or better, the colder more bitter coffee in the morning, when having to offline and rebuild a compromised server due to this framework.
It started with such promise, and now, we are looking to migrate all Rails apps off to alternative frameworks at the first opportunity. It really is a shame.
The usual fallacy: "the more vulnerabilities found on a piece of software the less secure it is."
That just doesn't logically follow: your chosen alternative framework just might have not been thoroughly audited (yet.) Or not audited by the right people, etc.
Actually I see it more of indicative problem with the design of Rails. We keep getting told we should like magic, convention over configuration, but maybe it would be better to have a config file where we can turn the magic off in Rails.
But please, no more Yaml files - it seems parsing Yaml has already caused enough holes in Rail this quarter.
This is good advice in general, but Rails used the wrong kind of parser for this kind of data. JSON is not YAML. A YAML parser does not provide the same guarantees as a JSON parser about its output. It doesn't matter if both parsers are completely correct if you use them inappropriately.
My understanding is that YAML is supposed to be highly general-purpose and is not supposed to be resilient to malicious input. These aren't YAML parser bugs, these are framework bugs that pass malicious data to the YAML parser when that parser should never be exposed to it. And that in turn appears to be entirely due to an extremely overly-helpful and magical nature of the framework.
Nope, the problem is not due to the magical nature of the framework.
They implemented the JSON decoder with a JSON to YAML converter, passing that through the YAML decoder.
The fix involves using an actual JSON parser and skip the going through YAML part. So it does qualify as a JSON parser bug, IMO (which is what I clumsily attempted to imply with my "(or JSON)" clause above.)
What if I told you that there is a new web framework similar to Rails, called Fortran on Fails. It has zero vulnerabilities reported against it, ergo it must be 100% secure.
> Symfony applications are not vulnerable to this attack
And it definitely has not the same track record. For example, it has been audited by a security company in one of the first versions. So far I have only seen minor security vulnerabilities, nothing like what Rails brings every week.
Anyway, that's not why I changed. I found it to be much better architected, 100% decoupled (as opposed to monolithic). You can change anything you want if you have to, or if you find better vendors and want to try them. It has actually been designed from day 1, and not by someone who has read about design patterns little time before creating the framework, and calls himself 'the master chef'.
Having an OOP background, I thought (I don't remember why) Ruby/RoR community was some sort of elite, and everyone had a much higher minimum level (as opposed to php, where most people are noobs). I was disappointed, most of them didn't even understand what interfaces were for (no wonder ruby hasn't added them yet), let alone knowing the most basic design patterns. They also seem to enjoy laughing at developers from other languages. All this was a pain to watch, but I didn't care as long as Rails was perfect, and that's how I felt about it at first. But it wasn't, so I moved to Symfony2, and found out not only the framework was superior, but also the community was awesome.
It started with such promise, and now, we are looking to migrate all Rails apps off to alternative frameworks at the first opportunity. It really is a shame.