[deleted]
Security Lessons Learned From The Diaspora Launch
61–70 of 142 posts
Re: Security Lessons Learned From The Diaspora Launch
#62"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…
I haven't used MongoDB, but I think there is a fundamental difference in the way data is updated. I don't think you have to escape JavaScript in the user input, because you don't update by submitting a single String to execute. The user input is just data.
It depends on the client driver. They have insert, delete, save etc. which send those commands with the user supplied data encoded, but most of the drivers also have an exec or execute which dumps what the user enters straight onto the db.
for eg.
http://www.php.net/manual/en/mongodb.execute.php
"This method allows you to run arbitary JavaScript on the database."
Re: Security Lessons Learned From The Diaspora Launch
#63The 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 s…
Obligitory reference:
http://expatsoftware.com/articles/2007/03/examplecode-produc...
(exampleCode != productionCode)
Re: Security Lessons Learned From The Diaspora Launch
#64There 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…
Good post. It comes down to inexperience, and I am sure we have all been through it ("pfffft.. I could do that in 4 hours" -- younger me).
There were red flags in their kickstarter post:
* "We are four talented young programmers from NYU’s Courant Institute trying to raise money so we can spend the summer building Diaspora"
* "Diaspora knows how to securely share (using GPG) your pictures, videos, and more."
* "We have a plan, a bunch of ideas and the programming chops to build Diaspora. What we need is the time it takes to iron out a powerful, secure, and elegant piece of software. Daniel, Ilya, Raphael, and Maxwell are all ready to trade our internships and summer jobs for three months totally focused on building Diaspora"
* "We promise to you that Diaspora will be aGPL software which will released at the end of the summer."
They also said that no similar system exists (they do)
Re: Security Lessons Learned From The Diaspora Launch
#65I 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?
Re: Security Lessons Learned From The Diaspora Launch
#66Earlier quoted context omitted.
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…
The real problem is with the coders that you don't eat lunch with — the authors of the shitty gems that get pulled in as dependencies.
For your companies' code reopening a class should be a huge flag in code review (something like gerrit should be in place at every large company), but it's not sustainable to police the dependencies of the libraries you use, especially when the default in the Rails community is spray and pray.
Re: Security Lessons Learned From The Diaspora Launch
#67Earlier 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…
In Austria there are Höhere Technische Lehranstalten (HTL, http://en.wikipedia.org/wiki/H%C3%B6here_Technische_Lehranst...) which offer vocational education (but the whole educational system is very different from the US and other countries, which is reflected in the problems faced in the conversion to the Bologna system, i.e. bachelor/master etc.).
Over 5 years, students (usually aged 14 when they enter the school) receive practical training in programming as well as a theoretical foundation, though in no way as thoroughly as in any university program. In the first year of the informatics branch they let students enjoy the beauty of programming linked lists in C, which is quite tough for many.
Re: Security Lessons Learned From The Diaspora Launch
#68After reading the article, also read this comment: http://www.kalzumeus.com/2010/09/22/security-lessons-learned... The comment negates some of the statements made in the post
No, that comment just helps to explain how trivial these things would have been to work around. That's the whole point of the article, that these guys missed all the most obvious things that you need to do to secure your application.
There are no deep, tricky issues explained because absolutely zero effort was needed to find a half dozen breathtakingly bad practices floating at the surface.
So yes, of course it's trivially fixable. The problem is that it wasn't trivially fixed and they thought they were ready to release it.
Re: Security Lessons Learned From The Diaspora Launch
#69Earlier 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…
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.
Depends on the course - the one I did was heavily theory/maths based. We had to do a lot of development but we weren't taught that much about good development practices - those kind of practical issues are pretty much orthogonal to CS and are much better picked up in a practical environment anyway.
Re: Security Lessons Learned From The Diaspora Launch
#70It'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…
It looks like a classic case of poorly managed expectations - the technologists would prefer an approach like the one you outline (and this was what I was expecting), however given their visibility they had to deliver a working application that people could download and install and have it do something.
While meeting both of those objectives in those timescales might be possible it would be a truly remarkable achievement. Not surprisingly it didn't happen and they released something that pleased nobody - all we can hope for is that they learn some lessons and move onto better things.