[steveklabnik]

> 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.

[lgleason]

+1 Steve

Part of being a good developer is understanding your framework and making sure that your app has the level of security you need. The framework cannot protect you from everything.

The team responded really quickly. Aaron is a really talented developer and a nice guy. We should all be thanking him. If you don't feel that enough emphasis is being put into security in rails beat away at it, find holes and then get involved in developing fixes for them. That is the beauty of open source.

Matz developed Ruby for adults. You get a lot of power, but also a lot of rope to hang yourself with. This is why testing in rails applications is so important.

[marshray]

http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulner...

Here are some good and experienced Rails developers who apparently had no idea that Rails would automagically suck in XML and YAML and turn it into symbols instead of strings.

Clearly they aren't the only ones who didn't "understand the framework" or we wouldn't have gone a week with the impression that CVE-2012-5664 was only exploitable in specific circumstances.

[lgleason]

That's not my point....

I made the "understand the framework" statement in response to some mistakes I have seen introduced by sloppy dev's on some rails projects I have worked on...That obviously wasn't the case here.......

If security is important you should periodically try to hack the system and consider incorporating automated penetration testing software against your application. I haven't had a need to go this far with my own recent apps so I cannot speak authoritatively on this, but I think there are some tools that can help with doing penetration testing etc..

In a past life I had to work on some pretty secure systems and did some crazy testing on things. I saw a lot of good developers introduce pretty big security holes....my favorite was when our /etc/password was served up by an application...and this was a well known team of craftsman that did this on a fairly large project. None of these have been limited to Ruby projects....they have included Java, C etc..

In my view security is a moving target. If the cost of a attack warrants the effort to protect against it then you do. If not then you don't. Even if the developers of the framework concentrate on security, there will always be ways to get around it. Safe's are rated on the amount of time it takes to break into them, if someone wants into bad enough they will get in. The same is true with software.

Should I be more aware of the security on my apps? probably. Should we as a community be better with it? Yup. But unless I've taken the time to really dig into it, offer constructive feedback and be willing to jump in to fix it I have no business criticizing the state of things.

And I say all of this as someone who loves Ruby.

[marshray]

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.

[lgleason]

Rails has definitely started to get complex, which is why many have chosen to go towards the simplicity of Sinatra, Rack etc.. Any time a framework get's complex this happens.

Look at big data and AI. There are loads of permutations. How do you prevent stuff from just happening? How do you make sure that things are correct etc.? Trust me I would love to do TDD on an AI / big data analysis project. But the reality is that no-one has figured out how to reliably test things....so TDD is not the right tool at this point. But there is also the potential to introduce vulnerabilities. That doesn't mean I am not going to use AI or do big data.

It's always a balance between tighter security/less complexity, or more complexity and less security etc...obviously there are other factors as well, but my point is to choose the right tool for the job.....sometimes it is Rails, and sometimes not......

And beyond that give the Rails team kudos for a taking care of things like this when they do find them.

[marshray]

Let us agree in giving the Rails secuity team many well-deserved thanks!

We on the sidelines primarily criticise as a stage of our shock and grief. That the patches keep flowing is unsettling in the short term but reassuring in the long term.

Thanks again everyone who dropped everything and worked so hard to get this set of fixes out!

[subsystem]

I really hope this isn't the sentiment of the RoR community. There has to be a place for critique when it's warranted. At this scale it's not a joke any more, you ask for what you need and otherwise you do less.

[steveklabnik]

I specifically asked them to elaborate on what could be made better.

[lambda]

Less magic.

The more magic, unexpected behavior you have when parsing untrusted input, the more likely you are to have security holes.

Instead of building up some complex object based on untrusted input, the author of the application should specify the values and types expected, and the parser should parse those and nothing more. This would lead to much simpler code paths, as the user never has an object that has unexpected keys, values, behaviors, etc. Don't parse the object using complex, general purpose code, then hand the user an object that they have to treat specially; if their form only expects 5 values of given types, then parse only those values and those types.

The problem is, all of this kind of magic is at the very heart of what Rails is. I don't know if you could eliminate it all and still have Rails be Rails.

[nthj]

This sounds a lot like strong_parameters, which (I believe) will be the default in Rails 4, and is only a gem install away from Rails 3.2 apps.

https://github.com/rails/strong_parameters

[steveklabnik]

It will be the default, yes.

[subsystem]

There are specific things that could be said about the bug in question, like not being secure by default, but this doesn't fix the underlying problem. The development team should recognize that security is an important part of the project and act accordingly.

[steveklabnik]

Seems reasonable. How did they not 'act accordingly' in this case? What should be different about the security process currently in place?

[smackfu]

Nothing gives me confidence in a platform like "almost nobody is even paid to work on Rails."

[InclinedPlane]

I agree, this is a dangerous sentiment.

Whether money is involved or not, for a framework, developers should either be committed to their products or not.

If this was a different sort of product then that limitation of not getting paid might carry some weight, but when you encourage people to develop on top of your platform and when it is shown to have egregious flaws there is no excuse. You either get to work fixing them or you tell the world to stop using your framework because it's broken and not going to be fixed.

Fortunately, the Rails devs are seriously committed to their product, which is why these fixes came out so quickly.

Edit: The Rails team is certainly deserving of many thanks, but they don't get a pass on problems just 'cause they work for free. Similarly, if someone gives me a free car I will thank them, but if that car starts a fire in the garage and burns down my house I will curse them too.

[steveklabnik]

I'm sure some Core developers would love your sponsorship to give even more time to devote to Rails development.

Even without the money, this issue was dealt with swiftly. See the comments below about 'the Rails security team is the best vendor I've worked with.'

[awj]

Yes, judging platforms by how many people are paid to work on them instead of track record or other verifiable merits is totally the best way to go.

[lgleason]

I thought some come of the core committers had their work sponsored by their employers.

[steveklabnik]

Aaron is the only person on core who is paid to work on Rails. (Among other things.)

I am a committer, and part of my job is to work on open source. Ish.

Other than that, it's everyone else's spare time, IIRC.

[lgleason]

Wow, that actually gives me more confidence because we have people doing it because they feel passionate about it. Thanks for your hard work....

I've been busy with some other small OS projects (and stuff that pays the bills) but personally feel like I need to try to carve out some time this year to do something to contribute back to Rails.....

[steveklabnik]

<3

If I can help you help us somehow, please let me know.

[mikeycgto]

If you've recently started a new Rails project (or are thinking about it), you should use strong_parameters right off the bat!

[joevandyk]

I'm not 100% positive, but I don't think strong_parameters would do anything to protect you here.

[steveklabnik]

It would not have helped with this vulnerability, no. But it is a better way of handling filtering appropriate parameters.

[pekk]

Why is strong_parameters not the only way? Rails is pretty opinionated in many other respects...

[bratsche]

It was opinionated to use attr_accessible until a better approach came along. Beginning in 4.0 it will be opinionated to use strong_parameters, but they can't just take attr_accessible away because a lot of people are upgrading apps.

[jenius]

It will be the default in rails 4... so soon : )

[steveklabnik]

The downside of 'don't break APIs for minor version changes' means that you can't break APIs until the major version changes. ;)

[steveklabnik]

Agreed! That is what I teach when I do training.

[nachteilig]

This is actually the first I'm seeing about strong_parameters, since I don't follow Rails 4 stuff much right now. Thanks for the tip!

[steveklabnik]

Any time. Please let me know any issues/problems/thoughts you have with it.

[sj26]

Cost/benefit.

There are always going to be security holes in anything we make. We can be a bank and focus two feet ahead on making sure everything is as secure as possible, or stay aware of security (and not do anything stupid) while moving fast enough that any flaws are irrelevant/fixed when exposed.

It also highly depends on how much risk you're willing to accept. For the average rails app, absolute security is not as important as moving fast. Be an adult and make adult decisions about your tools and processes to suit your circumstances.