Security Lessons Learned From The Diaspora Launch • Hacker News Board

Re: Security Lessons Learned From The Diaspora Launch

#21

Post by donw » Thu, Sep 23, 2010, 4:22 AM UTC

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? =)

Good luck! I've been trying to hire him for months now. ;p

Re: Security Lessons Learned From The Diaspora Launch

#22

Post by grovulent » Thu, Sep 23, 2010, 4:23 AM UTC

tszming wrote: post #15

Would appreciate if more articles like this are posted on HN, useful and practical!

Yeah - I usually come on here to find the technical sorts of articles that I learn from and have been seeing less and less of these lately.

Re: Security Lessons Learned From The Diaspora Launch

#23

Post by bl4k » Thu, Sep 23, 2010, 4:28 AM UTC

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))

They likely didn't learn Rails in college either

Re: Security Lessons Learned From The Diaspora Launch

#24

Post by rubyrescue » Thu, Sep 23, 2010, 4:31 AM UTC

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.

Re: Security Lessons Learned From The Diaspora Launch

#25

Post by gfodor » Thu, Sep 23, 2010, 4:31 AM UTC

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.

Re: Security Lessons Learned From The Diaspora Launch

#26

Post by aberkowitz » Thu, Sep 23, 2010, 4:33 AM UTC

I knew Diaspora had problems when I got an email from the guy who hosts Openspora telling me that [two] other people had the same username.

Re: Security Lessons Learned From The Diaspora Launch

#27

Post by techiferous » Thu, Sep 23, 2010, 4:38 AM UTC

grovulent wrote: post #22

tszming wrote: post #15

Would appreciate if more articles like this are posted on HN, useful and practical!

Yeah - I usually come on here to find the technical sorts of articles that I learn from and have been seeing less and less of these lately.

It's true. And as a result, I'm seeing more and more threads like this one. :)

Re: Security Lessons Learned From The Diaspora Launch

#28

Post by shajith » Thu, Sep 23, 2010, 4:39 AM UTC

Thanks for the web-app security pointers in the post: the RoR security guide[1] and the OWASP Top 10[2]. These should be required reading for anyone making a public web application.

[1] http://guides.rubyonrails.org/security.html (Well-written, like the other guides. Totally worth reading fully).

[2] http://www.owasp.org/index.php/Top_10_2010-Main (Open Web Application Security Project's top application security risks for 2010)

Re: Security Lessons Learned From The Diaspora Launch

#29

Post by jlgbecom » Thu, Sep 23, 2010, 4:44 AM UTC

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've always thought it would make more sense for CS degrees to be for computer scientists (ie, people who want to do more high-level theoretical work), and that software development was more of a trade school, where you learned the languages, and were soon thrown into real-world style projects and apprenticeships.

Imagine if your nurse came out of college having never stepped foot into a hospital, having only read about how to take vitals and such, but never having done it on a live human being.

Re: Security Lessons Learned From The Diaspora Launch

#30

Post by jerf » Thu, Sep 23, 2010, 4:53 AM UTC

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'd go one further and say that if you use string interpolation with anything remotely related to user input at all in a web app, you probably just wrote a security hole of some sort. I use "probably" in the frequentist sense of the term, because the odds of a given user-input string interpolation in an arbitrarily-chosen web app being in at least one of 1. an HTML string 2. a database string 3. a javascript string or 4. something else that is executable by something, without the context-relevant encoding function, are quite high. Same goes for any string concatenation involving anything from the environment or user without the conspicuous presence of an encoding function of some kind, since interpolation is just syntax sugar for concatenation.

"Don't let users interpolate, ever" is close to truth. It isn't quite truth, but it's a lot shorter than the truth.