Slashdot Mirror
Security Lessons Learned From the Diaspora Launch
patio11 writes "Diaspora, the privacy-respecting OSS social network, did a code release last week. Attention immediately focused on security. In fact the code base included several severe security bugs. This post walks through the code, showing what went wrong, and what it would let an attacker do to someone who was using Diaspora." The developer who wrote the post ends with: "You might believe in the powers of OSS to gather experts (or at least folks who have shipped a Rails app, like myself) to Diaspora’s banner and ferret out all the issues. You might also believe in magic code-fixing fairies. Personally, I’d be praying for the fairies because if Diaspora is dependent on the OSS community their users are screwed."
Because of course, obscurity is proper security.
I think the hysterical jeremiads a little over-done.
Give it a couple of months and get back to me. I expect production deployments to be fairly reasonable in terms of security.
Because if Diaspora is dependent on the OSS community their users are screwed.
Isn't that a bit like saying "if getting this building completed is dependent on construction workers, we're screwed"? Why would you make such a disparaging remark about the very people that will be keeping this thing going?
Living With a Nerd
and because yo can see the code these bugs were found
imaigne htis being the windows os
you cant see it it dont exist until....too late
YEA this developer that point sit out PROVES OSS is a better way
Um, and if closed-source project were to receive the same level of public scrutiny, the users would be any less screwed?
All the Diaspora hate coming from this PRE-ALPHA release of their source code seems so strangely out of place.
I mean, nothing seems to point to me that this is shill garbage coming from facebook, but the conceptual idea of Diaspora is sound and the code was released for the precise reason of improving it, as it has done. Yet all I've heard is some disproportionate vitriol against the project. It doesn't make sense.
And hell, the majority of the security issues found appear to be rather simple to fix. Just add authorization checks and use mongoDB stored procedures more frequently.
They did a code-release, flaws were found, now they'll get corrected, that's how FOSS works.
Seems like this reviewer had the uncanny expectance that FOSS-devs are popes in respect to their field, making infallible code (OMG THEY USE LINUX!!!!!one!!eleven!).
Unfortunately, the existance of code-fixing faeries was disproven by Wirth in 1972. Code fixes are actually implemented by type of cobbler elf.
I don't run anything coded with Ruby on any machine, problem solved.
Got Code?
Here is a list of alternative open source Peer-to-peer social networking softwares
Note that The Appleseed Project has existed since 2004 and is the first.
if Diaspora is dependent on the OSS community their users are screwed.
If it wasn't for the OSS community, everybody would believe they've released a safe program. Thanks to OSS, we now know that installing it is not the best decision yet.
I'd say the users would be screwed if diaspora was not open source. Linus Law once again.
I was not surprised to find out that the author sells proprietary software. I think that maybe, just maybe he's biased against FLOSS?
In soviet russia the government regulates the companies.
Cobblers!
Is around to see it, then obviously it must not exist or be exploitable.
"Sorrow is better than laughter, for by sadness of face the heart is made glad." [Ecclesiastes 7:3]
At least with Diaspora they know to call it a bug. At facebook, security holes are known as features, i.e. "places" aka the "please rob me" feature.
I think the point they are trying to make (and perhaps badly) is that anytime you have to rely on volunteers you have the potential to get bit in the ass. Any volunteer organization or group has this problem, it's not just open source. Churches, after school groups, the Elks, etc. When volunteers are the main way you expect to get support, you are at their whim. This week people are busy, so no one shows up, or the kids have a soccer game, or some new more exciting group has their interest so you lose a few people.
I don't think the idea is that the open source community is going to screw people, but that the idea of expecting volunteers to always be plentiful and useful is a good way to cause yourself problems.
I will shred my adversaries. Pull their eyes out just enough to turn them towards their mewing, mutilated faces. Illyria
a message in the subject line and continue it in the body
I mean, nothing seems to point to me that this is shill garbage coming from facebook, but the conceptual idea of Diaspora is sound and the code was released for the precise reason of improving it, as it has done ...
Okay well, sometimes I look at code and I think "good start" and then sometimes I feel like Simon Cowell ... and ask them to start over. So to determine where I stand with the Diaspora code, allow me to quote the article:
This basic pattern was repeated several times in Diaspora’s code base: security-sensitive actions on the server used the params hash to identify pieces of data they were to operate on, without checking that the logged in user was actually authorized to view or operate on that data. 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. Rails makes exploits like this child’s play, since URLs to actions are trivially easy to guess and object IDs “leak” all over the place. Do not assume than an object ID is private.
Okay, I taught myself how to use the rails framework and code Ruby. And one of the things I was amazed at was the Rails magic. Because of how powerful it can be (both good and bad). Yes, it helps you prototype but it's errors like these that make me pause and reconsider if the person coding Ruby on Rails really understands how the framework is attempting to assist them. Obviously if you allow any user to enter any ID of a record in their URL for any CRUD action ... you aren't really understanding what those routes are trying to do for you. And you're a danger to your users.
While I could quickly remedy the above problem for the Diaspora team by improving the authentication and authorization code checks, it might be better to just start over. Now, I've devoted none of my time to the concept of liberating social network users and for that I thank the Diaspora team. This blog posting -- if true -- sure is a vote of no confidence for their capabilities of developing a realistic system. Can they improve? Certainly. But if you're making errors like that, you might be better off letting someone else take a stab at this. It's a harsh thing to say but you don't understand the tool you're using to prototype if you're even starting at this point.
I wish them the best of luck and I hope the community reaches out to them. But I'm not interested in recoding everything. I'd sooner simply start my own project.
My work here is dung.
Someone wrote a blog post to point out some security issues that need fixing in the pre-Alpha version of Diaspora, and here you are using his words for pointless sensationalism that undermines the work of the Diaspora team and propagates the "Diaspora is shite" gossip that will most certainly haunt the project even after the code has hit Beta. Shameful.
If you want to do something useful, then instead of repeating how doomed the project is, ask for people to join them (I think we have some capable individuals around here) and help out.
And no, I'm not affiliated with Diaspora, I'm just annoyed by what this sort of news reporting.
I don't really understand what's wrong with this blog author, this "Patrick" fellow. Diaspora is git-release of a pre-alpha. It's essentially proof-of-concept which was released so we can have a look at it and contribute. The author's "if this is OSS, we're screwed" assertion apparently ignores the fact that Chromium, Mozilla, Linux, and dozens of other open source projects work perfectly fine. Additionally, the "their code is unprofessional" accusation is simply wrong-headed. It was never intended to be "professional", so there's no way for it to be "unprofessional". It's a foundation released to the public that other people can build on.
As for all this worry about zero-day holes...every piece of software has them. If you think that these kids aren't professional because they can't make a perfect, idealized, secure pre-alpha, then you're riding the slopes of a Nirvana fallacy. The entire reason it was open-sourced was to allow researchers the opportunity to improve the code INSTEAD of going public in order to gain visits to their arrogant blog posts and acting like there's some huge problem not covered by the disclaimer. OOPS SORRY IS THAT TOO CLOSE TO HOME, PATRICK? I have never seen more arrogant douchebaggery in a security blog post. This "these are errors that shouldn't be present in any code!" bullshit is a result of Patrick and his circlejerk buds building the project up in their own heads, then being disappointed when the pre-alpha wasn't a facebook-killer.
Yes it has errors. But the very fact that it's 1) open source, and 2) being debugged even by douches such as Patrick, means that the whole "OSS Diaspora" concept ACTUALLY WORKS IN PRACTICE.
http://groups.google.com/group/diaspora-dev/browse_thread/thread/4cd369bdf16a346f
(My comments, starting with: "Here are some general thoughts about how Diaspora might relate to the
Semantic Web and a Social Semantic Desktop, and how that might make it even
more awesome to encourage everyone to migrate to it.")
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
fark you. I know this is just a troll response, but that was some of the most anti-OSS crap I've ever seen you editorialize. Is it because they want a token controversial-subject person, because they think it improves readership? Is that why they let you stay on while constantly bashing the same community this site used to be defined by?
Sheesh. I know that the modern slashdot man is ahisotorical but this is the 2nd time in a week that this PR shite is being shoveled.
it can also serve as a method of squeezing a more complete thought into an unexpanded post.
Then once it's been modded up enough, or otherwise meets your criteria for expanding automatically, it just looks retarded.
I think the reason behind all the bile being tossed at Diaspora is probably because of the hype attached to the project and people not realizing that a pre-alpha release isn't the same thing as a finished product at all. They just see "...Diaspora...released..." and jump to the wrong conclusion, not realizing that it isn't the final version. I'm eager to see where Diaspora goes once it's cleaned up.
I thought that was the OSS mantra.
Seriously though, they're only some inexperienced kids, they released a pre-alpha version of their code, cut them some slack. Not everyone is born with 20 years of programming experience (actually no one is born with 20 years of experience, but from the way some people talk you'd think they were).
My problem with their efforts is they used Ruby. Which might be really nice and all, but not that many people use it. Thus it is really hard to find people who understand it well enough to help them work on the code and or just check the code for bugs.
New things are always on the horizon
As much as I want Diaspora to succeed I do worry about its future viability. In addition to the security issues discussed ad nauseum I have to question some of the technology choices made. It seems like the authors were extremely well-intentioned but made a (tech student) mistake of choosing tech that's popular within tech circles, over ubiquitous, very accessible net staples (such as their choice of MongoDB over something like MySQL).
I don't mean to start a flame war, Ruby and MongoDB have their benefits, but as Diaspora was meant to be distributed very widely I can see the relative unfamiliarity with these as causing some problems. This is perhaps one of those things you learn from experience.
To take an example of successful OSS web app -- Wordpress --- part of the popularity is due to the fact that the system that powers it is supported by nearly host on the planet (regardless of good/poor technical competencies) and countless people have (or believe they have :) ) rudimentary knowledge of how to install, administer and modify it. Admittedly WP is a security nightmare, greater accessibility doesn't help with that problem, but there is no denying that by relying on familiar technology choices has helped make the app successful.
Read the authors blog just a bit, I am not really sure the guy even wrote this article he may have had it commissioned. The author is a crapware distributor and this article is nothing more
than a attempt at driving traffic to his site which worked. Now his claim to fame is some "bingo card printing software for teachers".
A few minutes with a compiler and a few dictionary files will show him exactly what "Open Source" is good for. I could really care less about what he wrote but if I was pissed about it there would be a new open source bingo card printing software package released within the next two hours.
Got Code?
If you read TFA one of the authors of the system replied trying to defend their system. If you don't design the system properly in the first place you might as well re-write because it will take much longer to patch and deal with the ensuing nonsense.
More generally how long does it take people to get tired of re-writing (what looks like lisp code??) the same old low layer nonsense to manage sessions, acls and trivial arrangements of data?
I have a feeling most "web developers" would have better, cheaper, faster results with technologies closer to Oracle Forms or MS ACCESS. But that would require them to do data modeling and think rather than just churning out line after line of broken redundant code.
You know? Something that prevented access to data unless the user owned it? This should have been the lowest level. Like a kernel prevents an application from accessing another's data, they should have a kernel that enforced security before they started the "app" level.
Frankly, I'm sad for the human race that anyone can now make a video, or post a technical news-post, and their project takes off. Anyone sane knew there was no REAL evidence that they were capable coders.
What annoys me though, is that other projects such as OSW did already have working code, and thanks to Diaspora, we now have at least one project which could have truly taken on Facebook soon but lost a lot of valuable attention, and one which will likely suck for a VERY long time (until it gets forked), and in the process of doing so, people will lose faith in other social networking sites.
There was no "launch", this was an alpha code release. Alpha code often has bugs, sometimes major. They even called it a "Developer Release". So I don't understand the uproar about *gasp* bugs in alpha code! If they had branded it beta code then I'd be more concerned with fundamental bugs, but even the developers said it had security bugs when they released it:
http://www.joindiaspora.com/2010/09/15/developer-release.html
Feel free to try to get it running on your machines and use it, but we give no guarantees. We know there are security holes and bugs, and your data is not yet fully exportable. If you do find something, be sure to log it in our bugtracker, and we would love screenshots and browser info.
"You might believe in the powers of OSS to gather experts (or at least folks who have shipped a Rails app, like myself) to Diaspora's banner and ferret out all the issues. You might also believe in magic code-fixing fairies."
Is that not exactly what has happened? In fact, is that not what the author himself is doing? He's ferreting them out like a good little fairy.
Security is part of the design, not the implementation.
Most developers still haven't learned that security isn't something you check for at various access points in the code: it is something you build directly into the business layer. For example, your code should not have a method like this anywhere:
public DeletePicture(int pictureID)
The method should be:
public DeletePicture(SecurityCredentials user, int pictureID)
This way it is impossible for your web to accidentally call DeletePicture() without checking for security. The security check is built-in to the lower-level and there is nothing you can do about it. Having worked on secure web services before, I realize I did not do this in my design, which was great for making simple tools, but it meant that all user-facing code had to have checks for security loopholes. The web is especially weird because users can hack the pages and the HTTP requests to call your methods in ways you never
I read stuff like this and it just seems like security is a hopeless undertaking.
A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.
"Security through hubris," which refers to the hawkers (selling security that ain't) of proprietary software and gawkers (buying security that ain't) with brand-pride. "Security through hubris," doesn't refer to closed source code, and it doesn't refer to not disclosing known flaws. It refers, exclusively, to things that AC may of been referring too, like 'no one will ever go be able to find the security flaws, no one will ever know about or use open-port 6424 for cracking, and/or no one will every know enough about the software to call any unpublished black-back-doors (any access/function available).
DAMN, I think, maybe we know what AC was trying to say ...?
Unaccountable leaders are masters, and unrepresented people are slaves. How do US and EU fare?
The summary contains yet another example of my number one pet peeve as a copy-editor: “do” being used as a generic verb. English is not Perl; some expressions are simply wrong in English. As opposed to “Diaspora, the privacy-respecting OSS social network, did a code release last week,” the correct form of the opening sentence is “Diaspora, the privacy-respecting OSS social network, released code last week.”
I am a much better writer and editor than I am a programmer, which probably means I'm the only person on Slashdot who gives a damn about the error discussed in this post. Nevertheless, it's important that every geek do [generic verb to describe a generic action --Ed.] what he or she can to fight the onset of the “idiocracy.”
Discussion should, at this point, be about the protocols (and perhaps about whether they are secure), not about the code!
Crypto is not soy sauce for security
For the 99% of /. readers that don't RTFA, I thought I'd share this clever quip. Now go RTFA; it is actually a decent read.
I really would like to know if the number of good, in it for the long haul, careerist FOSS developers is increasing or decreasing. I fear more and more 'freeloaders' (like me) are just using open source OS and programs solely for the issues of cost and yes, 'security through obscurity'. In this and most cases it is far better to get as many eyeballs on the code as possible, but are those eyes brightly shining twentysomethings, or a dwindling number of fiftysomethings, screaming rapidly towards retirement and cataracts?
You might believe in the powers of OSS to gather experts (or at least folks who have shipped a Rails app, like myself) to Diaspora’s banner and ferret out all the issues. You might also believe in magic code-fixing fairies. Personally, I’d be praying for the fairies because if Diaspora is dependent on the OSS community their users are screwed.
Says the developer (I mean - he shipped a Rails app!) who has a vested interested in closed source projects.
The English department at my high school had a very strict rule about 'Being' verbs - am, is, are, was, were be, being, been, and do. In our Big end-of-senior year paper, we could only use being-verbs 5 times in, I don't remember exactly, but I think a 7 or 10 page paper - less than once per page. When you went over the count, they started deducting points - IIRC, they deducted like 5% off the total report grade for each extra being verb. That was enough to give you a very strong incentive go back through your drafts looking for being verbs and rewriting sentences and paragraphs to excise them from the text. (Wow, it is so hard to write in the past tense without being verbs; although, for an English paper, you aren't usually talking about history so you can usually avoid the past-tense). I don't think direct quotes from sources in your Bibliography counted against you.
As the parent points out, you can almost always replace a being verb, with an *active* verb - you say what the subject is *doing*, not what the subject is *being*, or is having done to it (obviously there are a few certain cases where you must use being verbs, some in this post - I've re-read before posting, and there's certain sentences I cannot figure out how to re-write). The word 'do' is kind of in-between, but it's better, as the parent shows, to say the group *released* instead of 'did a release', or 'released a new build', or 'released a new version', or 'published a release', or 'released a new snapshot', etc. It makes your language more interesting.
I do think that the strictness of my school's English policies did help me learn to be a better communicator - one of the great complaints about a lot of geeks is that they don't have sufficient communication skills to effectively relay/teach other people about the tech they are working on. I don't claim to be a *great* communicator, but I think I do alright most of the time.
Its like you hire some one to build you a custom car. He shows you his work in progress: Its got the body of a car, the inside is nicely done, the paint job is awesome, and you open the hood to find that the transmission only has one gear. Furthermore, the engine is from a go-cart. The battery: nine volt, hooked up in series with a lemon battery. Yeah, those are issues that can be fixed pretty easily. But do you really want the same guy to do it?
Well.. maybe. Or Maybe not. But Definitely not sort of.
Diaspora needed 2 things to work: bullet proof security and publicity.
They should have started with a public competition for the best architecture. $1000 Grand prize. Proposals should have been voted on and commented on (but the Diaspora team should have reserved the right to pick the winner). This would have given them the best ideas to work with, the strongest criticisms, and publicity. Instead they seem to have tried to build something basically on their own, and so have belly flopped.
"Read the authors blog just a bit, I am not really sure the guy even wrote this article he may have had it commissioned. The author is a crapware distributor and this article is nothing more
than a attempt at driving traffic to his site which worked. Now his claim to fame is some "bingo card printing software for teachers". - by codepunk (167897)
on Thursday September 23, @12:22PM (#33676736)
See subject line above, and answer the question. You see, the thing is, that I see dorks like you all week long online. You're the kind that goes around bitching about others that actually have some sort of 'street cred' in the field of computers, when they themselves (ones like you doing the bitching that is) have nothing whatsoever to their name, like you I am strongly wagering, especially since you go around by a 'pseudonym/handle/nick' online which really gives that much away (and those like you, that bitch about others who have done something decent? Well, they're just like you, and inhabit places like /. all day long online, while they themselves do not even work in computers, or even have a job, nor even possess a degree in the computer related sciences). Your name here? Tack on a "wanna be" in front of it: It would suit you better.
As I said here: http://groups.google.com/group/diaspora-dev/msg/17cf35b6ca8aeb00 ... Ideally (though few manage this), security needs to be woven intrinsically and mutually throughout an entire endeavor at all levels of the social process, and from beginning to end, from recruitment to developer training to coding standards to code reviews (or whatever works) to archiving procedures to product announcements to bug fix procedures to communications with the public, as well as at all levels of the code itself, the tests, and so on. For many situations, security is often like a chain -- any weak link makes it fail. The less a project embodies this end-to-end security ethic, the more constant vigilance or constant exercise of power is required by everyone involved in it (extrinsic security and/or unilateral security). ... :-( ... ..."
"The central issue many people are concerned about (reading comments elsewhere) is that security is not an "add on".
So, in that sense, security is cultural. If you try to bolt on security after the fact (like trying to use a big military to defend long oil supply lines instead of having local power sources like solar panels, or trying to be the one who has all the power and everyone is afraid of rather than being the one who has a lot of friends who all share power and look out for each other) you end up spending a lot of time, money, and lives on "security" and you possibly still end up insecure.
Unfortunately, intentional or not, the first Diaspora release has been taken by some people to be a statement about the culture of Diaspora development as regards end-to-end security, even if it was not an intentional statement or even it it perhaps may not be accurate assessment relative to intent or plans. So, it is going to take a bit of work to recover from that, but no doubt it can be done by showing steady progress to creating a developer culture that has a security mindset woven throughout it.
So how does one get security in practice, assuming you want to do it end-to-end? What engineering attitude may be best to cultivate within that mindset?
Often, the best security is just simplicity.
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
The basic thing is that any software project, FOSS or not, depends on competent software engineers for proper application design, testing, and so forth. Security issues are preventable, but you need engineers, not developers, to do the design and address how authentication/authorization needs to be handled. This is true regardless of development methodology (the role of an engineer is arguably different when doing something like extreme programming but I am not at all convinced that it goes away).
If you don't really understand security, don't try to write secure software all by yourself. FOSS does well when it comes to peer review. Use that. Have experts tell you what you are doing wrong. I know I have learned a lot over the years from such experts and am now much better at that area than I used to be. Think of it like an apprenticeship. For a FOSS project, opening the code early is a good idea. Get review before the problems become pernicious and very difficult to fix. This mistake will probably cost the Diaspora team at least few months in release time, and we can all hope it is fixed properly without meeting the fate of Duke Nukem Forever.
What went wrong is simple: You have a few young (and hence experienced) hotshot (i.e. technically competent) programmers working on a major project without expert feedback using the latest fad technologies (rails, etc). Things get missed. The results are impressive but so are the failures, and by the time the problems are noticed, fixing them is difficult and expensive in terms of time and money.
It's exactly like laying copper pipe, or putting in wiring, except that instead of three times as long, it takes 10x as long or longer to fix after the fact. If you don't know what you are doing, get supervised by someone who does. Again, that's a real strength of FOSS, but it takes an openness that all too many projects lack.
In my experience with insecure FOSS projects, the problem is usually a combination of secrecy and unwillingness to accept input at critical stages. This is true, for example, with SQL-Ledger which keeps development versions secret and where the developer is unwilling to generally accept code contributions or even development feedback from others. Secure projects (like PostgreSQL) generally have more open development processes and yet retain control by a small meritocratic committee.
LedgerSMB: Open source Accounting/ERP
Has anyone considered the fact that FB my have hired some devs to rake over this code the second it was released, find every little thing wrong with it they could, and spam the issues everywhere?
While the fairy business is obviously flamebait, the actual bugs are really quite bad. Going through all that code and fixing it must be a PITA, and those things shouldn't have happened in the first place. I wrote more secure web applications when I was 14! Laughable.
I'm surprised that Diaspora has these kinds of bugs. I've been working on ObjectCloud, an open-source web server with some distributed social networking features, since November of 2008. One of the reasons I didn't court high-profile publicity is that I didn't want to be under the gun to deliver a shoddy product.
A core part of my design is security. Operations have security enforced at a layer lower then what performs the operation. While I won't pretend that it's bug-free, my design attempts to minimize obvious things like users screwing with each others profiles. Likewise, I designed a powerful ORM system in C# that parameterizes user input so that the risk of SQL injection is unlikely and easily fixable.
Furthermore, I didn't release my code until I spent almost a year in private development, and I'm still keeping a low profile until I'm ready for high levels of attention.
This is why I'm shocked that Diaspora has these kinds of bugs. With all of the attention that we're giving to security these days, it's a shame that Diaspora isn't designed from the beginning to be secure.
No, I will not work for your startup
I don't really think that we should really worry about conventional information weapons so much. What we should focus more of our fear and resources on are the infamous IWMD (Information Weapons of Mass Destruction). The development of these by axis of evil nations should be monitored and sanctioned.
Hmm. Diaspora specifically launched early, with an emphasis on the fact that it's a first step, and NOT a complete production ready system. Hell, in their press release they declared that they have security holes. Surprise surprise, they weren't lying. OMG, call the press. Again.
There's a strand of comments against that article offering the viewpoint that the author's criticism should be followed by patches, or is otherwise somehow invalidated.
Look at Diaspora's current "contributor agreement." It shows the same approach to legalese that's been demonstrated in the codebase: ie, it's of shoddy pre-alpha quality.
No bloody way. Fix the contributor agreement, you might see patches.
There *are* magic code-fixing fairies... they're called "consultants" (clouds part and light shines down as heavenly choirs sing) The diaspora team should use the money raised through kickstarter to hire crack "security" consultants.
The License is the first problem.
They need to make it 100% GPLv3 in order to get everyone to help out.
Instead they have a multi-license hydra that spits out a proprietary product at the end.
That's outrages! how can they release a pre-alpha with bugs. Closed source software would never be released in a pre-alpha stage with security bugs in it. Honestly, that is normaly preserved for the release candidate or the final version.
I am wondering. If people release a pre-alpha of something it is not ready for production use, it is ready to look at it. It is only a little bit more than a prototype.
"Absolutely, I have a really kick ass score on WOW, if my mom would just let me play it more I would be the best. by codepunk (167897)
on Thursday September 23, @04:27PM (#33679844)
See subject line above, and grow up kid. Do well at school, get good grades (instead of burning your time online here or playing WOW), and get to a decent college and study up. Maybe then you will be able to put guys like this author down (and that author DOES have some "street cred" in this science, you do not), because then, at least, you'd be somewhat of a peer (especially IF you managed to produce some decent program others use or rated well, and currently/apparently, based on your reply? You have NOT! Keep acting like you do though? You never will!). Also, for someone trying to "come off" like a kid?? Funny your posting history shows you posting things like this (from your post history):
http://slashdot.org/comments.pl?sid=1793386&cid=33642716
"Back in the day when I used to wrench on cars I only used Snap-On tools. I could have bought craftsman tools for half the price so why didn't I? Snap-On tools are expensive as hell but the quality is just a tad bit better than craftsman. Rounding off a single nut in some hard to get at spot with a craftsman wrench could easily cost me 4-5 hrs hell and lost labor. I no longer wrench on cars but I still make my living with tools, enjoy your craftsman while I make a living with a Mac." by codepunk (167897)
on Monday September 20, @06:33PM (#33642716)
Funny, somehow, after I read that from YOU? I do not believe you are just some kid who lives at home with his parents, per your quote above etc. ... so, you can quit lying now, because imo you are. Instead of bitching about others or trying to put them down? Try to learn something and do something good/decent with your life (and grow up!)
I'm going to chime in here with a different view.
I used to recommend SQL-Ledger to customers of mine. I didn't put it through a detailed security review. I didn't realize how bad it was. I had only really been writing web apps for about a year and while I had though a lot about security I didn't trust my own conclusions much yet (I still don't trust myself where I don't have to).
Then I discovered a major security hole in the program, of the sort described here. The program asked for authorization and then inadequately checked for it. It was trivial to forge credentials to bypass controls. Bad..... I went to the developer figuring he'd understand and fix it. Of course little did I know the developer was out of his league or else the problem wouldn't have occurred. The problem didn't get fixed.
After some time of trying unsuccessfully to get the problem fixed (for a year, btw), and getting back at least one totally inadequate fix, I complained to a few trusted development friends and pretty quickly one of them introduced a few others to me and we got LedgerSMB started.
So we initially decided to try to retrofit the SQL-Ledger codebase with security measures. We gave up after a year and three major releases, opting instead for a block-by-block rewrite because the obvious issues were only the tip of the iceburg. Removing SQL injection vulnerabilities alone took 2 months (and we missed only one out of thousands of putative vulnerabilities).
I think this sort of experience here has real value to this discussion. The problems are essentially the same: inadequate checks for authorization, inadequate checks for code injection, and the like. These are often VERY intrusive to fix, and very time consuming to audit for. The code was also poorly structured, and the db design bordered on unusable (a lot of the code relied on ambiguous foreign key relationships).
If these sorts of errors are being made here, then my past experience tells me that this project will never be safe to use. It's a great proof of concept. Now they need to start over, do real security design, and scrap their current release schedule (push things out maybe a year). And they need to ensure they get REAL security experts on their team, i.e. people who review the code and dress down developers who do stupid things. And they need to keep things open from the start of the rewrite so suggestions come in before it's too late to fix them.
However if they don't do this, the project will never amount to anything.
LedgerSMB: Open source Accounting/ERP
I see security as the good-guy equivalent to DRM.
If DRM is a no-win proposition, and fortunately it appears it is, then security is probably a no-win proposition also.
A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.
the simplest error was when i tested it:
go to signup page, click signup without entering anything. you get a stacktrace.
django has the forms framework, and django is only rails for python. i think rails will have something like that. and if not, they should catch the exception with own code. ...
this is clearly the first bad smell. from there it went downhill
User maintains more than a dozen sockpuppet accounts on Slashdot.
twitter! where have you been you big old socktrol!? and more importantly, when are you going back?
The first clue is that they intended to release a secure distributed social networking platform and that the first thing they released publicly was an application, not documentation of the security model and federation protocol.
If you had a good design for the security model and federation protocol, you can implement an application leveraging using any usable tools (and Rails, used correctly, would probably be quite serviceable in this regard.)
But you probably aren't going to just stumble into a secure distributed application if you don't start with a solid foundation, no matter what platform you use.
Most developers still haven't learned that security isn't something you check for at various access points in the code: it is something you build directly into the business layer. For example, your code should not have a method like this anywhere: http://www.bilgiyarismasi.biz/ this site data