Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Security Lessons Learned From The Diaspora Launch

kalzumeus.com

Post reply on HN
Print view View original

81–90 of 142 posts

Re: Security Lessons Learned From The Diaspora Launch

#81

Post by code_duck »

gfodor wrote: post #25

I'll admit, when people came down hard on them vis a vis security, I figured it was just a bit sloppy as a preview release. I was wrong.. these aren't really security "holes" as that's not strong enough a word. I think the best way to put it is they accidentally created the first social network wiki.

Maybe they should take that strength and build on it! Then they can say they were visionaries instead.

I agree though, these aren't like subtle security holes that would need a security expert to review. Checking that a user own the resource on which they are requesting modification is basically common sense.

Re: Security Lessons Learned From The Diaspora Launch

#82

Post by code_duck »

jeremymcanally wrote: post #36

One more bug in the first code snippet is their use of find_by_id means that @album could be nil, causing an error when they attempt to edit it. Most people would use @album.find and then catch the error/show a 404. I realize these guys are in college, but they really should have (a) brought people's expectations in line with their abilities and (b) reached out to experienced developers to help them out. Intridea pro…

Totally, their lives would be so much better now if they had just asked 2-3 experienced Rails developers to review their work before releasing it like this. Actually, the fact that they didn't think to do that kind of illustrates a problem.

Re: Security Lessons Learned From The Diaspora Launch

#83

Post by code_duck »

Tomek_ wrote: post #76

I had my doubts about Diaspora, but now I know for sure: it will be a complete fiasco. Those are horrendous errors that show that those guys have completely no idea about web programming - and I can't see them learning it quickly (certainly not before planned release date of the final version). Sad thing.

Indeed, the level of errors shown in this demonstrates that they would probably need about 2-3 years of experience to be decent at doing work like this. I think the best thing they could have done is hired 3 skilled developers to work for 6 months at $5k a month.

Re: Security Lessons Learned From The Diaspora Launch

#84

Post by code_duck »

equark wrote: post #45

I don't think this is that big of a deal. Pretty much every developer I know has learned about security through this exact process. Either a senior developer or user exposes the flaw and smart, but new, developers quickly realize the didn't understand the attack angles. Without concrete experience it's pretty hard to appreciate how exactly these attacks work. But after a few exploits you start getting paranoid, under…

Why would the community of experienced developers who are supposedly expected to be interested in working on this project, find it rewarding to sit around and wait for them to work through their training wheels? This whole situation really is absurd.

Re: Security Lessons Learned From The Diaspora Launch

#85

Post by epochwolf »

patrickaljord wrote: post #46
patio11 wrote: post #10

Earlier quoted context omitted.

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.

In Shapado we use a safe_update methode like this so we always need to specify which attribute can be updated: @question.safe_update(%w[title body language tags], params[:question])

I like this better than my solution, which was to specific which params were allowed for each controller action and remove any that weren't allowed.

Re: Security Lessons Learned From The Diaspora Launch

#86

Post by ekidd »

code_duck wrote: post #80
mike-cardwell wrote: post #72

Earlier quoted context omitted.

ruby -e "'=XX===============================' =~ /X(.+)+X/" Why does that hang in Ruby? In Perl it's fine...

Well... basically, it sounds like Ruby's regex engine needs some work, hmm?

No, people should know better than to write regexes like /X(.+)+X/, with gratuitous doubly-nested "+" characters. :-) This code performs fine when written as /X(.+)X/, and it matches the same set of strings.

Regexp engines are subtle beasts, and there's a couple different ways to implement them (DFAs vs NFAs, simple engines vs lots of clever special cases, etc.). See O'Reilly's "Mastering Regular Expressions" for an exhaustive discussion.

Re: Security Lessons Learned From The Diaspora Launch

#87

Post by patio11 »

rb2k_ wrote: post #73
jasonkester wrote: post #68

Earlier quoted context omitted.

No, that comment just helps to explain how trivial these things would have been to work around. That's the whole point of the article, that these guys missed all the most obvious things that you need to do to secure your application. There are no deep, tricky issues explained because absolutely zero effort was needed to find a half dozen breathtakingly bad practices floating at the surface. So yes, of course it's tri…

Please read the whole comment I linked to. I was talking about things like the OP saying that browsers could delete things by prefetching (GET requests) or that update_attributes does a double assignment which are simply not true

I don't understand what the comment means by double assignment, but I guarantee that update_attributes will indeed let me overwrite owner_id in the manner specified. Would you like me to demonstrate this with code against a specific git revision? It isn't hard.

Re: Security Lessons Learned From The Diaspora Launch

#88

Post by rb2k_ »

patio11 wrote: post #87
rb2k_ wrote: post #73

Earlier quoted context omitted.

Please read the whole comment I linked to. I was talking about things like the OP saying that browsers could delete things by prefetching (GET requests) or that update_attributes does a double assignment which are simply not true

I don't understand what the comment means by double assignment, but I guarantee that update_attributes will indeed let me overwrite owner_id in the manner specified. Would you like me to demonstrate this with code against a specific git revision? It isn't hard.

No, I'm happy to believe you. It just seems that assumptions like the "the code doesn’t check to see if the destroy action is called by an HTTP POST or not." are incorrect and still in the post. There also isn't a proper answer to that comment so far.

Re: Security Lessons Learned From The Diaspora Launch

#89

Post by wglb »

rb2k_ wrote: post #73
jasonkester wrote: post #68

Earlier quoted context omitted.

No, that comment just helps to explain how trivial these things would have been to work around. That's the whole point of the article, that these guys missed all the most obvious things that you need to do to secure your application. There are no deep, tricky issues explained because absolutely zero effort was needed to find a half dozen breathtakingly bad practices floating at the surface. So yes, of course it's tri…

Please read the whole comment I linked to. I was talking about things like the OP saying that browsers could delete things by prefetching (GET requests) or that update_attributes does a double assignment which are simply not true

Then read a reply to your comment: http://www.kalzumeus.com/2010/09/22/security-lessons-learned...

Re: Security Lessons Learned From The Diaspora Launch

#90

Post by zeemonkee »

code_duck wrote: post #83
Tomek_ wrote: post #76

I had my doubts about Diaspora, but now I know for sure: it will be a complete fiasco. Those are horrendous errors that show that those guys have completely no idea about web programming - and I can't see them learning it quickly (certainly not before planned release date of the final version). Sad thing.

Indeed, the level of errors shown in this demonstrates that they would probably need about 2-3 years of experience to be decent at doing work like this. I think the best thing they could have done is hired 3 skilled developers to work for 6 months at $5k a month.

Which begs the question - where did the money go ?

What they've released looks like your average weekend github side-project. I suspect a large % of Hacker News members have projects like this (though hopefully with better security ;-)). So what did they spend the money on ?

Post reply on HN