Security Lessons Learned From The Diaspora Launch

Last week, Diaspora — the OSS privacy-respecting social network — released a “pre-alpha developer preview” of their source code.  I took a look out it, mostly out of curiosity, and was struck by numerous severe security errors.  I then spent the next day digging through their code locally and trying to get in touch with the team to address them, privately.  In the course of this, I mentioned obliquely that the errors existed on Hacker News, and subsequently was interviewed by The Register and got quoted in a couple of hundred places.

The money quote most outlets went for was:

The bottom line is currently there is nothing that you cannot do to someone’s Diaspora account, absolutely nothing.

I’d like to back up that contention, now that it is safe(r) to do so.

Reporting security bugs is a funny business: any description of the error sufficient to resolve it is probably sufficient to create exploit code.  This is why I was fairly circumspect about the exact mechanism for the errors, and why Steve Klabnik also mostly declined to give specifics when describing the state of the codebase.  Since the specific errors I reported are now patched, I’m going to disclose what they were, so that budding Rails developers who care about security do not inadvertently give attackers the ability to do anything they want.

By the way, if you’re looking for Rails security advice, I recommend the official guide and the OWASP list of web application vulnerabilities, which would have helped catch all of these.  Web application security is a very deep topic, and often involves unforeseen circumstances caused by the interaction of complicated parts which are not totally under the developers’ control.  That said, nobody should be making errors like these.  It hurts us as developers, it hurts our ecosystem, and it endangers our users in spite of the trust they have put in us.

I found somewhere in the ballpark of a half-dozen critical errors — it depends on how you count pervasive mistakes that undermined virtually every class in the system.  There were three main genres.  All code samples are pulled from Diaspora’s source at launch, were reported to the Diaspora team immediately, and have been reported to me as fixed.

Authentication != Authorization: The User Cannot Be Trusted


#In photos_controller.rb
def destroy
    @album = Album.find_by_id params[:id]  # BUG
    flash[:notice] = "Album #{} deleted."
    respond_with :location => albums_url

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.

(There is a second error here, by the way: the code doesn’t check to see if the destroy action is called by an HTTP POST or not. This means that an overenthusiastic browser might follow all links from a page, including the GET link to a delete action, and nuke the photo without any user action telling it to do so.)

You might think “Surely Diaspora checks to see if you’re logged in, right?” You’re right: they use Devise, a library which handles authentication, to verify that you can only get to the destroy action if you’re logged in. However, Devise does not handle authorization — checking to see that you are, in fact, permitted to do the action you are trying to do.


When Diaspora shipped, an attacker with a free account on any Diaspora node had, essentially, full access to any feature of the software vis-a-vis someone else’s account. That’s pretty bad, but it gets even better when you combine it with other errors.

How to avoid this:

Check authorization prior to sensitive actions. The easiest way to do this (aside from using a library to handle it for you) is to take your notion of a logged in user and only access members through that. For example, in my software, any action past a login screen has access to a @user variable. If an action needs to access one of their print_jobs, it calls @user.print_jobs.find(params[:id]). If they have subverted the params hash, that will find no print_job (because of how associations scope to the user_id) and they’ll instantly generate an ActiveRecord exception, stopping any potential nastiness before it starts.

Mass Assignment Will Ruin Your Day


def update
  @user = User.find_by_id params[:id]  # <-- uh oh, no auth check

  @user.update_profile params[:user]  #  root_url)

def update_profile(params)
  if self.person.update_attributes(params)  #  <-- insert input directly to DB

Alright, so we know that if we forget authorization then we can do arbitrary bad things to people. In this case, since the user update method is insecured, we can meddle with their profiles. But is that all we can do?

Unseasoned developers might assume that an update method can only update things on the web form prior to it. For example, this form is fairly benign, so maybe all someone can do with this bug is deface my profile name and email address:

Diaspora Profile Update Page

This is catastrophically wrong.

Rails by default uses something called “mass update”, where update_attributes and similar messages accept a hash as input and sequentially call all accessors for symbols in the hash. Objects will update both database columns (or their MongoDB analogues) and also call parameter_name= for any :parameter_name in the hash that has that method defined.

Let’s take a look at the Person object to see what mischief this lets us do. (Right, instead of updating the profile, update_profile updates the Person: Diaspora’s internal notion of the data associated with one human being, as opposed to the login associated with one email address (the User). Calling something update_profile when it is really update_person is a good way to hide the security implications of code like this from a reviewer. Names matter — make sure they’re accurate.) What methods and fields do you expose…

class Person
  key :url,            String
  key :diaspora_handle, String, :unique => true
  key :serialized_key, String   #This is your public/private encryption key pair.  OOPS.

  key :owner_id,  ObjectId   #You don't want me changing this one either...

  one :profile, :class_name => 'Profile'
  many :albums, :class_name => 'Album', :foreign_key => :person_id
  belongs_to :owner, :class_name => 'User'   #... because it lets me own you!  Literally!


one :person, :class_name => 'Person', :foreign_key => :owner_id  #Oh dear.

This is painful: by changing a Person’s owner_id, I can reassign the Person from one account (User) to another, allowing me to both deny arbitrary victims from their use of the service and also take over their account, allowing me to impersonate them, access their data at will, etc etc. This works because one in MongoDB picks the first matching entry in the DB it can find, meaning that if two Person have the same owner_id, your account will non-deterministically control one of them. So I’ll assign your Person#owner_id to be my #owner_id, which gives me a fifty-fifty shot at owning your account. If that is annoying for me, I can always assign my Person#owner_id to have some nonsense string, de-linking them and making sure current_user.person finds your data when I’m logged in.

But wait, there is more!: Note the serialized_key column. Can you guess what that is for? Well, if you follow some spaghetti in the User class, that is their serialized public/private encryption key pair. You might have heard that Diaspora seeds use encryption when talking between each other so that the prying eyes of Mark Zuckerberg can’t read your status updates. Well, bad news bears: the attacker can silently overwrite your key pair, replacing it with one he generated. Since he now knows your private key, regardless of how well-implemented your cryptography is, he can read your messages at will.

This is what kills most encryption systems in real life. You don’t have to beat encryption to beat the system, you just have to beat the weakest link in the chain around it. That almost certainly isn’t the encryption algorithm — it is some inadequacy in the larger system added by a developer who barely understands crypto but who trusts that sprinkling it in magically makes it better. Crypto is not soy sauce for security.

Is this a hard attack? No. You can do it with no tool more complicated than Firefox with Firebug installed: add an extra parameter to the form, switch the submit URL, own any account you like. It took me two minutes to find this vulnerability (I looked at the users controller first, figuring it was a likely place for bad stuff to happen if there was bad stuff to be found), and started trying to get the word to the Diaspora team immediately. It literally took longer to get Diaspora running than it took to create a script weaponizing this.

Steps to avoid: First, fix the authentication. That won’t prevent this attack, though — I can still screw up my Person by changing it’s owner_id to be yours (and do this an arbitrary number of times), virtually guaranteeing that I can successfully disassociate your account from your person.

After you fix authentication, you need to start locking down write access to sensitive data. Start by disabling mass assignment, which should be off in an public-facing Rails app. The Rails team keeps it in because it saves lines of code and makes the 15 minute blog demo nicer, but it is an easy security hole virtually anywhere it exists. Consider it guilty until proven innocent.

Second, if your data store allows it, you should explicitly make as much as feasible unwritable. ActiveRecord lets you do this with attr_readonly — I’m not sure whether you can do it with MongoMapper or not. There is almost certainly no legitimate reason for owner_id to be reassignable.

NoSQL Doesn’t Mean No SQL Injection


  Person.all('$where' => "function() { return this.diaspora_handle.match(/^#{query}/i) ||
               this.profile.first_name.match(/^#{query}/i) ||
               this.profile.last_name.match(/^#{query}/i); }")

Diaspora uses MongoDB, one of the new sexy NoSQL database options. I use a few myself. They have a few decades less experience getting exploited than the old relational databases you know and love, so let’s start: I claim this above code snippet gives me full read access to the database, including to serialized encryption keys.

What the heck?!

Well, observe that due to the magic of string interpolation I can cause the string including the Javascript to evaluate to virtually anything I want. For example, I could inject a carefully constructed Javascript string to cause the first regular expression to terminate without any results, then execute arbitrary code, then comment out the rest of the Javascript.

We can get one bit of data about any particular person out of this function: whether they are in the result set or not. However, since we can construct the result set at will, we can make that a very significant bit indeed. One thing Javascript can do is take a string and convert it to a number. I’ll elide the code for this because it is boring, but it is fairly straightforward. After I have that Javascript, I can run a binary search to get someone’s serialized_key. “Return Patrick if his serialized key is more than 2^512. OK, he isn’t in the result set? Alright, return Patrick if is key is more than 2^256. He is in the result set? Return him if his key is more than 2^256 + 2^255. …”

If their key has 1,024 bits (wow, so secure), it will take me roughly 1,024 and change accesses to find it. That will take me, hmm, a minute? Two? I can now read your messages at will.

I think MongoDB will let me do all sorts of nastiness here aside from just reading parts of the person object: for example, I strongly suspect that I can execute state-changing Javascript (though I didn’t have any luck making a Lil Bobby Tables to drop the database, but I only spent about two minutes on it) or join the Person document with other documents to read out anything I want from the database, such as User password hashes. That might be a fun project for someone who is not a complete amateur.

Code injection: fun stuff for attackers, not quite so fun.

How to avoid this:

Don’t interpolate strings in queries sent to your database! Use the MongoDB equivalent of prepared statements. If MongoDB doesn’t have prepared statements, don’t use it for your security-critical projects until it does, because you will be exploited.

Take Care With Releasing Software To End Users

Since making my public comments, I have heard — over and over again — that none of the above matters because Diaspora is in secret squirrel double-plus alpha unrelease and early adopters know not to put any data in it. False. As a highly anticipated project, Diaspora was guaranteed to (and did) have publicly accessible nodes available within literally hours of the code being available.

People who set up nodes might be intelligent enough to evaluate the security consequences of running them. That is actually false, because there are public nodes available, but we’ll run with it. Even if the node operators understand what they are doing, their users and their users’ friends who are invited to join The New Secure Facebook are not capable of evaluating their security on Diaspora. They trust that, since it is on their browser and endorsed by a friend, it must be safe and secure. (This is essentially the same process by which they joined facebook — the zuckers.)

How would I have handled the Diaspora release? Well, candidly, I wouldn’t have released the code in the current state, and instead would have devoted non-trivial effort to securing it prior to release. If you put a gun to my head and said “Our donations came from 6,000 people who want to see progress, give me something to show them”, I would have released the code that they had with the registration pages elided, forcing people to only add new users via Rake tasks or the console. That preserves 100% of the ability of developers to work on the project, and for news outlets to take screenshots, without allowing technically unsophisticated people to successfully sign up to the Diaspora seed sites.

I don’t know if the Diaspora community understands how bad their current security posture is right now. Looking at the public list of public Diaspora seeds, while the team has put a bold disclaimer that the software is insecure (which no one will read because no one reads on the Internet — welcome to software, guys), many of the nodes are explicitly appealing as safer options which won’t reset their DB, so you won’t lose your work if you start on them today. That is irresponsible.

Is Diaspora Secure After The Patches?

No. The team is manifestly out of their depth with regards to web application security, and it is almost certainly impossible for them to gather the required expertise and still hit their timetable for public release in a month. 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. There are, almost certainly, exploits as severe as the above ones left in the app, and there almost certainly will be zero-day attacks by hackers who would like to make the headline news. “Facebook Competitor Diaspora Launches; All Users Data Compromised Immediately” makes for a smashing headline in the New York Times, wouldn’t you say?

Include here the disclaimer that I like OSS, think the Diaspora team is really cool, and don’t mean to crush their spirits when I say that their code is unprofessional and not ready to be exposed to dedicated attackers any time soon.

About Patrick

Patrick is co-founded Starfighter, founded Appointment Reminder and Bingo Card Creator, and presently works at Stripe on Atlas. (Opinions on this blog are his own.) Want to read more stuff by him? You should probably try this blog's Greatest Hits, which has a few dozen of his best articles categorized and ready to read. Or you could mosey on over to Hacker News and look for patio11 -- he spends an unhealthy amount of time there.

130 Responses to “Security Lessons Learned From The Diaspora Launch”

  1. Andrey Butov September 22, 2010 at 7:48 pm #

    Good post Patrick.

    I think it helps to have a certain mindset during app dev.

    I remember, especially when writing my first few web apps, the first thought in my head when writing any controller was “Oh shit … can the user type a different number in the URL and get to someone else’s data”?

    A certain bit of … paranoia … comes in useful with these things.

  2. Dave September 22, 2010 at 7:53 pm #

    Thank you VERY, VERY much for what you have done, for following up, and for being very clear.

  3. Shamit Kumar Tomar September 22, 2010 at 8:15 pm #

    Awesome post. Nice effort to bring it out.

  4. Will Cannings September 22, 2010 at 8:56 pm #

    You’re right Patrick, at the moment there are a lot of security issues with the codebase, but I disagree that it’s an insurmountable challenge for the team to fix them. Some of the issues your raised aren’t actually issues, and Rails makes it quite easy to fix the rest:

    – not checking authorisation is the most glaring and easily abused problem, but it can be fixed quite easily with a before_filter. They’re using pretty well structured controllers most of the time accessing a single model or two, so adding simple auth checks around the actions is pretty simple (and wouldn’t require much rewriting of each action)

    – Rails is already preventing the delete action being called by a GET request because they used the resources method in their routes file

    – update_attributes doesn’t do a double assignment. In both mongo_mapper (the lib they’re using for mongo) and ActiveRecord an assignment method is called to set the value. In mongo_mapper this method may not always exist so the value may be set directly on the underlying values hash, but only one or the other assignments is used (this is never a problem in AR).

    – update_attributes respects privacy on fields set by attr_protected (and mongo_mapper has this as well). All they need to do to rectify this issue is put “attr_protected :owner_id, :serialized_key” etc. as necessary. They could also turn it around and use attr_accessible and list only the fields that should be mass assignable (less chance of future problems that way). To say mass assignment is a security hole and should be off in public facing Rails apps is a bit of FUD in my opinion.

    – I couldn’t find the code that you used to show the potential injection attack (so it’s possibly already been patched), the only other place I could find them using $where was in a rake task which will never be publicly accessible so this isn’t an issue. The other finder methods (that I’ve seen) go through mongo_mapper, then Plucky (a mongo_mapper dependency) to construct the query sent to the mongo driver as a hash of options. The mongo driver then constructs the final query, so if there’s any security issues they exist within mongo, the mongo driver, plucky, or mongo_mapper and not diaspora.

    There are some very obvious security issues in the code as it is at the moment, but they’re actually pretty simple to fix, and I don’t think it’s beyond the team to fix them.

  5. Erlend September 22, 2010 at 10:19 pm #

    Thanks for writing this post. Good and detailed. I guess I’d say NoSQL really means no SQL-injection (because there is no SQL), but it opens for NoSQL-injection (because the query languages can be injected), but that’s nitpicking

  6. Ryan September 22, 2010 at 10:21 pm #

    Will, I think you’re missing the point. Yes, many of these things are obvious and easily fixable, which is exactly why it’s so alarming that they’re in the released code in the first place. A lot of this is newbie stuff, discussed in beginner level tutorials. These basic protections should be second nature for experienced developers, and present in the code from the very start.

    Patrick’s conclusion is exactly right, starting with “The team is manifestly out of their depth with regards to web application security.” You can’t trust people making these kinds of mistakes to be able to handle the non-trivial security concerns anytime soon.

  7. Brian Armstrong September 22, 2010 at 11:09 pm #

    It’s a beta….this sort of quick and dirty code is perfectly fine to get something up and running for an early preview (one level above scaffolding) and is easily fixable down the road.

    With a few Ryan Bates screencasts (you’ve probably seen em, he’s got some good ones on security) they could fix 95% of these in a caffeine fueled weekend.

    In fact, from what I’ve seen in the Rails community, this sort of code is common at launch, even amongst venture backed companies. It’s just that we don’t get to see the code of most venture backed startups at launch.

    I think Diaspora is screwed, but not for security reasons. Those sort of things are easily fixable. The problem is their value proposition won’t be enough to take down the entrenched incumbent that is Facebook. Privacy just isn’t enough of a competitive advantage at this point (especially in a business with such strong network effects).

  8. Anti Veeranna September 23, 2010 at 12:07 am #

    No, this sort of quick and dirty code is not fine for a beta or even an alpha. If you do not think about the security from the very start, then your project is doomed.

  9. Carl September 23, 2010 at 1:44 am #

    > There are some very obvious security issues in the code as it is at the moment, but they’re actually pretty simple to fix, and I don’t think it’s beyond the team to fix them.

    Maybe so, but given the schoolboy security errors they introduced in the first place, it’s highly likely that they will continue to introduce further vulnerabilities until they’ve been trained, trained, trained, and then lived and breathed security for quite some time.

    Even experienced developers involved in secure software design make mistakes; that’s why people commission application security assessments. The diaspora team, while well intentioned, have shown themselves to be complete rookies in the security arena. The *will* introduce more bugs.

    If they have the budget, they may want to consider a full-time security person to help provide training, review, and guidance.

  10. Jaco Pretorius September 23, 2010 at 1:47 am #

    Great post, good job

  11. Bob September 23, 2010 at 1:53 am #

    This just made me loose all my faith in diaspora as a better alternative to existing social networks. Wow, talk about catastrophic beginner errors in web development. No matter how pre-pre-alpha this is, if you’re coding like this, it predicts no good for the end result.

  12. me September 23, 2010 at 3:02 am #

    Unfortunately requiring POST instead of GET does not prevent against the Cross Site Request Forgery attack, you need to post a secret token along with the request.

  13. Andreas Schipplock September 23, 2010 at 3:53 am #

    very interesting read.

    What I don’t get is that there are so many rough security “bugs”. When I start with a new project I try to follow the basics steps to make the web-app “secure” and it should be a routine that you are used to and not think about.

    But to be honest I didn’t really expect diaspore to be “good” in the first run :).

  14. Hairy Dave September 23, 2010 at 4:05 am #

    Brian Armstrong said: “It’s a beta….this sort of quick and dirty code is perfectly fine to get something up and running for an early preview (one level above scaffolding) and is easily fixable down the road.”

    When your only selling point against your 800lb gorilla competition is the security of users’ information, showing that your code has no security at all is not a good preview.

  15. Jonas September 23, 2010 at 4:17 am #

    “Wtf wtf wtf” was my reaction to this article. Thank you for taking your time to publish this. These mistakes are way beyond beginner mistakes, they are head-in-the-cloud I-don’t-care problems. Those developers have no business writing software.

  16. Eric Tully September 23, 2010 at 4:34 am #

    To me, the value of Diaspora is the protocol and not their particular implementation. Consider a protocol like HTTP – it’s been written and re-written many many times. If Diaspora becomes popular, wouldn’t we expect people to re-write it in scores of other languages, adding, changing, and improving? While these mistakes are inexcusable, I don’t think they detract from the concept.

  17. Nick Quaranto September 23, 2010 at 4:38 am #

    Maybe you should recommend that every Diaspora dev reads before writing another line of Rails code?

    I would gladly contribute the fixes myself but the license is just horrible and the ridiculous “Contributor Agreement” is just a piss-poor way to run an open source project.

  18. Pedro Teixeira September 23, 2010 at 4:52 am #

    @Eric – The diaspora concept is interesting, but again, anyone can have a good idea, what sets them appart is the implementation.
    With this I think the diaspora guys shot themselves on the foot – several times.
    I wouldn’t trust diaspora with *any* of my data.

  19. Darth Continent September 23, 2010 at 5:24 am #

    Nice article. It’s like Diaspora is saying, “WE won’t leak your privacy details, but if there happen to be people on teh internets exploiting our security vulnerabilities, well…”

  20. Jason L Perry September 23, 2010 at 5:45 am #

    Thank you, Will Cannings for pointing out the things I was thinking while reading this. The author might be well versed in security, but it’s unclear he knows rails as well as he thinks he does.

  21. jeff September 23, 2010 at 6:00 am #

    “(There is a second error here, by the way: the code doesn’t check to see if the destroy action is called by an HTTP POST or not. This means that an overenthusiastic browser might follow all links from a page, including the GET link to a delete action, and nuke the photo without any user action telling it to do so.)”

    You’re wrong on this point – the Rails routing mechanism does this for you. This is, as long as you’re using the RESTful routing, which it appears they are.

  22. Eliot September 23, 2010 at 6:04 am #

    MongoDB $where and db.eval (the 2 ways to use JavaScript) do have a prepared statement style. Instead of just specifying the code to run, you also give it variables to define in the scope before it executes.

  23. Fred Crotchet September 23, 2010 at 7:18 am #

    Well I hope you were 100% sure of those departing comments you made because you just did some serious damage to a project that was already facing astronomical odds of succeeding. And it almost seems like you did it for your own gain.

  24. TheGnome September 23, 2010 at 7:20 am #

    Even Apple makes some of these very basic mistakes. For example, if you know the Apple ID of a company’s iPhone administrator (as defined within the provisioning portal), you can deny them admin access to their own projects, simply if you have your own iPhone development account. They were notified about this two years ago, but have done nothing to fix it. I guess security through obscurity is good enough for Apple.

  25. Caley September 23, 2010 at 7:24 am #

    Good post, however I will ask one question:

    Do you think zuckerberg’s code was rock solid for “The Facebook” when it came out? He can’t keep his mouth closed so I highly doubt his code was any better.

  26. postmodern September 23, 2010 at 7:36 am #

    The quick fix for the NoSQL-injection would be to use Ruby’s Regexp.escape method on the input, before dumping it into the JavaScript string.

  27. Richard Lauren September 23, 2010 at 7:52 am #

    The only thing that they have really achieved is killing the chances of a better project from succeeding now their high-profile attempt is a failure.

    Maybe it is about time they started thinking about returning the money they raised as they have failed to deliver what they promised and it doesn’t look like they ever will.

  28. Martijn September 23, 2010 at 8:03 am #

    I must say that it’s dissapointing that a project that’s supposed to be a trustworthy alternative to FB is so insecure. I agree that being in pre-Alpha status is not an excuse, flaws like these should not be present in any code. It’s not like you’re suddenly going to correct them a few months later.

    Oh well, it’s good that the devs took this beating so early in the project.. they’ll only come out stronger :)

  29. Meditato September 23, 2010 at 8:05 am #

    I don’t really understand what’s with all of you. This 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. The author’s “if this is OSS, we’re screwed” assertion apparently ignores the fact that Chromium, Mozilla, Linux, and dozens of other open source projects work perfectly fine. Additionally, the “their code is unprofessional” accusation is simply wrong-headed. It was never intended to be “professional”, so there’s no way for it to be “unprofessional”. It’s a foundation released to the public that other people can build on.

    As for all this worry about zero-day holes…every piece of software has them. If you think that these kids aren’t professional because they can’t make a perfect, idealized, secure pre-alpha, then you’re riding the slopes of a Nirvana fallacy. The entire reason it was open-sourced was to allow researchers the opportunity to improve the code INSTEAD of going public in order to gain visits to their arrogant blog posts and acting like there’s some huge problem not covered by the disclaimer. OOPS SORRY IS THAT TOO CLOSE TO HOME, PATRICK?

  30. Meditato September 23, 2010 at 8:20 am #

    Also, the fact that a bunch of arrogant naysayers such of yourself recognized these problems (as if the majority weren’t already being commented on in the Diaspora Git’s “issues” section) means that the “OSS + Diaspora” strategy is actually working. Kinda hard thinking on a meta-level, isn’t it?

  31. Ori Pekelman September 23, 2010 at 8:25 am #

    Great post, and a great argument for putting security first.

    I would agree with some of the commentators that fixing these glaring security holes is quite an easy job for a trained professional, and there would be many trained eyes on this specific project. If the maintainers are smart enough to know which commits to pull, this should be ok.

    The problem is that people who, it seems, know little about security are not the people I would give the job of coming up with a secure protocol, a secure system design, or even the job of deciding if the design other people came up with is any good. Doing a distributed system, where the nodes don’t know each other very well, but should be able to interact quite deeply, is a very hard security problem.

    Public key cryptography is not some magic dust you can just spread around; there are at least two very important issues you have to deal with 1. how do public keys get exchanged (for security). 2. What kind of information spillage exposing public keys produce (for privacy).

  32. Bernhard September 23, 2010 at 8:25 am #

    I want to compare this post so somebody who discusses the quality of a Wikipedia article as completely terrible, listing all problems in detail, pissing on the original author, instead of just fixing the problems he found by directly contributing.
    If you are that good, than prove it by helping Diaspora in a non-destructive way. Otherwise it seems you just want to raise your own skills over others, and defend a corporation that lives on abusing peoples social needs.

  33. Vasil Kolev September 23, 2010 at 8:52 am #

    Seems like people don’t understand the severity of the problem. Errors like these mean that the code is beyond help – there was never the idea of security to begin with and fixing it is harder than starting from scratch. It’s actually pointless to keep looking for problems in it.
    (for some reason sendmail comes to mind)

  34. Dog September 23, 2010 at 9:10 am #

    You’ve proven, in one unfortunate sense, exactly why OSS works; you took a day to review the code, post improvements, and draw all the attention to yourself you possibly could. The project is now improved purely because of your desire for self-aggrandizement.

    But your abysmal attitude…

  35. Joe September 23, 2010 at 9:12 am #

    The most popular open source web apps have surprisingly unexpected chaos in their code. I come from the LAMP world – yes develop on Linux, and usually everyone calls PHP a joke, a hack and stuff like that. Well, if you point out odd things, you get bashed by the loyalists, not even replied properly. And I was told Ruby/RoR enabled one to write superb code.
    Well, thanks for showing me that RoR is just like any other tool – good when used properly. This is not to bash Ruby/Rails at all, on the contrary, I realized that good coding is orthogonal with technology. So, it’s each individual project and developer.

    I also figure that those who shout the most, often code the worst. The guys who code well, do just that, and leave the shouting (or not) to others.
    Diaspora has such “brand value” – the shining savior – and this is the level of experience behind the code.

    Hype kills code.

  36. Alex September 23, 2010 at 9:23 am #

    Great publication, but let take a look to the see greater picture:

    Let say community of users might be at least 10000000.
    User in average has 10 contact and suppose there is possible to construct a graph which connects all users. (Well exclude the army users assuming they are separated by firewall and considered as insulated cluster).

    What is the probability that you can infect all system?
    And compare with vulnerability of FB system.

    p.s. Thank Patrick for great publication and his contribution to the project, and let wish good luck to Diaspora (you actually can’t do much for 100K nowadays).

  37. Jeremy September 23, 2010 at 9:23 am #

    I am amazed by the sheer number of people (mostly elsewhere, a few here) missing the point of this article and those like it elsewhere. Since they keep mentioning the pre-release nature of the software, might a rough analogy help? I’m hungry and therefore it is going to involve pancakes. :)

    Imagine for the moment that I am opening a new restaurant. My early marketing revolves almost entirely around it serving “better pancakes than IHOP.” (Serving better pancakes than IHOP isn’t difficult but let’s run with it.) Later on, after the early marketing and before the restaurant opens, I publish a preliminary menu for all to see. It has no pancakes on it.

    No pancakes!

    Preliminary menu or not, the restaurant with “better pancakes than IHOP” serves no pancakes?

    My marketing was either in jest, an outright lie, or at the very least I should not be trusted with your pancake needs for the foreseeable future.

  38. no carrier September 23, 2010 at 10:03 am #

    what did you expect? university programmers usually suck.

  39. Dave Manchester September 23, 2010 at 10:12 am #

    Maybe it’s time to tap some of that venture capital to bring in some seasoned security coding talent?

    Just a thought…


  40. Dutch Uncle September 23, 2010 at 10:13 am #

    It is depressing, after 30+ years in computing since the mainframe days, to see so many comments along the lines of “It’s a demo and they’ll just fix it up.” I thought that the world had already accepted that quality and performance have to be designed in, not glued on. (Security is part of quality, especially in a product specifically advertising security.)

    Nobody would accept a fast-food burger that was raw inside; why would you accept any less of software?

  41. The_Assimilator September 23, 2010 at 10:31 am #

    I looked at the alpha Diaspora code and found the implicit authorization bug within 10 minutes, and then I stopped looking and deleted the code. If the team cannot get such a simple yet vital security concept down from the first line, the project is doomed, period.

    Crude as it may sound, I’ve probably produced bowel movements more secure than the alpha Diaspora code. Code security isn’t difficult, unless you do it wrong or you’re incompetent/oblivious, and I fear the Diaspora developers fall into the latter category.

    Disappointing, very disappointing, and a damning indictment of those who talk the talk but can’t code their way out of a paper bag.

  42. thehalloween September 23, 2010 at 10:33 am #

    Very professional article. I really appreciate the author’s informative tone taking this as an example of exactly what is wrong, why it is wrong, and how to fix it. I didn’t get the feeling that this was any sort of defamation, but rather a real-world example and how to fix it.

  43. The_Assimilator September 23, 2010 at 10:36 am #

    And for anyone who wants to question my credentials – I’m 25, have been coding for a decade, and wrote my first SQL injection-proof PHP app at age 17.

    If one guy with no formal training in PHP development, less than a year’s experience, writing code in his spare time, can bake in security from day one… then the four-man Diaspora team can have no excuse for their failure to do so.

  44. Dave Manchester September 23, 2010 at 10:59 am #

    So, The_Assimilator: Based on the tenor of Your comments, should we look for You to submit one or more patches to Diaspora? ;-) Your excellent security credentials should make it smooth sailing, no?

    Or should we not hold our breath?

    “Men exist for the sake of one another. Teach them then or bear with
    them.” – Marcus Aurelius


  45. Nick D September 23, 2010 at 11:32 am #

    Never ever expose primary keys to the end user. Your database will almost certainly be set up to assign a numeric key to a user, or a photo, or a status update etc. But off the back of that, have a lookup table which links your primary key to something more random. Then expose the more random ‘key’ to the end user. That way, you can pretty much guarantee that the user can’t just change a digit or two and get access to somebody else’s account.


  46. fred September 23, 2010 at 11:40 am #

    your title is terrible
    good read though!
    i hope you help those you can when you can.
    have a goodin’

  47. Yardboy September 23, 2010 at 11:53 am #

    @Nick D
    Security through obscurity is not secure.

  48. Daniele C. September 23, 2010 at 12:05 pm #

    OMFG!!! I couldn’t imagine that Diaspora had such *rubbish* regarding security! This leads me to think that Rails apps are inherently insecure…but, back on topic, it’s really a huge design mistake and nothing else

  49. xyz September 23, 2010 at 12:11 pm #

    “The author’s “if this is OSS, we’re screwed” assertion apparently ignores the fact that Chromium, Mozilla, Linux, and dozens of other open source projects work perfectly fine.”

    All the OSS projects I have been involved in had a core of competent devs that effectively acted as gate keepers policing the code. Some of them do little more than say “that’s a bad idea” when someone does something stupid. These devs are a large part of the reason the projects are of high quality.

    Trying to do things the opposite way around just isn’t going to work. Especially with a project like this. The devs will be adding low quality code faster than people working outside the project can point it out and fix it.
    Users will be continually demanding the software does more encouraging the devs to write new code instead of fixing existing code. There will also be a nice sized pool of low quality patches from users the devs can pull from.
    What you end up with is PHP-Nuke where you host a site and it ends up defaced hours after it first appears in a google search,

  50. Tom C September 23, 2010 at 12:13 pm #

    Nick… Unfortunately, thats just security through obscurity, and someone, somewhere will figure out your pseudo random “key” generation system… or they will brute force it…

    The fix is not to “make something more random” it is to properly authorize actions in the code as the original post stated. This is seriously coding for the web 101, maybe even 099…

    While I agree in principle with not exposing DB primary keys, I don’t know if there is a way to not do it in rails (django, of course being sane doesn’t tie DB models to the URL structure of a site… but thats another flamewar for another day), so its not practical to not do it… anyway, you have to have some unique identifier in the URL a lot of times, and whether that is a number, a random string of characters, or a name, it doesn’t matter, you have to authorize the actions, you can’t leave it up to chance that your “super randomizer machine!” will keep people (or computers) from guessing.

  51. Alex September 23, 2010 at 12:14 pm #

    Read my previouse post – it’s all does not matter much for the community of multiply seeds – if you can break one seed.

    Can you write code which spread into the system, like Windows viruses?


    If you can’t – system is stable secure enough – you can’ do much to the system of 1000000 seeds.

  52. jan g September 23, 2010 at 12:43 pm #

    For those taking the stance that this criticism should be followed by patches (or is otherwise somehow invalidated), I’d advise you to look at Diaspora’s current “contributor agreement.” It shows the same approach to legalese that’s been demonstrated in the codebase: ie, it’s of shoddy pre-alpha quality.

    No bloody way. Fix the contributor agreement, you might see patches.

  53. Allyn September 23, 2010 at 1:34 pm #

    While I think the glaring omissions of this alpha release is concerning indeed, I am quite opposed to the idea that Diaspora is doomed. In fact, one can interpret these security issues as a desire to make as much functionality realized as possible. If that is true, these security omissions are not a glaring insight into the many failures of the Diaspora team, but only an insight into their enthusiasm for their project. Lets be fair here: enthusiasm is really all you need. That and an idea.

    Also, all you old timers may want to consider the concept that in our world, youth is not a handicap. Never the less, I promise to stay off your lawn.

  54. SAsd September 23, 2010 at 2:42 pm #

    Anyone that has any clue of software or web development will immediately realise that the problems mentioned in this article do indeed mean the project is doomed. Its only chance would be to replace every single developer involved in this alpha release with someone who knows what he is doing.

    What Disapora is trying to achieve is incredibly hard to get right, __especially__ security wise, in the first place. But the problems exemplified here are so basic that they just _mustn’t_ happen. The fact that this is pre-release/alpha/whatever is completely meaningless, if the people working on it had the skills necessary to do what they aim for there is no way they would have missed such blatant flaws. Sure, anyone can make mistakes but this is pure incompetency.

    As long as those people are in charge there is no way Diaspora is ever going to be secure no matter how good the contributors. I love OSS but just as you can’t survive on love on itself being OSS alone doesn’t mean you are secure.

  55. Roger September 23, 2010 at 3:12 pm #

    I am amazed that some people in the comments actually a) adamantly defend lousy code b) argue that security cluelessness can be fixed by patches instead of building security into the foundation of what you are doing c) claim that somebody who identifies security risks is somehow in a moral obligation to fix those holes.

    In my experience people like these usually only “get it” when they are audited by 3rd party, forced to follow secure coding standards,by somebody higher up, ridiculed in public or sued. For mutual benefit they should stay away from areas where they can do any harm in the first place.

  56. Roger September 23, 2010 at 3:21 pm #

    One more thought: Compare Haystack. Both projects seem to have a lot in common. There are lessons to be learned for future media darlings.

  57. Keith Perhac September 23, 2010 at 4:23 pm #

    Whenever I see articles like this, I always get nervous:
    “Crap, I bet my code has the same security holes littered all over it. Time to recode 100 sites to make them more secure! *cries silently into coffee cup*”

    But looking at the code samples from Diaspora, I honestly have no idea how these bugs got through testing. Or even through a code sanity-check.

    In the 5 months that they’ve been working on this software, did no one actually realize that they needed to check if the user was the owner of the data they were changing? Did no one realize that this was a Bad Idea(tm)?

    I have to admit, when I wrote my first user-oriented web app (ah, so young and carefree), I made the same mistake. But realized it within 2 weeks of writing the code, and WELL before I actually released. And I’m one person working at nights after his day-job, not 4 guys with over $300,000 in funding.

    This is security101 kind of stuff.

    I’d be much more forgiving if there were multiple XSS vulnerabilities, or something to that degree — those are generally harder to predict than standard method attacks. But to have /users/destroy take raw input from the user with no checks? That’s just negligent.

    It’s on the same level with Lil Bobby Tables.

    (In the old system, if they don’t check if the data was posted instead of getted, I could conceivably create a page with a bunch of images with the src “/users/destroy” and then just have the id be 1-99999999999. The user viewing the page will be logged in, so I get through that barrier. Then unauthenticated account deleting goodness. Mmm-mmm. I do love the smell of napalm in the morning.)

    ** Afterthought
    I notice on Wikipedia that Zuckerberg was one of the people that contributed to the project. While I doubt he had any ulterior motives for the contribution, I find it interesting that with the rampant security flaws in Diaspora, Facebook’s security now looks better in comparison.

    Almost as if Zuckerberg is saying “Security be HARD, suckaz!!”

  58. Anon September 23, 2010 at 5:14 pm #


    not to mention the entire article being biased…

  59. David September 23, 2010 at 6:04 pm #

    Thanks for the writeup. Really helpful to see examples of security holes and how they’re exploited. I wish I’d known half this stuff when I started off developing years ago…

    As for the authorisation, can’t this be handled separately from the controller? I haven’t used rails, so don’t know quite how it’s set up, but with Zend Framework (don’t kill me), authorisation is often implemented as a front controller plugin which gets run prior to dispatching the controller.

    On a side note, it makes me wonder how rampant these kinds of security holes are in closed source web-apps…

  60. Cellar September 23, 2010 at 6:24 pm #

    Bit of a problem here, only mentioned as a few anecdotes, is that security is hard and it just is no issue even with a bunch of people that set out to make it an issue. I shudder to think about all the holes that must, logically, be in facebook and all those other “2.0” apps.

    I sense a bit of an abyss where programming skill is concerned. I’d mention that I wouldn’t trust any language for which the interpreter is leaking memory like an irregular striped leaky bucket and not only is the community perfectly fine with that, but the developers seem to be institutionally incapable of finding the leaks and plugging them, but even without mentioning that the wider programming-for-the-internet community Has A Problem. And, frankly, the “IT security industry” is more about making a good buck or two with “security research” née narcism than about structural improvement of the state of computing.

    I don’t mean to be personally insulting (I’d be s’tabbing people with apo’s’trophes’ for cau’s’e if I was’ to go ad hominem) but it has long been observed that we have our work cut out for us in most any field of computing. I sense a bigger pattern here, and we’re not dealing with it.

  61. jon September 23, 2010 at 10:06 pm #

    Great writeup, Patrick; thanks for taking the time to do it. I totally agree that it’s unlikely they’ll have an alpha release with even minimal security by their target of mid-October. On the other hand I think they did the right thing releasing the code. They got rapid calibration and everybody’s expectations are being set properly. Sounds like the magic of open source to me.

    It’s really striking how negative the tone is in this thread. I certainly see reasons for skepticism, but it’s premature to count them out. They’ve got a good path forward if they can push through to an Octoberish release that gets an insecure version available to to real users, not just developers. Not only will the make it more likely that they’ll get critical mass in the developer community, it will also get a diverse group of users into the feedback loop as early as possible. Then they can get some more funding, step back, and do the security architecture and threat modeling etc. to build the “product-quality”, secure, private version we all really want.

    Also, Diaspora’s not the only game in town. Have any of the other alternatives —, OneSocialWeb, Appleseed, etc. — paid attention to security? If so, this could be a good way to get people to pay attention. If not, see Cellar’s excellent point above about how there’s a bigger problem here.


  62. Will Cannings September 23, 2010 at 11:00 pm #

    @Ryan No I understood the point of the article but I don’t agree with the premise. These are simple mistakes, but they don’t indicate the team is incapable of fixing them, nor does it prove that they will keep making these mistakes. You might have a different approach to development and lock down security at every step as you develop. Clearly these guys don’t, and that’s not a be all and end all situation – it’s perfectly OK for them to release a version which doesn’t have these security issues later. Running the code as is and assuming it will be perfect is stupid, they made it clear this release wasn’t intended for this purpose. If it was a choice between them releasing their code as is so we get to see how they’re going and what we can expect, or them having an incomplete release but one that’s much more secure, I’d prefer the former.

    @Daniele C What from the article makes you think Rails apps are inherently insecure? Rails actually provides a lot of security “for free” without you even thinking about it (use the form helpers and you get CSRF protection automatically).

    And overall: these problems can be fixed in a day or two. The release was a teaser of what we can expect, not something we should all be running. Cut them some slack and stop tearing in to something which isn’t 100% perfect.

  63. Kommentator September 24, 2010 at 2:05 am #

    @Alex: If I can own one Diaspora, they are all owned. Finding them for me is something google does for me. So if one is broken, 1000000 is broken as well.

    This aside: if some team is coding like this, the code is trash. All you can do is learn from it, throw it away and start from scratch. As it has been said hundreds of time: you can’t patch security in as a feature. Security is a design decision which allows no exceptions from it. I’m really surprised by reactions like the above: it’s pre-whatever? BS. We all know what happens to prototypes: they get a shiny package and are than sold the day they are running good enough to serve some purpose.

    Patrick even pointed out how this system could have been distributed if it really only were a poc they are going to throw away after showing it.
    I have to admit though, I wrote code like this as well. It was my first year in university and I had no clue about what-so-ever in security. The project served me to learn some PHP. One thing I learn since than (the hard way ;-)): if it is broken to this point, don’t fix it. Throw it away and start from scratch. It’s cleaner, it’s faster, it’s even easier.

  64. gd September 24, 2010 at 2:13 am #

    this article just shows that the guys behind the project don’t have expertice nor skills developing software. media hyped project to turn out being overrated. i will not use a oss project to share, host and save personal data which is faulty from the very start.

  65. ajn September 24, 2010 at 4:21 am #

    @Will Cannings: you said:

    “These are simple mistakes, but they don’t indicate the team is incapable of fixing them, nor does it prove that they will keep making these mistakes. You might have a different approach to development and lock down security at every step as you develop. Clearly these guys don’t, and that’s not a be all and end all situation – it’s perfectly OK for them to release a version which doesn’t have these security issues later.”


    “And overall: these problems can be fixed in a day or two.”

    THIS attitude/opinion is what I (and I would humbly submit, others who spend a lot of time thinking about security) disagree with in this debate. Let me say up front I was/am rooting for Diaspora to succeed; no love for FB here. But time and time (and time) again I’ve run into code written by junior/inexperienced developers where they just slap together the core functionality with the belief that they can “just add in the security stuff later”. It. Does. Not. Work. Like. That. Yeah, you can put a veneer of security on after the fact but if the original fundamental design phase doesn’t think about the threat model, expected attacks, etc, you are doomed. Doubly-so with a super-high-profile app like this that is guaranteed to attract every jackass script kiddie in the world on day 0 just to make a name for themselves as the first asshole who “hax0red Diaspora”.

  66. steve September 24, 2010 at 5:55 am #

    That’s why people should use Scala + Lift for web applications … :-)

  67. Jeff September 24, 2010 at 6:20 am #

    “NoSQL Doesn’t Mean No SQL Injection”

    Actually it does. Titles have meanings. Calling something “SQL injection” when it is actually “JavaScript injection” is a good way to confuse readers.

    Really, this is English writing 101 stuff. I can’t believe anyone thinks the rest of this article has any value now. This is not something that can be tacked on by a proofreader. The author has made elementary level semantic errors and cannot be trusted. Let’s make a pancake or hamburger analogy…

  68. panzi September 24, 2010 at 6:44 am #

    OMG, these are really greenhorn mistakes. Didn’t they pass a webapp development introduction course on their university? These are exactly the classical errors that you always hear from really cheap-ass proprietary webapps where you usually laugh about the incompetence of the people involved and think this can only happen because of the very cheap attitude of the management and because no developer cares the least bit about their code.

  69. Tobias September 24, 2010 at 7:21 am #

    Consider OSS and contribute… which is what this article does in peculiar ways, though in a rather unsuportive manner.

    I actually believe these facts on security vulnerabilities only make experienced security folks (want to) contribute more, instead of what is suggested in the article and a good lot of the comments.

    Whining about how bad the code and the security situation really is… bores me to death. Get your act together and get involved, otherwise you might just stay happy (seeing people) make a few marketing bucks on facebook, iphones and what nots.

    So, Patrik, have you only got time and nerve to critizise a most welcome project or would you find a few moments to find ways to rather actively contribute… involved rather than detached.

  70. Whoa September 24, 2010 at 10:08 am #

    Only contribute if (and as much as) you want to, Patrick…they’re the folks who took the donations. I say ignore the idiots and walk away smiling knowing your web app won’t get hacked by a 6th grader.

  71. Louis September 24, 2010 at 12:47 pm #

    @ajn: I totally agree with what you are saying.

    And now, some comments on other opinions floated here…

    Someone earlier said that other, successful, software has been released before with zero-day exploits. Sure. The problem here is not that Diaspora has zero-day exploits. It is the nature of Diaspora’s security holes which is the problem. From time to time, people ask me to test their systems. The holes Patrick found are usually the kind of hole I try to find first. They are the first thing that people trying to break the security of the system will try.

    Now, some people are implying or flat out asserting that there was some benefit in releasing the code the way it was, with gaping security holes. Presumably it allowed for an earlier release, saved time, or effort, or what-have-you. Ah, but the difference in effort here is comparable to the difference between making sure doors and windows are closed and locked when going to work in the morning and not doing it. Indeed, several commentators who are defending Diaspora say that it will be quick to fix the holes. Well, if it can be *fixed* quickly and easily, then forcibly it can be done right *in the first place* quickly and easily. So there was no benefit in releasing code with security holes.

    I don’t think this shows a flaw in OSS or that Diaspora is doomed but it is a significant misstep.

  72. ITDEPT September 24, 2010 at 12:58 pm #


    Am I the only one who thinks:
    They would have been releasing any index.html at 15 Sept.
    Guess what… KickStarter DOESN’T PAY if you don’t show some work at day X.
    I know Diaspora since it made it’s first appear on KickStarter, and any developer would agree with me, that the time frame was ridiculous for this kind of project, hell, there’s projects on KS not so tech oriented and ask for more time!
    So… they might be good developers, however, there was a deadline on them, or ELSE… NO MONEY…
    See… this is why I like BSD, they’re motto: We’ll release it when it’s good enough, no dates, no deadlines, nothing…
    This was everything a MONEY thing. If team had a lot of cash and time on their hands, and good will of doing something really great, we would only see Diaspora in about 1year and a half.

  73. brain extender September 24, 2010 at 1:04 pm #

    Very nice in depth analysis. Kept in mind you’d reviewed a “pre-alpha developer preview” you’d contributed in the way open source software works. Transparency by open source code helps to eleminate thoose bugs in early stage of development. Nice work and well written.

    And – as a developer i think they just realized the functionality here to make things work in the alpha. Anyway – a good pointer to not miss your aspects in production release.

    brain extender

  74. scott September 24, 2010 at 1:07 pm #

    No worries, just take the Microsoft approach: make some fixes and rename the project. ^.^

  75. ITDEPT September 24, 2010 at 1:36 pm #

    @scott: GOD DAMN RIGHT :D :D :D sorry the caps

  76. Snaky September 24, 2010 at 3:41 pm #

    Patrick, it would be great if you could take a look at This is a non-commercial social tool and if more security experts would like to help to improve it, this would be of great benefit to many poeple around the planet! THANKS!

  77. Schlipsnerd September 24, 2010 at 9:21 pm #

    As diaspora is an open-source project, i can makes some patches and add them to the project. What if i make a malicious patch, that at the first look fixes a bug, but in the other hand does something bad. who will take a look at my code and decide if it should be commited to the codebase of disapora. the four programmers that shows they dont know how to create a secure webapplications?

    Well im not a programmer, but with this idea in mind, i understand why some here say its doomed. As a user, i cant have trust in diaspora at the current state… and the diaspora team have a hard piece of work ahead… they have to show they can make trustworthy code and build up a trustworthy developer community.

    Thank you, Patrick, for opening my eyes.


  78. Norbert September 25, 2010 at 12:31 am #

    > In fact, from what I’ve seen in the Rails community, this sort of code is common
    > at launch, even amongst venture backed companies. It’s just that we don’t get to
    > see the code of most venture backed startups at launch.

    This concerns me more than the actual state of the codebase. As many others have said here, this is not an issue of a couple security bugs leaking past QA. This is a product that sells security and privacy as their core belief, their raison d’être; and then delivers something completely different. Real security and privacy needs to be built-in, not glued on.

    Many people say Patrick and others who are being critical have hurt the project. I disagree; the developers of Diaspora screwed the pooch. They promised the moon and spent all their R&D money on pretty spacesuits and PR for the astronauts; its too bad that a month before launch date some outside observer reminded them they might actually need a launchpad and rockets. Diaspora may still recover from this massive fumble, but not if the community keeps pampering them. Right now the project needs critical people who are not afraid of admitting their mistakes and can still get stuff done.

    God speed Diaspora. (and thanks Patrick for the lovely write-up)

  79. ormris September 25, 2010 at 7:28 am #

    All the bugs that have been found are horrible oversights. Let’s go and fix them. If you can find’m, you can fix’m. The diaspora guys could obviously use some help, so let’s help them. Github is good for this. OSS is good for this. This is why the diaspora guys released the code in the first place. So guys like Patrick could analyze the code with the perspective of years of experience that they definitely don’t have. There’s been a good deal of complaints, but not a single patch. You all have the power to solve these problems.

  80. flo September 25, 2010 at 9:50 am #

    sorry but I really don’t get what is supposed to be the problem here.
    this is a preliminary alpha version to show off the features they are working on and get in touch with co-developers. They made it very clear that this is no production release and is not intended to be stable nor secure. Opensource collaboration means sharing code early in the conceptual idea stage. Simple readable code is perfectly suited to play around, experiment and change easily and often. It will be rewritten many times anyway and secure code would just be in the way during that process. Performance and security comes later once the feature-set settles. To me it seems like many here are very proud that they understand basic childish beginner security concepts but totally miss the point. The promise of dispora has never been to release a production-ready secure product but to empower us to take the ownership of our data back. We should appreciate these ambitions and help the project succeed. Once we are able to get our data back we should of course secure it! but we are not there yet.

  81. Scott September 25, 2010 at 11:35 am #

    “I took a look out it, mostly out of curiosity, and was struck by numerous severe security errors.” Speaking of errors, I think “out” should be “at.”

  82. Web Technology News September 26, 2010 at 12:36 am #

    So many people commenting with no understanding of web development and business.

    These Diaspora guys were marketing this new system as secure. As this poster has mentioned it’s not secure because of the main fundamental problem, authentication checking. If these Diaspora guys were serious this would be the *first* thing you would focus on, and even without the marketing it would still be one of the first things you put into the code – they seemed to have missed this.

    I’ve never used ROR but I’m looking at their changes for the Auth fixes. Why aren’t they using some sort of ACL that controls every controller/method instead of manually checking the permissions per method? Or is this way more flexible?

    Good article. Every bit of software released has to be ripped apart so action is done. I can’t see Diaspora going far (even with Auth fixes) due to it being decentralised, coded in ruby (requires large infrastructure and not supported as much as PHP) and look at how many features FB has. It’ll take them a long time to catch up if this is what they’ve managed to do so far.

    One great example is Minecraft. Pretty much one guy in one year coded that entire game. Makes me wonder why I’m such a slow web developer!

  83. Ian September 26, 2010 at 2:58 pm #

    > Crypto is not soy sauce for security.
    Lovely quote, mind if I steal it ;)

  84. Michael Finkenthei September 27, 2010 at 12:35 am #

    I guess they had a reason to call it a “pre-alpha developer preview” of their source.
    As long as they learn something out of it, this just might have done the job.

    Anyway, I do appreciate the basic ideas behind the Diaspora approach on social networking. I really hope these folks will get help in buckets. It will be worth it.

  85. Martijn Wismeijer September 28, 2010 at 4:37 am #

    Nice read. Thank you!

  86. Cory Forsyth September 30, 2010 at 8:03 am #

    It’s disappointing to see so much un-constructive criticism of Diaspora. I see a lot of unwarranted negativity towards the project, and it appears that a lot of that disdain comes from jealousy over the heavy (and somewhat undeserved) hype and pre-success that Diaspora has seen. They’d raised, almost in spite of themselves, a ton of money before writing a single line of code, and a lot of people seem to begrudge their early success.

    It’s really a very laudable, admirable project, and one that everyone in the OSS community, along with everyone worried about facebook’s stranglehold on their identity, should be cheering on, not taking potshots at.

    It takes some courage to release something that you know (and they certainly do know) is incomplete. Every successful project I’ve been involved with has started out as something just completely shitty, with tons of bugs and holes, and has iterated its way to something of beauty. When I’m starting a project I have to remind myself that the way to eat an elephant is “one bite at a time,” to avoid despairing when the first effort isn’t the perfect thing I had in my head.

    So, Diaspora has released early, and if they can now just release often, I think they at least give themselves a fighting chance of building something useful. And in turn if the brilliant minds in this community, like yours, would help them instead of sneer at them, they’ll have an even better shot.

    That said, the content (if not the tone) of this article is superb, and it’s great to get more visibility for web application security in general. I have no doubt that this post will result directly in an improved, more secure Diaspora.


  87. Karl Smith September 30, 2010 at 8:07 am #

    Fantastic. Very well written. Most importantly, I leaned a couple of new techniques.

  88. rhj October 3, 2010 at 4:43 pm #

    I have to say, I thought pivotal, a well known rails bunch, were helping and mentoring these guys?

    What happened there? This doesn’t reflect well on them.

  89. OldTimer October 4, 2010 at 1:22 am #

    Unfortunately, this Diaspora thing is unraveling exactly as expected… It reminds me of some darknet projects back in the days.
    What they are trying to achieve is technically difficult even for experts in the field, so clearly it is only their youthful inexperience that makes them think they can pull it off through a “summer coding session”.

  90. Xiong Chiamiov October 5, 2010 at 11:20 am #


    > It takes some courage to release something that you know (and they certainly do know) is incomplete. Every successful project I’ve been involved with has started out as something just completely shitty, with tons of bugs and holes, and has iterated its way to something of beauty. When I’m starting a project I have to remind myself that the way to eat an elephant is “one bite at a time,” to avoid despairing when the first effort isn’t the perfect thing I had in my head.

    The point is that these mistakes should never have existed in *any* iteration. Anyone with a passable knowledge of web security would have covered these basic issues when first writing the code, because, well, that’s the way you do it.

    Secondly, it’s much easier to think about security issues when initially writing code, rather than hacking it in later. I can’t really trust them to end up with a secure application now unless they completely scrap it and restart.

  91. Paul Yokota October 6, 2010 at 2:34 pm #

    So how do today’s announcements from Facebook affect Diaspora? Can they still carve out a place for themselves in the space, especially in light of their stability issues.

  92. Mark October 13, 2010 at 11:25 am #

    The problem is not just of releasing code early. There is no *system* in place for handling row level access. You can patch all your data access methods and updates with additional checks, but you instantly start with legacy cruft. This system needs a complete rewrite with at least 30 seconds of thought given to row level access and permissions.

    Time for a second round of funding for Diaspora 2!

  93. Mark October 13, 2010 at 11:25 am #

    The problem is not just of releasing code early. There is no *system* in place for handling row level access. You can patch all your data access methods and updates with additional checks, but you instantly start with legacy cruft. This system needs a complete rewrite with at least 30 seconds of thought given to row level access and permissions.

    Time for a second round of funding for Diaspora 2!

    Allowed memory size of 33554432 bytes exhausted (tried to allocate 6519 bytes) in /var/www/ on line 1007

  94. Mark October 13, 2010 at 11:25 am #

    The problem is not just of releasing code early. There is no *system* in place for handling row level access. You can patch all your data access methods and updates with additional checks, but you instantly start with legacy cruft. This system needs a complete rewrite with at least 30 seconds of thought given to row level access and permissions.

    Time for a second round of funding for Diaspora 2!

    P.S. why does every thing popular on the Web suck?
    Allowed memory size of 33554432 bytes exhausted (tried to allocate 6519 bytes) in /var/www/ on line 1007

  95. Mr Cheese October 14, 2010 at 10:05 am #

    What an awesome, yet accurate, dismantling of “Dis-saster-pora”.

    If you don’t know that security in web applications is a fundamental concept and should be employed from day one then please pay a visit to Honestly, you need to understand that secure code is not something you can retrofit – you do it from day one and your security-concious of everything you do.

    These mistakes that you have shown are incredible – no level of caveats can excuse them.

    Great blog post.

  96. Maxwell November 9, 2010 at 7:13 pm #

    I have to wonder if many of these doomsayers posting here don’t have any connections to FB or Suckerpunch himself… something smells fishy here.

    It’s an OSS think thank, an intrepid idea… as was FB in the beginning. Look how FB inspired the big boys Google & Yahoo to launch social networks… FB shouldn’t expect that it wouldn’t inspire a response from the OSS world- or that its pioneering leap would be “The Last Big Thing”… pfft.

  97. Maxwell November 9, 2010 at 7:16 pm #

    It may be that Diaspora succeeds- that the uncovering of these vulnerabilities will prompt swift and resolute response to the problem.

    Or it may be that Diasp fails miserably- but the fact that they even tried will inspire SOMEBODY to step up and make this happen. It WILL happen, it’s not like it’s impossible or anything. All they need is the interest of someone like George Soros ro some other philanthropist who wants to make the world a better and safer place. OSS social networks WILL happen, and soon…

  98. Ashish Singh November 25, 2010 at 10:19 am #

    Its funny how you get the highs and lows at the same time. It is only today that I came to know about this project, went through some really inspirational postings and ended up here. Well, you can romanticize with the Idea of Power to the People as much as you want, but at the end performance is what really matters. A project with such an exposure and contributions can’t afford to be just trial n errors. I understand it is supposed to be OSS, so why didn’t the developers involved the community from start up. Having done some programming myself(nothing to this extent or even remotely close — as far as security is concerned), I agree it is far more wise to start from scratch with the help of some seasoned programmers than to amend and patch. Its the Idea that matters. Coding is important but you can buy people to do it for you. So, lets cheer up guys ! No worries. The world will still go on and the Facebook will prevail for the time being. (Ironically I was reading about Mark Zuckerberg when I came to know about this project and still more irony was his investment on it !)

  99. jersey shore season March 27, 2011 at 1:38 am #

    this one is a great story thanks for publishing

  100. Phil April 8, 2011 at 7:31 am #

    LOL, epic fail on behalf of Diaspora.

  101. Boyd Stephen Smith Jr. August 27, 2011 at 9:07 am #

    How does the security of the code look now, almost one year later? Has the power of the bazaar development model given us an application that is secure, or just another way to leak even more information onto the ‘Net and get pwnd?

  102. tham tu tu November 14, 2011 at 11:35 pm #

    Excellent post. I used to be checking continuously this blog and I am impressed! Very useful information specifically the ultimate part :) I handle such info much. I used to be looking for this particular info for a long time. Thank you and good luck.

  103. Baylink November 15, 2011 at 10:08 am #

    *My* problem with Diaspora, which I explained in a fairly long comment on their Kickstarter page, quite early, was that in my estimation, there were quite a number of really useful things *which were theoretically impossible to accomplish without a trusted third-party intermediary*, which Diaspora specifically declines to allow.

    And I hesitate to mention it, but I wonder what we’re going to find out in the wake of the suicide of one of the 4 original developers this week…


  1. Principles of Computer Security, CompTIA Security+ and Beyond, Second Edition - September 22, 2010

    […] Security Lessons Learned From The Diaspora Launch: MicroISV on a … […]

  2. NoSQL Daily – Thu Sep 23 › PHP App Engine - September 23, 2010

    […] Security Lessons Learned From The Diaspora Launch: MicroISV on a Shoestring […]

  3. First source related to Master’s Thesis - Kristo Vaher - Creating Castles in the Air, from Air, by Exertion of the Imagination - September 23, 2010

    […] Security Lessons Learned From The Diaspora Launch Tags: IFI7117 Posted in Master's Studies […]

  4. NexusOne/Arduino PhoneSat Satellite Launch Video | - September 23, 2010

    […] Security Lessons Learned From The Diaspora Launch: MicroISV on a … […]

  5. Zach Inglis - September 23, 2010

    […] are “completely out their depth.” I appreciate their efforts but abusing people’s security is not […]

  6. Liminal states :: Diaspora: what next? (DRAFT) - September 23, 2010

    […] Diaspora account, absolutely nothing,” Patrick McKenzie went into more detail yesterday in Security lessons learned from the Diaspora Launch.  It’s great reading if you’re a programmer or just curious about why most software […]

  7. Interesting Reading #585 – $250,000-a-day Minecraft, $33,000,000,000 Facebook, Bankrupt Blockbuster, Nuclear UFOs and much more… – The Blogs at HowStuffWorks - September 23, 2010

    […] Security Lessons Learned From The Diaspora Launch – “Last week, Diaspora  — the OSS privacy-respecting social network — released a “pre-alpha developer preview” of their source code. I took a look out it, mostly out of curiosity, and was struck by numerous severe security errors. I then spent the next day digging through their code locally and trying to get in touch with the team to address them, privately. In the course of this, I mentioned obliquely that the errors existed on Hacker News, and subsequently was interviewed by The Register and got quoted in a couple of hundred places…” […]

  8. « Bookmarks vom 23.09.2010 – 24.09.2010 - September 24, 2010

    […] Security Lessons Learned From The Diaspora Launch: MicroISV on a ShoestringDiaspora security issuses. […]

  9. Links » The Tragedy of the Uncommons - September 25, 2010

    […] ultra-hyped projects are turning out to be crap. I am, of course, speaking of Haystack and Diaspora (you should follow these links, I am not going to go over the ground they cover, […]

  10. Together we’ll discuss HTML and C++ « Blaufish - September 26, 2010

    […] hörde bara min del av konversationen, som hamnade nere i Ruby och att jag läst en artikel med Ruby kod som jag tyckte såg ut som om någon spytt upp den. (Jag vet att vi skall tycka Ruby […]

  11. Quora - September 28, 2010

    How does the code that Diaspora just released look?…

    The general impression among the community is that the code is very clean and concise, and it’s well laid out like a Rails app would be expected to be. That said, there is nothing in the application that is anything special; the majority of the source…

  12. Openness as a quality | tante's blog - September 29, 2010

    […] have taken it apart even in more detail than I have showing that there are more than just bugs but huge conceptual problems with diaspora but in this text I don’t really want to address those implementation problems at all. […]

  13. Why Tumblr Sucks: Followup | Zach Inglis - October 1, 2010

    […] that takes millions in funding doing such a bad job. This is basically a bigger version of the issues of Diaspora. People doing their job, very badly – just with more […]

  14. Diaspora: lecciones de seguridad « Mbpfernand0's Blog - October 4, 2010

    […] liberaron las primeras muestras que ya han provocado algún comentario. En particular, en Security Lessons Learned From The Diaspora Launch muestran algunas […]

  15. Liminal states :: What can Diaspora learn about security from Microsoft? (REVISED DRAFT) - October 10, 2010

    […] code to the open-source community in September.  From a security perspective, it’s swiss cheese, filled with security 101 errors.  In Diaspora: what next?, I argued This was probably the right […]

  16. dev. » Links: Java, Security & more - October 13, 2010

    […] (and more): Diaspora has a long way to go, but there are lots of things you can learn. Things like what you should never, ever do, that […]

  17. Tales from the Net » What Diaspora* can learn from Microsoft - October 14, 2010

    […] from a security perspective, the code was swiss cheese: filled with holes. This was probably the right tradeoff for them to make at first. If the guys had […]

  18. Episode 82: Various security topics | PHP Podcasts - October 14, 2010

    […] diaspora security review :: Diaspora security review […]

  19. Liminal states :: What Diaspora can learn about security from Microsoft - October 15, 2010

    […] from a security perspective, the code was swiss cheese: filled with holes — just like most web startups. But then again, most web startups aren’t […]

  20. Trevor Turk — Links for 10-21-10 - October 21, 2010

    […] Security Lessons Learned From The Diaspora Launch The team is manifestly out of their depth with regards to web application security, and it is almost certainly impossible for them to gather the required expertise and still hit their timetable for public release in a month. […]

  21. פרוייקט דיאספורה עולה לאויר | Newsgeek - November 26, 2010

    […] ביום רביעי האתר נפתח להרשמה ראשונית – אפשר להכניס את כתובת הדוא"ל, לקבל אישור ולהמתין עד שתתקבל הזמנה לכתובת שהזנתם. המפתחים מאחורי הפרוייקט יודעים לספר כי בכל שבוע הם מחלקים הזמנות נוספות, והסיבה לכך היא כמובן שעליהם לבצע בדיקות עומסים ולטפל בבעיות אבטחה אשר עלולים להעיב על חווית המשתמשים לפני שיוכלו להשיק בצורה רשמית את הפלטפורמה. להזכירכם, הקוד, ששוחרר לראשונה בספטמבר, ספג ביקורת קשה על כך שנתגלו בו לא מעט בעיות אבטחה. […]

  22. Open-source Social Network diaspory idzie na żywo | palace - November 28, 2010

    […] kiedy pierwszej wersji kodeksu pracy w stosunku do obsługi została wysłana, to natychmiast skrytykował za to, że roi się od błędów […]

  23. Which Browser – « Which Browser? - November 29, 2010

    […] a initial Diaspora formula was initial published in September, independent reviewers found some vicious technical defects, including a series of certainty weaknesses. The developers […]

  24. Ruby on Rails – Security issues of diaspora | - May 14, 2011

    […] « Bash find files larger than 1GB … An Introduction to Haml and Sinatra » […]

  25. Diaspora Link & Invite requests - SLUniverse Forums - July 18, 2011

    […] folks might want to proceed with caution as there are some reported security issues with Diaspora. Security Lessons Learned From The Diaspora Launch | Kalzumeus Software […]

  26. buy zovirax online Olympia - January 8, 2012

    […] functional Belstaff Blousons have top and excellent quality Show your figure from Belstaff Fashionable jacket buy belstaff jackets […]

  27. WHAT IS DIASPORA*? Bizarro Facebook? « Loud Liger's Blog - January 16, 2012

    […] what they’re selling, they have some convincing to do. When the code first shipped, many security failures came to light. The source code was actually so ridden with security problems that users […]