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

101–110 of 142 posts

Re: Security Lessons Learned From The Diaspora Launch

#101

Post by danieldon »

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

My first web app had authorization. I didn't even go to school for CS.

Simply put, they focused too much on trendy tools and libraries like MongoDB and CarrierWave and neglected the basics.

Re: Security Lessons Learned From The Diaspora Launch

#102

Post by rb2k_ »

wglb wrote: post #89
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

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

It wasn't my reply, I just thought it was an interesting one.

The original post lists a lot of samples, the reply adds some more information to those, the "reply" moves this into almost to an argumentum ad hominem.

I'm just saying that it would be nice if the OP would at least delete the stuff that is just plain wrong.

Re: Security Lessons Learned From The Diaspora Launch

#103

Post by egmike »

ekidd wrote: post #86
code_duck wrote: post #80

Earlier quoted context omitted.

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…

Interesting. Any other recommendations on how to secure regex's that take in user input in Ruby/Rails?

Re: Security Lessons Learned From The Diaspora Launch

#104

Post by patio11 »

chegra wrote: post #100
patio11 wrote: post #96

Earlier quoted context omitted.

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?

Pretend someone described email over HTTP as a hit new webapp. Email over HTTP is architecturally insecure. Architecturally, there is no way to tell that people are who they say they are. Architecturally, the message is readable by every server between the endpoints. There is no notion of trust baked into email, so you're going to pour gazillions down the drain to retrofit anti-spam mechanics over the insecure architecture.

In terms of micro-architecture, take a look at Wordpress. I love Wordpress, don't get me wrong, but it almost can't be made secured due to some design decisions that can't be reversed, such as "Wordpress templates contain executable code with direct unfiltered access to the database."

Re: Security Lessons Learned From The Diaspora Launch

#105

Post by arethuza »

jasonkester wrote: post #60

Lesson learned: Never let the outside world see your First Big Project Ever. This is what Fred Brooks would have called the First System. Everybody builds this thing at the beginning of their career, and it's always this embarrassing. Mine, in 1996, took this a step further and actually prepared SQL statements in javascript before submitting them to the server to run. Yours probably did something equally bad. It's th…

Yes, but Fred Brooks also warned that the Second System would be even worse!

Re: Security Lessons Learned From The Diaspora Launch

#106

Post by llimllib »

barry-cotter wrote: post #59
sprout wrote: post #48

Earlier quoted context omitted.

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

>Nurses and especially Doctors have years of pure science before they're ever allowed into their trade schools. This is an (unnnecessary) North American tick, whose pernicious influence is spreading. Medicine has traditionally been an undergraduate degree in Europe and all former European colonies aside from the US, and those countries that are in its cultural sphere (like S. Korea, which got rid of its undergraduate…

And demand for doctors is kept artificially high via a small number of available med schools[1], incenting the profession to erect increasingly high barriers to becoming a doctor.

[1]: http://www.nytimes.com/2010/02/15/education/15medschools.htm...

Re: Security Lessons Learned From The Diaspora Launch

#107

Post by avar »

egmike wrote: post #103
ekidd wrote: post #86

Earlier quoted context omitted.

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…

Interesting. Any other recommendations on how to secure regex's that take in user input in Ruby/Rails?

First of all you should think hard before taking regexes from users. Even if you do it correctly you'll still (presumably) need to search over your entire dataset, instead of doing something more lightweight like rely on SQL indexes. Use it with care.

You should use a regex engine that's explicitly designed to take potentially hostile input. Like the Plan9 engine, or Google's re2 engine which powers Google Code Search.

You can also just use Ruby's dangerous PCRE engine if you do something like forking off another process with strict ulimits which executes the regex for you. Then you can just kill it if it starts running away with your resources. Look into how e.g. evaluation bots that work on the popular IRC channels on FreeNode are implemented. POE::Component::IRC::Plugin::Eval on the CPAN is a good example.

Re: Security Lessons Learned From The Diaspora Launch

#108

Post by makmanalp »

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

What a stupid excuse. I'm a "college kid". I don't neglect simple access control in my software.

Re: Security Lessons Learned From The Diaspora Launch

#109

Post by randallsquared »

SamReidHughes wrote: post #40
jlgbecom wrote: post #29

Earlier quoted context omitted.

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…

As an ex-student, I would rather take a CS degree though, even though I was in it for the software development. You end up learning about software development anyway, in the beginning of your career, so it's not a good use of your time to devote yourself to this in college.

You end up learning about software development anyway, in the beginning of your career

...and that's exactly what people are complaining about: the Diaspora devs learning about software development practices in the beginning of their career, while writing code for release.

Re: Security Lessons Learned From The Diaspora Launch

#110

Post by daredevildave »

jodrellblank wrote: post #95
code_duck wrote: post #81

Earlier quoted context omitted.

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

The landlord of the pub I worked in once used to say: "There is no such thing as common sense. It's all experience"
Post reply on HN