Security Lessons Learned From The Diaspora Launch
kalzumeus.com
Security Lessons Learned From The Diaspora Launch
1–10 of 142 posts
Re: Security Lessons Learned From The Diaspora Launch
#2I've always wondered about this (not being a code-monkey-ninja-wizard, myself)...
If you open source something, unless it's perfectly written, wouldn't the hacking potential be... near 100%? If everyone can see how you do everything it seems like even a minor slip up will potentially surrender your site.
Could someone explain this (I'm probably missing a piece of the puzzle I can't place)?
Re: Security Lessons Learned From The Diaspora Launch
#3I can probably go all night on this, but a couple things from a quick read of this (very good) post:
First, mass assignment.
The answer to mass-assignment bugs is "attr_accessible". Accessible attributes can be set via update/build/new; nothing else can. Every Rails AR model should have an "attr_accessible" line in it.
I've met smart dev teams working under the misconception that attr_accessible means "these are the attributes that can be changed based on user requests", and so virtually everything is made accessible. No! If something's not attr_accessible, you just set it manually (user.foo = params[:user][:foo]). It's not painful and the extra line expresses something important ("this is a sensitive attribute"). Attributes are inaccessible until they prove themselves mass-assignment-worthy.
Second, the string interpolation in the regex.
Real quick: don't ever let users interpolate arbitrary strings into regular expressions. Regular expression libraries are terribly complicated and not very well tested. To illustrate (but not fully explain) the danger here, run this line of code:
ruby -e "'=XX===============================' =~
/X(.+)+X/"
Oh, one more thing: I appreciate Patrick's take on systems failures breaking Rails apps before underlying crypto flaws will, but even if they had protected their keys, their crypto wouldn't have worked. Don't build things that require crypto. You aren't going to get it right.
Re: Security Lessons Learned From The Diaspora Launch
#4I've always wondered about this (not being a code-monkey-ninja-wizard, myself)... If you open source something, unless it's perfectly written, wouldn't the hacking potential be... near 100%? If everyone can see how you do everything it seems like even a minor slip up will potentially surrender your site. Could someone explain this (I'm probably missing a piece of the puzzle I can't place)?
On about 80% of our projects we'll never see source code. Not having source code is a speed bump for a professional appsec tester. The problem with Diaspora isn't that it's open source; it's that they launched their open source project when it wasn't ready for that.
Re: Security Lessons Learned From The Diaspora Launch
#5Not to be totally nitpicky but if they're using any recent version of Rails (I haven't looked at the source yet), the DESTROY action doesn't respond to GET by default. That doesn't change the fact that they don't scope deletes to the logged-in user's assets.
Re: Security Lessons Learned From The Diaspora Launch
#6I've always wondered about this (not being a code-monkey-ninja-wizard, myself)... If you open source something, unless it's perfectly written, wouldn't the hacking potential be... near 100%? If everyone can see how you do everything it seems like even a minor slip up will potentially surrender your site. Could someone explain this (I'm probably missing a piece of the puzzle I can't place)?
Having source code makes both attacks and defenses easier. It isn't automatic that a bug present in source code will be caught, either by attackers or defenders -- "a million eyes make all bugs shallow" is basically horsepuckey. The bugs in the PNG processing routines, for example, took something like a decade for someone to find and exploit. All Java implementations of OpenID are OSS. All are vulnerable to timing attacks, at least as of a month or so ago. I implemented one of them and passed my implementation past our resident God King of Engineers and he didn't see that fault, either.
Now, if you're a highly anticipated project and you're making errors covered in every Security 101 article which happen to be very visible, then OSSing your code makes it highly likely that people will see those, for good and ill. What scares me for Diaspora's future isn't those errors -- it is the part of the iceberg below the waterline. I mean, if you're steaming at full speed towards a gigantic "I'M GONNA RIP UP YOUR BOAT!" sign, there is probably something underwater and I doubt any qualified security guy (I am so not one) will donate you a few tens of thousands of dollars to tell you how screwed you are right now.
Re: Security Lessons Learned From The Diaspora Launch
#7I've always wondered about this (not being a code-monkey-ninja-wizard, myself)... If you open source something, unless it's perfectly written, wouldn't the hacking potential be... near 100%? If everyone can see how you do everything it seems like even a minor slip up will potentially surrender your site. Could someone explain this (I'm probably missing a piece of the puzzle I can't place)?
The idea is that people can help you eliminate insecure methods--if the code available. "Security through obscurity" leaves you with no assistance and engenders a false sense of security where determined attackers are concerned.
That said, MPWILGSIANSE (my password is LadyGaga so I am no security expert)
Re: Security Lessons Learned From The Diaspora Launch
#8I've always wondered about this (not being a code-monkey-ninja-wizard, myself)... If you open source something, unless it's perfectly written, wouldn't the hacking potential be... near 100%? If everyone can see how you do everything it seems like even a minor slip up will potentially surrender your site. Could someone explain this (I'm probably missing a piece of the puzzle I can't place)?
That's why you don't run pre-alpha code on a production server. The advantage of publishing code this early is that people like the author can point out flaws and help secure the software.
Re: Security Lessons Learned From The Diaspora Launch
#9Not to be totally nitpicky but if they're using any recent version of Rails (I haven't looked at the source yet), the DESTROY action doesn't respond to GET by default. That doesn't change the fact that they don't scope deletes to the logged-in user's assets.
POST vs. GET is a little bit of a red herring anyways, since either method works for CSRF. (I'm adding to your comment, not amending it).
Re: Security Lessons Learned From The Diaspora Launch
#10I can probably go all night on this, but a couple things from a quick read of this (very good) post: First, mass assignment. The answer to mass-assignment bugs is "attr_accessible". Accessible attributes can be set via update/build/new; nothing else can. Every Rails AR model should have an "attr_accessible" line in it. I've met smart dev teams working under the misconception that attr_accessible means "these are the…
Every Rails AR model should have an "attr_accessible" line in it.
I'd do you one better: use an initializer to monkeypatch ActiveRecord::Base and fire "attr_accessible nil", which will cause mass assignment to fail on any object you create from a class which doesn't make the assignment explicit.