Slashdot Mirror
Security Lessons Learned From the Diaspora Launch
patio11 writes "Diaspora, the privacy-respecting OSS social network, did a code release last week. Attention immediately focused on security. In fact the code base included several severe security bugs. This post walks through the code, showing what went wrong, and what it would let an attacker do to someone who was using Diaspora." The developer who wrote the post ends with: "You might believe in the powers of OSS to gather experts (or at least folks who have shipped a Rails app, like myself) to Diaspora’s banner and ferret out all the issues. You might also believe in magic code-fixing fairies. Personally, I’d be praying for the fairies because if Diaspora is dependent on the OSS community their users are screwed."
Here is a list of alternative open source Peer-to-peer social networking softwares
Note that The Appleseed Project has existed since 2004 and is the first.
It doesn't really matter that it's pre alpha, or whatever designation you want to give it. A platform touted as being a secure replacement for facebook ought to consist of secure code from day 1. Security needs to be built into the bones of the program, and If you read the article, you'd see that the errors made were pretty egregious. Fact is, any programmer worth his or her salt would not have started out with code like this with a plan to fix it later in future releases, they'd get it right from the very beginning. That they made these mistakes so early on speaks wonders about how inexperienced these programmers were (and hopefully are no longer now that they've learned their lesson). I'm still rooting for Diaspora but am a little disappointed by this.
Quid festinatio swallonis est aetherfuga inonusti?
Africus aut Europaeus?
Exactly. It does exactly what it's supposed to do: Instead of having a single mega-corp have complete control of your data, it does completely the opposite and lets everyone in the world have complete control of your data! It truly is the anti-Facebook.
I mean, nothing seems to point to me that this is shill garbage coming from facebook, but the conceptual idea of Diaspora is sound and the code was released for the precise reason of improving it, as it has done ...
Okay well, sometimes I look at code and I think "good start" and then sometimes I feel like Simon Cowell ... and ask them to start over. So to determine where I stand with the Diaspora code, allow me to quote the article:
This basic pattern was repeated several times in Diaspora’s code base: security-sensitive actions on the server used the params hash to identify pieces of data they were to operate on, without checking that the logged in user was actually authorized to view or operate on that data. For example, if you were logged in to a Diaspora seed and knew the ID of any photo on the server, changing the URL of any destroy action from the ID of a photo you own to an ID of any other photo would let you delete that second photo. Rails makes exploits like this child’s play, since URLs to actions are trivially easy to guess and object IDs “leak” all over the place. Do not assume than an object ID is private.
Okay, I taught myself how to use the rails framework and code Ruby. And one of the things I was amazed at was the Rails magic. Because of how powerful it can be (both good and bad). Yes, it helps you prototype but it's errors like these that make me pause and reconsider if the person coding Ruby on Rails really understands how the framework is attempting to assist them. Obviously if you allow any user to enter any ID of a record in their URL for any CRUD action ... you aren't really understanding what those routes are trying to do for you. And you're a danger to your users.
While I could quickly remedy the above problem for the Diaspora team by improving the authentication and authorization code checks, it might be better to just start over. Now, I've devoted none of my time to the concept of liberating social network users and for that I thank the Diaspora team. This blog posting -- if true -- sure is a vote of no confidence for their capabilities of developing a realistic system. Can they improve? Certainly. But if you're making errors like that, you might be better off letting someone else take a stab at this. It's a harsh thing to say but you don't understand the tool you're using to prototype if you're even starting at this point.
I wish them the best of luck and I hope the community reaches out to them. But I'm not interested in recoding everything. I'd sooner simply start my own project.
My work here is dung.
I would agree, but that code was some junior level bullshit. Granted I haven't been doing this for 20 years, but damn that was some horrible coding going on there. Especially when they tout it as some super great OSS alternative to facebook. It almost made me question how good of a choice Ruby on Rails was for the entire project.
Hold up, wait a minute, let me put some pimpin in it
(my bold) So he's not actually saying anything bad at all about OSS; he's just saying that being OSS doesn't mean that they can magically gain experience (or experienced developers) and fix their entire codebase in a month. The notion that OSS development is to blame was purely down to Slashdot (or the submitter).
There is no Silver Bullet in coding. You can't get it right from the beginning always...
Oh come *on*. The errors in this code were deeply fundamental, and patently obvious to anyone paying any attention. Not authorizing actions performed by authenticated users? Really?? Jesus christ, that's *basic*.
Sorry, no, what we're talking about, here, are fundamental flaws in their security architecture (or, more to the point, a complete lack of security architecture). And security architecture is something you *have* to get right up front (which is why good software architects cost a lot of money... it's necessary work, and hard to do well).
A former employer of mine had a team build a proof of concept for a large and critical piece of software, on which much of the business would rely. The team worked for several months and produced a functioning proof of concept, which they demonstrated to the management. Management took a good look and said, "Great, install it, and support it."
Within a few more months almost all of the team had resigned in frustration.
As far as I know, that proof of concept is still in place, with teams of people dedicated to keeping it duct taped enough to keep staggering on.
The real, serious, carefully constructed and tested software never got built.
Somehow, I doubt this is a unique tale.
Moral of the story: start it the way you intend to keep on.
WALSTIB!
I don't really understand what's wrong with this blog author, this "Patrick" fellow. Diaspora is git-release of a pre-alpha. It's essentially proof-of-concept which was released so we can have a look at it and contribute.
And it contains flaws in its security architecture that are so basic, so deeply fundamental, that it's impossible to have any confidence in the development team. Security and scalability *must be architected up front*. Tacking it on after the fact is a recipe for disaster. And it's blatantly obviously that the people working on the project don't understand this.
Goddammit kdawson. That's it, your articles are blocked. You're the f***ing New York Post of Slashdot. Whatever merit any article you post may have you manage to completely overpower it with sensationalist editorial bias.
Security is part of the design, not the implementation.
Most developers still haven't learned that security isn't something you check for at various access points in the code: it is something you build directly into the business layer. For example, your code should not have a method like this anywhere:
public DeletePicture(int pictureID)
The method should be:
public DeletePicture(SecurityCredentials user, int pictureID)
This way it is impossible for your web to accidentally call DeletePicture() without checking for security. The security check is built-in to the lower-level and there is nothing you can do about it. Having worked on secure web services before, I realize I did not do this in my design, which was great for making simple tools, but it meant that all user-facing code had to have checks for security loopholes. The web is especially weird because users can hack the pages and the HTTP requests to call your methods in ways you never