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

91–100 of 142 posts

Re: Security Lessons Learned From The Diaspora Launch

#91

Post by andrewf »

zeemonkee wrote: post #58

It's not that the pre-alpha Diaspora has insecurities that bothers me, it's the whole execution. What I really would like to see is a documented protocol - based on XMPP or some other established, well-tested protocol would be good, but if not then at least something. Once you have that protocol - which tells you how Diaspora "seeds" communicate securely - you can let others build their own implementation, using Rail…

Google tried this with Wave.

Nobody stepped up to write a decent client, and the product was judged (unfavorably) on the merits of the reference implementation.

Re: Security Lessons Learned From The Diaspora Launch

#92

Post by mechanical_fish »

pjscott wrote: post #37
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.

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.

Re: Security Lessons Learned From The Diaspora Launch

#93

Post by DannoHung »

llimllib wrote: post #18
bl4k wrote: 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))

I disagree, this should be an obvious security capacity: Don't let people who are not permissioned to modify a given resource modify a given resource.

I might be able to excuse this since they're fundamentally still in alpha (or pre-alpha) and were rushing to get code out.

Re: Security Lessons Learned From The Diaspora Launch

#94

Post by kree10 »

rubyrescue wrote: post #24

I like that the phrase "Lil Bobby Tables" to reference dropping the database via SQL injection has entered the hacker vernacular. What would be a nice one-page security guide would be a 'lil bobby tables' guide to databases - SQL injection for any database - (SQL or NoSQL) - the goal being to help developers prevent these attacks.

It exists: http://bobby-tables.com/

Re: Security Lessons Learned From The Diaspora Launch

#95

Post by jodrellblank »

code_duck wrote: post #81
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.

You've said this twice now, and it still isn't true. Don't be the Youtube commenter who, on a video on how to hold and what to call parts of a musical instrument and how many people got it wrong, said "this video is useless, it's all common sense".

If it were common sense to do it, they would have done it. It's not. It's a very distinct thought pattern shift from "the browser is a part of the execution of our code and it will only try a delete link which the code has generated" to "the user can request anything at any time no matter what links we have or haven't generated or what they can see on screen".

It's a learned shift specific to some subsets of some kinds of computer programmers, not at all "common sense".

(and besides, even if it were common sense, what's the point in your comment then?)

Re: Security Lessons Learned From The Diaspora Launch

#96

Post by patio11 »

chegra wrote: 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. We need to cut scope or push back release." to my superiors.

I don't know if you can get a security expert to fix this for you. You can certainly wave a big enough check around to get somebody to look over your code, but that won't magically improve code you haven't written yet. Also, it is highly likely that Diaspora is architecturally insecure -- that, beyond the "Oops, didn't check the input" code-level whoopsies that your federation strategy as written (and apparently as not documented outside of the sourcecode) just cannot be made to work right.

Re: Security Lessons Learned From The Diaspora Launch

#97

Post by maximilian »

djhworld wrote: post #65
tptacek wrote: post #3

I 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…

I don't have access to a box with ruby on at the moment, what does that line do?

It just hangs ruby (like in an endless loop)

Re: Security Lessons Learned From The Diaspora Launch

#98

Post by ericb »

jlgbecom wrote: post #31

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.

Re: Security Lessons Learned From The Diaspora Launch

#99

Post by carbon8 »

tptacek wrote: post #12
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.

That's clever. Want a job? =)

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

Re: Security Lessons Learned From The Diaspora Launch

#100

Post by chegra »

patio11 wrote: post #96
chegra wrote: 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.…

Thanks for the reply. I agree with the impossible deadline bit. Can you give an example of what you would consider a architecturally insecure web application?
Post reply on HN