Live data from Hacker News

Security Lessons Learned From The Diaspora Launch

kalzumeus.com

41–50 of 142 posts

Re: Security Lessons Learned From The Diaspora Launch

#41
post #34
post #33

Earlier quoted context omitted.

I agree with the sentiment, but it's important to note that excellent programming requires some pretty high level theoretical understanding of Computer Science (i.e. Algorithms). There's a slow way to do everything and a fast way to do some things; programmers need to understand the theory behind this. In addition, if you're trying to teach someone how to write secure code, they're going to need at least some underst…

That's why professional programmers should get a B.S. in CS and then an M.S. in software engineering (or a few years of internship experience such as that required for licensed architects). Unfortunately, this is one of those things you can't say because it increases the opportunity cost of a programming career.

Or a professional programmer could just get a job and learn software engineering that way.

Re: Security Lessons Learned From The Diaspora Launch

#42
post #35
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.

I'm keeping this in my back pocket the next time I have a conversation about why I prefer Ruby's monkey patching paradigm to Python's strictness. This is better than all my current examples. :)

The good part about Ruby: you can monkeypatch around framework defaults which do not maximize for your project's circumstances. The bad part about Ruby: your least talented coder can monkeypatch around security features which make his life more difficult ("attr_accessible? Stupid Rails coders, don't they know they have private for that shit? Well, I'll redefine it to just NOP. I am the awesome!")

Re: Security Lessons Learned From The Diaspora Launch

#43

Earlier quoted context omitted.

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

I wouldn't really call CS degrees "high level theoretical work". Plus, I blame the professors.

I see Master's level students all the time who don't even know the basics of programming. That's just not acceptable and gives the university a bad rep.

Re: Security Lessons Learned From The Diaspora Launch

#44
post #42
post #35

Earlier quoted context omitted.

I'm keeping this in my back pocket the next time I have a conversation about why I prefer Ruby's monkey patching paradigm to Python's strictness. This is better than all my current examples. :)

The good part about Ruby: you can monkeypatch around framework defaults which do not maximize for your project's circumstances. The bad part about Ruby: your least talented coder can monkeypatch around security features which make his life more difficult ("attr_accessible? Stupid Rails coders, don't they know they have private for that shit? Well, I'll redefine it to just NOP. I am the awesome!")

I find educating the least talented coder I work with a mostly social problem that I can solve over lunch [1]. But yes, I've definitely felt the pain of monkey patching gone awry. :-p Working around a restriction enforced by your language is no picnic either though and it's not really something you can solve cleanly.

[1] Obviously large companies with massive Ruby code bases can't really do this. Not sure what to say there.

Re: Security Lessons Learned From The Diaspora Launch

#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, understand the basic problems, and are always thinking and reading about how your code might be missing something. These guys seem reasonably smart so I expect after a few months of exposure, they'll be fine.

Re: Security Lessons Learned From The Diaspora Launch

#46
post #10
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.

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

Re: Security Lessons Learned From The Diaspora Launch

#47
post #35
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.

I'm keeping this in my back pocket the next time I have a conversation about why I prefer Ruby's monkey patching paradigm to Python's strictness. This is better than all my current examples. :)

Note that this specific fix doesn't need you to open/monkey-patch ActiveRecord::Base, you can just do ActiveRecord::Base.send(:attr_accessible, nil) in an initializer.

Re: Security Lessons Learned From The Diaspora Launch

#48

Earlier quoted context omitted.

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

We're conflating a lot of different professions here. Phlebotomists only have trade school, but they're still going to be exposed to some pure science - at the least biology but likely chemistry as well - in high school.

Nurses and especially Doctors have years of pure science before they're ever allowed into their trade schools.

Likewise there are a variety of software careers, from sysadmin to developer to architect that require varied levels of education (though much like nurses developers can only benefit from better understanding of the principles behind their art.)

Re: Security Lessons Learned From The Diaspora Launch

#49
The biggest problem I think, and I speak from experience, is that some of the best rails tutorials leave out a lot of important security issues entirely. Some of them might do a trivial paragraph on password encryption, but most of them leave out any mention of these kind of basic security flaws.

Even if the writers didn't explicitly write chapters dedicated to security, obviously even that wouldn't be enough, they should at least note which code is entirely unsafe in production, and where you can learn more about it.

Every rails book is filled with this sort of code that people learn, and then use.

Post reply on HN