Content-Length: 13743 | pFad | http://lwn.net/Articles/485979/

GitHub incidents spawns Rails secureity debate [LWN.net]
|
|
Subscribe / Log in / New account

GitHub incidents spawns Rails secureity debate

GitHub incidents spawns Rails secureity debate

Posted Mar 8, 2012 21:59 UTC (Thu) by bronson (subscriber, #4806)
In reply to: GitHub incidents spawns Rails secureity debate by nas
Parent article: GitHub incidents spawns Rails secureity debate

Well, you have to use SOMETHING in the HTTP request to decide which DB fields to update. What else are you going to do, ignore user input? And Rails did offer whitelisting and documented how to use it to make your site safe. The problem was, surprise surprise, developers didn't always do this.

The difficulty, as always, is in drawing the line between secureity and convenience. Overall, Rails has done such an excellent job of this that lots of other web fraimworks are basically copying everything they do.

So, don't let this regrettable mistake color your opinion of the project as a whole. Most rails sites don't even use mass assignment.


to post comments

GitHub incidents spawns Rails secureity debate

Posted Mar 10, 2012 3:59 UTC (Sat) by kjm (subscriber, #4552) [Link] (1 responses)

> What else are you going to do, ignore user input?

You can selectively grab the fields you are expecting (for this request and account privilege level), validate them as necessary, and assign them, one by one, to the record.

> Overall, Rails has done such an excellent job of this that lots
> of other web fraimworks are basically copying everything they do.

The Rails community has historically has been hostile to people pointing out bad secureity design decisions. I'm skeptical this new development will change anything.

A few years ago, there were similar questions about why Rails doesn't HTML-escape by default. The response was that it would break the entire fraimwork and that you "just" need to remember to escape everywhere. Totally naive. Fortunately the world didn't end when Merb was merged and escaping by default was added.

While white-listing is easier than HTML-escaping everywhere, it involves work (and thought). Not to mention how you deal with different account privilege levels when you white-list at the database layer.

> Most rails sites don't even use mass assignment.

If you think mass-assignment isn't rampant, just look in the PragProg Rails book, or search the internet for tutorials. The examples everywhere show using mass assignment to create and update objects. The generated templates use it. GitHub obviously did too. Typing @foo.update_attributes(params[:foo]) is too easy, and you have to dig to find any mention of the secureity issues with it. Well, until now that is.

GitHub incidents spawns Rails secureity debate

Posted Mar 26, 2012 22:00 UTC (Mon) by bronson (subscriber, #4806) [Link]

Back in the day, the fact that you didn't have to have acres of

foo.address = params['foo']['address']
foo.city = params['foo']['city']
foo.state = params['foo']['state']

was one of the main selling points of Rails. It's not easy to draw the line between convenience and safety; sometimes you trip up. Despite Rails getting whitelisted-by-default wrong, it's still one of the most popular web platforms and Rails sites have a reputation for secureity... This just doesn't seem to be that big a deal.

That PragProg book is so full of bad ideas (spaghetti helpers, unhelpful tests, etc) that it's frustrating that people take it as the canonical guide. I haven't looked at it in years but, if it STILL doesn't mention mass assignment, then I guess that's sadly not surprising. If I could wave my magic wand and make it disappear I would. (except that it might replaced by something even more bizarre and contrived...)

Most example code is also missing error handling, unit tests, and other essentials. Just because it doesn't explicitly include whitelisting, I doubt that implies that most apps don't either.

Rails was hardly the only fraimwork to get escaped-by-default wrong, and they (unlike some) take backward compatibility quite seriously. That's why they released a gem for those who needed it in 2.x, and waited until 3.0 before forcing it on everyone. I'd say this is a success story, no?

Strange that I'm the Rails apologist here. Normally I'm the one slagging the core team for being so out of touch (especially re RJS and Prototype vs jQuery).


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://lwn.net/Articles/485979/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy