Weapons of Mass Assignment: Patio11 on Diaspora
queue.acm.org
queue.acm.org
I was honestly surprised when I got asked to edit this for the ACM, but couldn't say no to Achievement Unlocked: Journal Publication. Content-wise it is virtually identical to the blog post I did after Diaspora patched the issues I reported to them. The tone got radically altered from my Internet voice to my academic voice, which is rather rusty, so I apologize if it reads poorly.
In any event: congratulations on the CACM publication-- that's a quite impressive academic credential, if those things matter to you.
It scratches one thing off the bucket list, and many members of my family who expected me to go get a PhD will be tickled by it. In terms of actual utility, it is highly unlikely I'll ever have a CV again, but it makes a nice thing to have for e.g. visa applications. "Published in a prestigious academic journal" matters more to the Ministry of Justice than "has a whole lot of HN karma."
Now all I need is to find someone to cite it in Japanese...
Personally, there are a lot of things I value more highly than their actual utility, but then again, I'm fairly close to entering a PhD program in Buddhist Philosophy, so I'm pretty well acquainted with the notion.
> * For example, Rails could default to mass assignment being available in development environments, but disabled in production environments (which are, typically, the ones that are accessible by malicious users).*
That is a really bad idea. All it would do is create broken code in production that could not be debugged in development mode.
I may be way wrong here, but: didn't this particular suggestion come from an HN comment? I seem to remember when there was a flurry of Diaspora articles, that a comment mentioned this as a good example of Ruby monkey patching, and one of my "heroes" (so, patio11, or maybe tpatacek?) acknowledged it as a simple and beautiful solution.
Hmm... off to see if I can find what I'm thinking of.
edit: oh, ha! Found the link: http://news.ycombinator.com/item?id=1718422 . I was sort of right, sort of wrong. It was an HN comment, but it was actually patio11's own comment to tpatacek, who thought it was a great idea!
The thing you'll run into with that approach is that no authors of gems and plugins that include AR models declare attributes as accessible, effectively assuming that mass assignment is enabled and resulting in the gem/plugin not saving properly. I've had to fork and submit patches for every hugely popular gem with AR models I've used, so it appears practically no one else follows this approach in production apps.
I strongly suspect that leaving all attributes mass assignable on all models other than generated user models is extremely common in Rails apps and it's very likely that this vulnerability is ubiquitous.
Edited to add: Now I remember. The second gem was actually A/Bingo (a plugin). I fixed this back in January.
This is incorrect. Rails 3 (and 2.3) are thread-safe. They typically run in multiple processes because of Ruby's GIL.
Moreover, it's irrelevant. As I mentioned, this is unrelated to why Rails apps are typically run as multiple processes.
Wether it is a good idea to publish an alpha with demo that contains many known -TODO- security holes and -issues is another idea. But it is unfair to start calling Diaspora "a failure" or "an amateurish piece of xxx" (not my words, but heard them said after this article) because of not-yet-implemented security features (such as authorisation).
By now, the entire Diaspora is/was rewritten in My/PostgreSQL, most of mentioned issues are already dealt with, or are under contstruction.
"Amateurish failure" pretty much nails it, if you ask me, and if the Diaspora guys were working for me, I'd be showing them the door as quickly as I could manage it. That may sound harsh, but it's the voice of hard-earned experience.
The irony of its all is that Facebook's privacy issues has nothing to do with open/closed source. They can open they're entire source-tree tomorrow, it wouldn't make them more privacy-oriented than now. It's not how they collect the information or how they store it, but what they do with it and with whom they share it.
>"Amateurish failure" pretty much nails it
I think part of the problem here is, as much as those guys have good intention, the whole affair was ill-handled from the start. From the get-go, asking for money before showing any effort made me sceptical of the whole affair. The amount of exposure and money they got, without anything even resembling code, or implementation details was absurd. And then, what they initially came up with could've been done by a few software devs working on their free time, and was riddled by security issues. My advice to those guys is to use the money and hire some good programmers, which is what most startup guys do.
If they can't deal with beginner level stuff, how well do you think they will do with much harder problems like XSS?
Edit: Actually I really want to drive this point home: you wouldn't write a TODO for any of these things because it would take you as long to write the TODO as it would take to fix them.
Regardless, the purpose of publishing this isn't to grind Diaspora's nose in it. It is to help someone -- profs, students, or (scarily) someone who gets paid for this -- avoid shipping software in this state in the future.
I know when I build I like getting the scaffold/mvp up as quickly as possible ignoring security because hey, this thing isn't out in the wild, and do my due diligence on security after I am happy with the prototype.