Multiple vulnerabilities in parameter parsing in Action Pack

All software has bugs, and the subset of bugs which turn out to be security vulnerabilities is borderline asymptotic.

That's not to say all frameworks are created equally secure, but the differences have more to do with the culture around the project than any technical decisions (minus some very specific language-related issues).

Rails is a big, public project; with many years now of being used by a sizable number of people. There will be more security vulnerabilities discovered, hopefully they'll be addressed quickly and communicated well (which this one seems to be).

That's a long-winded way of saying to be cautious with picking some other framework because it has less security vulnerabilities reported, that almost certainly has no bearing on it being more secure.

Who'd have thought it? Hugely dynamic language turns out to be difficult to audit or analyse for security issues.

It was never about Java(C, C++) vs. Ruby despite what fanboys on either side made out. It was about conservative vs. devil-may-care. All that "convenience" and "it's so clean" came at the price of a whole load of code executed behind the scenes. You didn't write it, and the Gods of TDD preached that you don't need to test it because that's Someone Else's Problem. Auditing it is nearly impossible not least because it's a moving target, so you either get stuck in a backwater of obsolete versions that once got audited and approved or you live on the bleeding edge constantly (and DevOps hate you forever).

FWIW we (large satnav company) prototyped the last major service in Rails (actually a one-man hack proof of concept) then implemented it in production in Scala (and that was a bridge too far for a lot of people) because no-one wanted to run Rails in production.

The last Rails SQLI vulnerability was mitigated by the way ActionPack parsed request parameters, so lots of people dove into that code to see if the mitigation could be evaded with JSON or XML. That gave people incentive to review Rails XML parser wrapper class. The problem with that class is pretty obvious.

I'd guess multiple people working together, or multiple people who got hit by someone exploiting it in the wild.

> why isn't there more of a focus on security here?

More compared to what, exactly? This vulnerability was responded to pretty damn quickly after it was reported, given that almost nobody is even paid to work on Rails. If you saw Aaron tweeting about "working over the weekend" a few days ago, well, now you know.

That said, you mention attr_accessible in your post: that's gone as of the next release of Rails. Basically everyone agrees that strong_parameters is a better approach, which is why a gem was released that works with 3.2: you can use that better approach now.

As was mentioned below, security is a process, not a result. Nobody wants these kinds of issues to happen, but they will happen, and do to every single framework that's used by lots of people.