Live data from Hacker News

Security Lessons Learned From The Diaspora Launch

kalzumeus.com

121–130 of 142 posts

Re: Security Lessons Learned From The Diaspora Launch

#121
post #98

There are a lot of lessons to be learned from Diaspora, beyond the (brilliant) points made about security. 1. When media hype provides you with $200k, you're still best served by bringing people's expectations down to earth. There was no way they were going to be able to build anything approaching a Facebook killer in 3 months, and it would have been best if they would have made that clear in the beginning. 2. There…

> Open source isn't magic. Isn't it though? I think popular open source projects have magic. These guys put out a demo with lousy unsecured code and rookie mistakes and within a week the worst offenders were identified and repaired. I'm not saying they are great developers, but certainly OSS is some sort of powerful magic.

Open source is good at getting the small bugs, the syntax errors, the security holes with clear and direct fixes, etc.

Open source is not good for making use of the "Many eyeballs" for architectural decisions. It's where the wisdom of crowds provides little benefit. This is why most open source projects are not a haphazard bazaar of stone soup contributors, like most people think, but are actually small dedicated teams of talented software developers, who are usually paid.

I think our conception of what OSS can achieve, simply by being OSS, is somewhat inflated.

(Don't get me wrong, though, OSS is fantastic, and I think it's, by design, much better than close source)

Re: Security Lessons Learned From The Diaspora Launch

#122
post #99
post #12

Earlier quoted context omitted.

That's clever. Want a job? =)

Is that offer good for anyone? http://news.ycombinator.com/item?id=1031126

Of course. Drop me a line. I'd love to talk to you. We love talking to HN people.

Re: Security Lessons Learned From The Diaspora Launch

#123
post #107
post #103

Earlier quoted context omitted.

Interesting. Any other recommendations on how to secure regex's that take in user input in Ruby/Rails?

First of all you should think hard before taking regexes from users. Even if you do it correctly you'll still (presumably) need to search over your entire dataset, instead of doing something more lightweight like rely on SQL indexes. Use it with care. You should use a regex engine that's explicitly designed to take potentially hostile input. Like the Plan9 engine, or Google's re2 engine which powers Google Code Searc…

This assumes that PCRE doesn't still contain memory corruption flaws, despite not being heavily tested, and being in effect a programming language interpreter. Tavis Ormandy found a couple serious problems a few years ago.

I'd just scrub the hell out of strings before passing them to a regex engine.

Re: Security Lessons Learned From The Diaspora Launch

#124

Lesson learned: Never let the outside world see your First Big Project Ever. This is what Fred Brooks would have called the First System. Everybody builds this thing at the beginning of their career, and it's always this embarrassing. Mine, in 1996, took this a step further and actually prepared SQL statements in javascript before submitting them to the server to run. Yours probably did something equally bad. It's th…

Quite the contrary. Provided they have the right attitude, the programmers at Dispora just learned more on their first project than they ever would have if they hadn't shown it to anyone. That's one of the primary benefits of participating in open source software.

Re: Security Lessons Learned From The Diaspora Launch

#125

Lesson learned: Never let the outside world see your First Big Project Ever. This is what Fred Brooks would have called the First System. Everybody builds this thing at the beginning of their career, and it's always this embarrassing. Mine, in 1996, took this a step further and actually prepared SQL statements in javascript before submitting them to the server to run. Yours probably did something equally bad. It's th…

Quite the contrary. Provided they have the right attitude, the programmers at Dispora just learned more on their first project than they ever would have if they hadn't shown it to anyone. That's one of the primary benefits of participating in open source software.

I think the point is that this is the stuff that you always learn in the course of building your First Big Thing. By opening it up to public ridicule rather than to a polite code review by an understanding senior dev, they don't really get any extra learning out of the deal. Just extra humiliation.

Re: Security Lessons Learned From The Diaspora Launch

#126
post #96
post #78

I appreciate the two links with how to handling security issues in web application. As many have pointed out, they do not teach this stuff in University and acquiring such knowledge you tend to have to be very proactive about your development if you do not have industry experience. So thanks a lot for sending these nuggets our way. You stated that the team is manifestly out of their depth in terms of web security, ho…

So one of the painful lessons I picked up in industry is this: an impossible deadline plus a great desire to change is still an impossible deadline. Scheduling is not my bag, and I'm far less well acquainted with Diaspora than you are, but if I was four man months from release at the day job with the state of the project where I think it is I would be sending out emails saying "We will not hit this. It is impossible.…

That's what I feel. Not only do they have an impossible deadline to hit right now, but the deadline they did hit was probably impossible as well.

They may have spent most of the summer architecting this thing and figuring out things like "seeds". When it came down to putting code on screen, as it were, they had minimal time to do so. All of these security issues feel like the release was rushed and that they might have been better off releasing it silently, without a way to deploy public nodes, and having a blog post explaining the situation.

Re: Security Lessons Learned From The Diaspora Launch

#128
post #37

Earlier quoted context omitted.

When you put it that way, suddenly I'm intrigued by the concept.

Obviously real people will object when you manipulate their friend lists and their photo galleries. But there's real possibilities in a wikified social network for fictional characters.

Permissions-based, perhaps? I often feel facebook is a little wiki-ish when I find myself tagged in a new album of photos a friend uploads.

Re: Security Lessons Learned From The Diaspora Launch

#129
Did anyone really believe that a bunch of guys were going to write a secure privacy-based facebook-killer application in three or four months?

That's a challenging proposition even for experienced teams.

Though we all know that they warned us that the software was still full of bugs and treated as experimental.

Patrick says that doesn't matter, that they haven't got the foundation right and anything built on top of it will likely fall.

Maybe they can still iterate and fix those things. Maybe they will scrap large sections of the code and re-write it properly. I suggest they keep trying and learn something from all of this. Us older geeks can be pretty harsh sometimes. We often expect new-comers to not make the same mistakes we did once. That's how we learn though, so don't take it the wrong way.

Next time just don't promise more than you can deliver.

Re: Security Lessons Learned From The Diaspora Launch

#130
post #13

"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." When I was working as a pen tester I would completely scold developers for letting this happen - telling them that with everything we know today about security and good programming p…

> That was 11 years ago. The problem is, these kids are from college . They don't teach you stuff like "writing a secure web application" in college, or even try to. (Not that this is unreasonable, though perhaps I'm suggesting that there should be different career paths for CS majors and people who intend to be professional programmers. (I say as a CS-educated professional programmer))

First of all, this type of thing, preventing users from just changing around URLs, shouldn't need to be taught. It is pretty common sense. When you make something like this, if you don't wonder: "Gee, what would happen if somebody changed photo_id=123&delete=true to photo_id=124&delete=true, would it delete photo 124?" then I'd have to say you aren't a very curious individual. That likely doesn't bode well for your programming prowess.

Validating user input is probably the first thing you learn about web application programming, which is frequently taught at universities, or in books titled "web application programming" which you should at least skim if you're going to start a project like this. Don't blame college for this. Just because it is something that isn't focused on in college (it is, though), and they went to college, does not mean it was college's fault. Would it be fair to blame college for any other mistakes they made, just as long as college did not "focus" on it? No. Some things are common sense.

Most likely, the culprit was time constraints, which is far more excusable.

Post reply on HN