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

Comments

No Ruby

[codepunk]

I don't run anything coded with Ruby on any machine, problem solved.

Re:These are design problems, not coding problems

[guitaristx]

Ok, your code examples are beyond wrong-headed. They're just frickin' wrong, and illustrate a very poor grasp of abstraction. What you're essentially saying is that security concerns cannot be abstracted.

They can.

Your DeletePicture(int pictureId) example could be a method of a class (let's call it PictureManager) that depends on an ISecurityContext implementation (or an IPictureDataProvider whose concrete class depends on an ISecurityContext, or any other runtime configuration that happens to be appropriate). The nice bit about that is you can abstract the security portion away, and test your class in isolation. Your example actually is indicative of one of the sources of many bugs: coupling. You're coupling the responsibility of every piece of code to security. What if someone then comes along and says, "We now have a priority to gather analytics on our API. This is just as high a priority and just as critical as security." Your way means modifying the method signatures of every method in the system. That's bad design. Go back to school, kid. You've got a lot to learn.