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

11–20 of 142 posts

Re: Security Lessons Learned From The Diaspora Launch

#11

Post by jharrison »

tptacek wrote: post #9
jharrison wrote: post #5

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

I'm certainly not qualified to argue with you on anything security related (nor would I want to). I'm simply clarifying Rails default handling of destructive actions which is probably semi-offtopic.

Re: Security Lessons Learned From The Diaspora Launch

#12

Post by tptacek »

patio11 wrote: post #10
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…

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

Re: Security Lessons Learned From The Diaspora Launch

#13

Post by bl4k »

"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 practices there is no way you should allow that to happen. Off by-one bugs, timing attacks etc. are more excusable, but this, this is just amateur hour.

That was 11 years ago.

Re: Security Lessons Learned From The Diaspora Launch

#14

Post by pig »

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

You two, get a (conference) room :-p

Re: Security Lessons Learned From The Diaspora Launch

#16

Post by bl4k »

"NoSQL Doesn’t Mean No SQL Injection"

I lol'd. Mind if I use that?

MongoDB is harder to secure and filter because you have all of Javascript to worry about, rather than just SQL (and where most servers can escape arguments themselves through prepared statements etc.).

SQL databases are also well understood (for eg. in MS-SQL I can stop the remainder of the statement from executing with '--'). MongoDB with its JS engine is still a big unknown.

Re: Security Lessons Learned From The Diaspora Launch

#17

Post by bl4k »

sahillavingia wrote: post #2

I'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)?

With source code available attackers are white-box testing as opposed to black-box testing.

Black-boxing is where you throw known arguments at a system and measure the responses, and hence deducing what the system is doing

White-box testing is knowing what is happening internally, so you can immediately skip to step two of a security test - which is exploiting.

With black-boxing it takes a very very long time to learn the entire system and its workings, but it can be done. Having the code just means skip that test. For eg. with Diaspora from it launching to it being exploited was a matter of minutes.

The Twitter URL escaping bug from this week was from within one of their public source code repositories. While they don't release everything as open source, they have released enough to give an attacker a good view of their stack and how it works. Bugs not detected in the open source code are likely to also appear in other parts of the platform that are closed source (since they weren't detected in the first place)

Re: Security Lessons Learned From The Diaspora Launch

#18

Post by llimllib »

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

Re: Security Lessons Learned From The Diaspora Launch

#20

Post by najirama »

bl4k wrote: post #16

"NoSQL Doesn’t Mean No SQL Injection" I lol'd. Mind if I use that? MongoDB is harder to secure and filter because you have all of Javascript to worry about, rather than just SQL (and where most servers can escape arguments themselves through prepared statements etc.). SQL databases are also well understood (for eg. in MS-SQL I can stop the remainder of the statement from executing with '--'). MongoDB with its JS engi…

Similarly:

"...secret squirrel double-plus alpha unrelease..."

Mind if I use that? It would be a terrific title for an animal fighting game I've been itching to make.

Post reply on HN