Ruby on Rails vulnerable to mass assignment and SQL injection(zweitag.de)
zweitag.de
Ruby on Rails vulnerable to mass assignment and SQL injection
http://www.zweitag.de/en/blog/ruby-on-rails-vulnerable-to-mass-assignment-and-sql-injection
8 comments
I agree with you; however, there is something to be said for "not subject to drive-by mass tagetings on short notice" that is ignored by this argument. There may be 7 obvious bug in your program, but of you have a couple hundred users, will any of them bother? However, even if you have no users at all, you are going to get hacked by these 0-days due to people just scanning the Internet looking for vulnerable systems. In my case, every single time I've been hacked has been due to a 0-day dropping that I didn't pay enough attention to (like exim4), as opposed to the assuredly infinate number of bugs I have in my own software.
That's true, and there's something to be said for that, though I'm ambivalent about exactly what that something is. That's part of why I tried to make it clear that my point was "Don't knee-jerk on this" rather than "You must stick with Rails or you are a fool." I'm not going to preach security practices at people — there are people much better qualified to do that — I just want people to make sure they understand what tradeoffs they're making with whatever decision they make. A lot of people have drastic misconceptions about these sorts of things. If you're intending to have a little site that largely depends on security through obscurity not to get owned, you should at least know that.
Out of those couple of hundred users you only need one of them to be a bored teenager who has read a bit about web security to bust your application.
It's not like this stuff is that hard in a lot of cases, it's often just "if I put a semicolon in the URL, how does it respond?" or "does this form have a CSRF token?".
It's not like this stuff is that hard in a lot of cases, it's often just "if I put a semicolon in the URL, how does it respond?" or "does this form have a CSRF token?".
I'm a senior developer and I can assure you that stuff like "if I put a semicolon in the URL, how does it respond?" never works on my software. It doesn't because as a general rule I sanitize all input or rely on the stack to do it for me, but in general I know which parts of the stack are doing sanitization to lift that burden from me.
That doesn't mean my software is secure. Unfortunately some bugs are far more subtle, including the recent Rails exploit. So on one hand I trust Rails even more, precisely because such problems are found and fixed. But on the other hand this does open you up to mass exploits, which does give me the shivers.
So it really depends on how much effort you're spending on your app. If you actively maintain your app then you can take notice of zero day exploits and upgrade ASAP. But if you want a worry-less app that you don't want to maintain, a more custom stack is more suitable.
Case in point, Wordpress is the most popular blogging platform in the world. It's also the most targetted and shitty weekend blog implementations are far less likely to get hacked.
That doesn't mean my software is secure. Unfortunately some bugs are far more subtle, including the recent Rails exploit. So on one hand I trust Rails even more, precisely because such problems are found and fixed. But on the other hand this does open you up to mass exploits, which does give me the shivers.
So it really depends on how much effort you're spending on your app. If you actively maintain your app then you can take notice of zero day exploits and upgrade ASAP. But if you want a worry-less app that you don't want to maintain, a more custom stack is more suitable.
Case in point, Wordpress is the most popular blogging platform in the world. It's also the most targetted and shitty weekend blog implementations are far less likely to get hacked.
I know you mentioned Flask, but I haven't seen the same sort of stuff for Django, Pylons or Pyramid. Yes, some if not all of those frameworks use the flawed Pickle method for storing cookies, but so long as the secret is, well a secret, there is no way to get remote code execution on a very simple app built on those frameworks.
Sadly, in the Ruby community shiny and magic are seen as more important than secure, robust or well engineered.
That is the bottom line, and if choosing a new framework or language for your new projects, developers should really consider this.
Yes, it is wonderful creating meta DSLs, scaffold create new blog, and the rest. But when the server gets compromised, it looks a lot less shiny.
This seems like a slightly gussied-up version of "Ruby developers smell bad." It's just a bunch of ad hominem against the Ruby community with no substance to justify it. If you had accused the Ruby community of valuing cool new tricks over solid engineering seven years ago, it might have been a little bit realistic, because the Ruby community was small and starry-eyed back then and there wasn't a whole lot of battle-hardened code.
But nowadays? Rails is actually quite mature and a lot of work has gone into its engineering. It has a security team and they take these things very seriously. You might not feel they're doing well enough, but accusing them (based on no evidence whatsoever) of being obsessed with "shiny" things is not the way to express that concern.
This is not to say that you can't use whatever you want, obviously. Just that you seem to be throwing around dated stereotypes in service of a language pissing match rather than critically analyzing the merits of the framework.
But nowadays? Rails is actually quite mature and a lot of work has gone into its engineering. It has a security team and they take these things very seriously. You might not feel they're doing well enough, but accusing them (based on no evidence whatsoever) of being obsessed with "shiny" things is not the way to express that concern.
This is not to say that you can't use whatever you want, obviously. Just that you seem to be throwing around dated stereotypes in service of a language pissing match rather than critically analyzing the merits of the framework.
How do you guys who are freelancers or perhaps you work for a company and are the only guy working on a particular app handle security stuff like this?
A lot of what I hear is "drop what you are doing and patch this right now!". But of course there are many reasons why this might not be possible. For example you might be on a 15 hour flight with no internet, you might be dealing with some family crisis, you might be in the middle of a coke and sex binge with identical twins who look like Scarlett Johansen or whatever.
Do you live glued to your smartphone in constant fear of 0 days? Do you make sure there is some third party available to deal with this stuff? do you design with the possibility of having your app/site owned as a likely event?
And how do you make your client/employer aware of the implications of stuff like this?
A lot of what I hear is "drop what you are doing and patch this right now!". But of course there are many reasons why this might not be possible. For example you might be on a 15 hour flight with no internet, you might be dealing with some family crisis, you might be in the middle of a coke and sex binge with identical twins who look like Scarlett Johansen or whatever.
Do you live glued to your smartphone in constant fear of 0 days? Do you make sure there is some third party available to deal with this stuff? do you design with the possibility of having your app/site owned as a likely event?
And how do you make your client/employer aware of the implications of stuff like this?
I was living in hospital with my wife having a baby when the last one hit and, yep, I did it all tethered over a phone. First time I've done work in a room while someone was getting set up for a blood transfusion ;-)
If you can drop everything you're doing and patch your system the moment a patch is available, that's great! Do that. For most of us, it'll probably be the next morning or next workday when you would take care of a security patch.
Is this something you put into contracts with clients (assuming you are doing client work)?
I'm curious about how people do security SLAs or whatever.
I'm curious about how people do security SLAs or whatever.
Our main client has one security agreement in place - anything but Ruby on Fails please!
They seem quite happy with Python so far.
Doesn't seem like that solves the fundamental problem though. You could have django issues or whatever just down the pipe.
Or issues lower down the stack.
Let's compare the track record of Django and Rails:
http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-...
http://www.cvedetails.com/product/18211/Djangoproject-Django...
So far zero remote code execution and zero SQL injection vulnerabilities in Django.
http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-...
http://www.cvedetails.com/product/18211/Djangoproject-Django...
So far zero remote code execution and zero SQL injection vulnerabilities in Django.
That's not the point.
Given the axiom, "public facing applications that accept user input and execute code based on that input can sometimes be made to execute code that is not desired" and such a system serves some business function perhaps including storing customer data.
If you are responsible for such a system, how do you manage that risk in a realistic way? Minimising it by choosing a particular technology is only one dimension of security.
Incident response strategies, legal mitigation etc are important here also.
It seems that you either require a person with computer & internet access available at all times to patch at a moments notice or you need to devise a strategy so that having a web server compromised is not an apocalyptic event.
Given the axiom, "public facing applications that accept user input and execute code based on that input can sometimes be made to execute code that is not desired" and such a system serves some business function perhaps including storing customer data.
If you are responsible for such a system, how do you manage that risk in a realistic way? Minimising it by choosing a particular technology is only one dimension of security.
Incident response strategies, legal mitigation etc are important here also.
It seems that you either require a person with computer & internet access available at all times to patch at a moments notice or you need to devise a strategy so that having a web server compromised is not an apocalyptic event.
Still more DOS, Directory traversal and CSRF vulnerabilities.
The philosophy and nature of the features Rails provides are what causes these security vulnerabilities. Auto-magic features are prone to this sort of exploitation.
We actually moved off Ruby/Rails because of all this, but previously it was a test in QA, then patch Prod, both on same day of the word hitting the street that there was yet another hole to close
What are you going to do when whatever you're currently using has a security problem?
Moving off Rails is not a panacea
Moving off Rails is not a panacea
It doesn't have to be a panacea, it just has to significantly reduce the risk of being exploited (whether due to superior design philosophy, superior execution of that design philosophy, or simply 'security by low market share').
If the security of your platform depends on that platform not become a popular target of hacker attention then sometimes it really is as simple as "I don't need to outrun the bear; I just need to outrun you"
If the security of your platform depends on that platform not become a popular target of hacker attention then sometimes it really is as simple as "I don't need to outrun the bear; I just need to outrun you"
This is an odd way to think. What happens if you start on a niche platform and it gets popular, do you switch?
Just because a platform is small doesn't mean somebody isn't going to try and bust it and when they do the small project may not have the resources to push out a robust fix quickly.
Just because a platform is small doesn't mean somebody isn't going to try and bust it and when they do the small project may not have the resources to push out a robust fix quickly.
I'm not parent, but the claim wasn't that popular implies vulnerable. Just that some projects ignore security while the stakes are low, which comes back to bite them in the backside once adopters pick up (e.g. what we're witnessing with Rails now).
...which is often the right choice, because projects that pay attention to security from the get-go often lose out in the marketplace to ones who pay attention to other, more important factors. There's an opportunity cost to everything, and for many apps, security is not as important as convenience, ease-of-use, performance, or features.
Witness Dropbox vs. TarSnap. Dropbox has had multiple serious security vulnerabilities published. TarSnap is by the FreeBSD security officer. Yet Dropbox is the one with the million+ users and $B+ market cap, because grandma cares a lot more about being able to figure out how to use the product than about what happens when the product gets hacked.
Witness Dropbox vs. TarSnap. Dropbox has had multiple serious security vulnerabilities published. TarSnap is by the FreeBSD security officer. Yet Dropbox is the one with the million+ users and $B+ market cap, because grandma cares a lot more about being able to figure out how to use the product than about what happens when the product gets hacked.
There's a lot more to DB v. TS than "Dropbox focused less on security". They're different programs for different audiences. While in some cases they may have market overlap, TS definitely has a niche that would never even consider DB as a possibility. TS's major competitor is custom solutions like rsync.net + duplicity.
Why do you asume that even a teenager who's learnt something about vulnerabilities of web apps, will only try to find a bug typical for i.e. Rails?
It's more likely your app will become a target when it's popular among users.
It's more likely your app will become a target when it's popular among users.
I think the issue is less with bored teenagers and more with turnkey r00tkits. Remember when these Rails issues first blew up and someone posts a very insightful article saying that anyone, anyone running a public Web-facing Rails installation would be exploited?
This is possible because it can be computer-automated.
If you're in a situation where a teenager has to get bored and specifically tinker with your niche software then you may already be a large step ahead.
I mean, right? If we take it as true (as many are claiming here) that all web frameworks have security vulnerabilities and Rails is just being picked on because of its popularity, then you essentially need to make the decision between having 24/7 ability to quickly upgrade all of your running Rails installations, or using something not as popular.
This is possible because it can be computer-automated.
If you're in a situation where a teenager has to get bored and specifically tinker with your niche software then you may already be a large step ahead.
I mean, right? If we take it as true (as many are claiming here) that all web frameworks have security vulnerabilities and Rails is just being picked on because of its popularity, then you essentially need to make the decision between having 24/7 ability to quickly upgrade all of your running Rails installations, or using something not as popular.
As I asked in another thread discussing Rails security, what are the alternatives? What did you move to?
I honestly want to know. I can understand that Rails has this problems, and due to the way it originated (37 Signals apps) I can understand if security wasn't top priority. But now it does scare me a lot. I'm designing a product to be deployed at some large companies and every day I feel less and less secure about using Rails for that. It will be hard to explain to an executive in a top 500 company that I have to patch the damn system every week for a new problem.
I honestly want to know. I can understand that Rails has this problems, and due to the way it originated (37 Signals apps) I can understand if security wasn't top priority. But now it does scare me a lot. I'm designing a product to be deployed at some large companies and every day I feel less and less secure about using Rails for that. It will be hard to explain to an executive in a top 500 company that I have to patch the damn system every week for a new problem.
There are some frameworks that are designed with security as top priority: Lift (used at FourSquare and theguardian.co.uk), Opa, the main Haskell frameworks (Yesod, Happstack, Snap), and Google Web Toolkit come first to mind. And of course the mature J2EE frameworks if you want to go there.
That's no guarantee, and Rails gets a lot of scrutiny so it's difficult to tell to what degree if any it is less secure than other, less scrutinized frameworks, but these are all worth checking out.
http://liftweb.net/
http://opalang.org/
http://www.yesodweb.com/
http://happstack.com/
http://snapframework.com/
https://developers.google.com/web-toolkit/
That's no guarantee, and Rails gets a lot of scrutiny so it's difficult to tell to what degree if any it is less secure than other, less scrutinized frameworks, but these are all worth checking out.
http://liftweb.net/
http://opalang.org/
http://www.yesodweb.com/
http://happstack.com/
http://snapframework.com/
https://developers.google.com/web-toolkit/
It's hard to take Google Web Toolkit seriously when Google themselves don't use it. I mean, it's cool and all, but a Rails-killer, it is not. And after all is said and done, if you had wanted to develop the site in Java, you could have just used J2EE.
As for Haskell-- are you serious? You'll never find another developer who wants to maintain your Haskell code.
I agree that Lift is a good choice, for all the same reasons why Scala is a good choice.
I would also add Revel, for Golang, to that list.
As for Haskell-- are you serious? You'll never find another developer who wants to maintain your Haskell code.
I agree that Lift is a good choice, for all the same reasons why Scala is a good choice.
I would also add Revel, for Golang, to that list.
>it's cool and all, but a Rails-killer, it is not
I don't consider any of these to be Rails-killers, for comparative lack of the combination of lots of web-oriented libraries/plugins and ease of configuration, Rails' biggest draw.
But OP asked for frameworks designed for security, ostensibly to suite the needs of his upcoming project. GWT and the others could be options for that project, depending on requirements. Only OP knows, but worth suggesting.
>And after all is said and done, if you had wanted to develop the site in Java, you could have just used J2EE.
Yup, as I mentioned.
>You'll never find another developer who wants to maintain your Haskell code.
That's an absolute with which I absolutely I beg to differ.
>I would also add Revel, for Golang, to that list.
Looks interesting, but not mature enough yet to include it in this answer. And when they say 'modeled on the Play framework', that's a yellow flag to me, given that Play wasn't designed from scratch for strong security. Originally Play was easily vulnerable to basic attacks like XSS and later patched - eg, not designed around security from scratch. They seemed to want to build a better Rails on the JVM, but they seem to have also adopted the Rails community's preference for 'cool, quick, easy, and magic with security bolted on later', and just added 'fast'. Hopefully the Revel guys do better.
I don't consider any of these to be Rails-killers, for comparative lack of the combination of lots of web-oriented libraries/plugins and ease of configuration, Rails' biggest draw.
But OP asked for frameworks designed for security, ostensibly to suite the needs of his upcoming project. GWT and the others could be options for that project, depending on requirements. Only OP knows, but worth suggesting.
>And after all is said and done, if you had wanted to develop the site in Java, you could have just used J2EE.
Yup, as I mentioned.
>You'll never find another developer who wants to maintain your Haskell code.
That's an absolute with which I absolutely I beg to differ.
>I would also add Revel, for Golang, to that list.
Looks interesting, but not mature enough yet to include it in this answer. And when they say 'modeled on the Play framework', that's a yellow flag to me, given that Play wasn't designed from scratch for strong security. Originally Play was easily vulnerable to basic attacks like XSS and later patched - eg, not designed around security from scratch. They seemed to want to build a better Rails on the JVM, but they seem to have also adopted the Rails community's preference for 'cool, quick, easy, and magic with security bolted on later', and just added 'fast'. Hopefully the Revel guys do better.
Since I'm the op, I'll answer ;)
First, I do want to thank for pointing those frameworks out. I Knew about all the Haskell ones as well as Lift, but OPA I had no idea. Currently looking at it now. Not a fan of JS, but I'm open minded enough to take a loot at.
I quite like Haskell, but I feel the Haskell frameworks aren't there. They may be secure, but the way we have to develop around them makes me cringe (snap for example, and how to get parameters from actions, or yesod with the template haskell everywhere). Also, not sure how battle tested they are. Looking at Haskell wiki, each project has about 10 sites to each framework, and none high profile enough.
I love my unix shell, but I'm really considering .net for this (I think c# is quite a decent language, and f# allows me to have functional programming in there.) Microsoft is trusted by the enterprise (Even if there are issues, managers are more willingly to allow .net patches than framework of the day patches.)
I'll look at lift/scala/play now, see if they allow me an ease to develop that I like, combined with JVM security (whatever that is, but more likely a manager will know about JAva than Ruby/Python)
First, I do want to thank for pointing those frameworks out. I Knew about all the Haskell ones as well as Lift, but OPA I had no idea. Currently looking at it now. Not a fan of JS, but I'm open minded enough to take a loot at.
I quite like Haskell, but I feel the Haskell frameworks aren't there. They may be secure, but the way we have to develop around them makes me cringe (snap for example, and how to get parameters from actions, or yesod with the template haskell everywhere). Also, not sure how battle tested they are. Looking at Haskell wiki, each project has about 10 sites to each framework, and none high profile enough.
I love my unix shell, but I'm really considering .net for this (I think c# is quite a decent language, and f# allows me to have functional programming in there.) Microsoft is trusted by the enterprise (Even if there are issues, managers are more willingly to allow .net patches than framework of the day patches.)
I'll look at lift/scala/play now, see if they allow me an ease to develop that I like, combined with JVM security (whatever that is, but more likely a manager will know about JAva than Ruby/Python)
>but OPA I had no idea. Currently looking at it now. Not a fan of JS, but I'm open minded enough to take a loot at.
Crap, Opa used to be an Ocaml framework that you programmed with an Ocaml-derived DSL and that generated client side JS and a single native binary that contained both the app server, web server, and database. It reminded me of Facebook's single binary blob architecture.
But looks like it's been changed since I last looked at it, now you program it with a JS-derived DSL and it generates client-side JS and server-side Node.js. It can still compile to server-side native code, but not by default, you have to compile it from source to get that:
http://forum.opalang.org/0_235
At a cursory glance it appears the MLState guys are still using their Ocaml-based compiler to generate both the client and server side JS/MongoDB, and I assume still have the same focus on framework security, but not certain.
Personally, the only one of those frameworks I would use for high-security production is Lift, though I'm really looking forward to the Haskell frameworks getting there as well. Lift is the only one that meets my personal requirements for maturity and designed-for-security, but figured I'd list the others just in case.
Lift also does things differently, in a way that I personally appreciate but not all do - namely that html 'pages' are parsed as typed XML DOM objects rather than dumb text files/strings, and Ajax/Comet are DOM transforms rather than string rewriting. Instead of writing controllers, you write 'snippets' in Lift's DSL that bind to a DOM element and transform it, and that can be wired to other snippets, parallel processed, and lazy-loaded. All very cool, like a server-side single page application.
As for .NET, I haven't used or even paid much attention to the MS stack since 2009 so am not qualified to say anything about it, but it's definitely a safe choice. Nobody ever got fired for buying MS, they put billions into securing it, and there are tons of experts on it.
Crap, Opa used to be an Ocaml framework that you programmed with an Ocaml-derived DSL and that generated client side JS and a single native binary that contained both the app server, web server, and database. It reminded me of Facebook's single binary blob architecture.
But looks like it's been changed since I last looked at it, now you program it with a JS-derived DSL and it generates client-side JS and server-side Node.js. It can still compile to server-side native code, but not by default, you have to compile it from source to get that:
http://forum.opalang.org/0_235
At a cursory glance it appears the MLState guys are still using their Ocaml-based compiler to generate both the client and server side JS/MongoDB, and I assume still have the same focus on framework security, but not certain.
Personally, the only one of those frameworks I would use for high-security production is Lift, though I'm really looking forward to the Haskell frameworks getting there as well. Lift is the only one that meets my personal requirements for maturity and designed-for-security, but figured I'd list the others just in case.
Lift also does things differently, in a way that I personally appreciate but not all do - namely that html 'pages' are parsed as typed XML DOM objects rather than dumb text files/strings, and Ajax/Comet are DOM transforms rather than string rewriting. Instead of writing controllers, you write 'snippets' in Lift's DSL that bind to a DOM element and transform it, and that can be wired to other snippets, parallel processed, and lazy-loaded. All very cool, like a server-side single page application.
As for .NET, I haven't used or even paid much attention to the MS stack since 2009 so am not qualified to say anything about it, but it's definitely a safe choice. Nobody ever got fired for buying MS, they put billions into securing it, and there are tons of experts on it.
Revel doesn't run on the JVM. Golang compiles to a static binary that you can just deploy with the cp command. As for security, it seems a little unfair to criticize them for stuff that a different, unrelated framework did.
As for J2EE, it's solid, but Java's security reputation may have been tarnished by the latest web-client exploits.
As for .NET... do you really want to share your profits with Microsoft? I do agree that Microsoft's security has improved lately though.
The other thing about both .NET and J2EE is that they don't strike me as terribly productive languages for programmers. This may ignite a flamewar, but I don't think anything can claim to replace rails unless it also replicates the productivity of rails. You may find that hard to do if you use a pointy-hair-approved solution.
As for J2EE, it's solid, but Java's security reputation may have been tarnished by the latest web-client exploits.
As for .NET... do you really want to share your profits with Microsoft? I do agree that Microsoft's security has improved lately though.
The other thing about both .NET and J2EE is that they don't strike me as terribly productive languages for programmers. This may ignite a flamewar, but I don't think anything can claim to replace rails unless it also replicates the productivity of rails. You may find that hard to do if you use a pointy-hair-approved solution.
>As for security, it seems a little unfair to criticize them for stuff that a different, unrelated framework did.
True, but as a first impression it's not positive, for me at least. I don't have the bandwidth to evaluate more deeply, so unfortunately signaling like this carries more weight than it probably should.
>As for J2EE, it's solid, but Java's security reputation may have been tarnished by the latest web-client exploits.
Not to those of us only interested in server-side Java. The recent vulnerability not only does not affect server-side Java, it also does not even affect client-side standalone Java apps. Just Java applets running in the browser. Those of us paying attention know that and aren't overly concerned by it.
>The other thing about both .NET and J2EE is that they don't strike me as terribly productive languages for programmers. This may ignite a flamewar, but I don't think anything can claim to replace rails unless it also replicates the productivity of rails. You may find that hard to do if you use a pointy-hair-approved solution.
One of the biggest cognitive mistakes people make that leads to misjudgments is not thinking in terms of expected value. For example, Rails may be more productive than J2EE up front, but if you lose significant developer time or worse, money, to breeches and exploits, then its total productivity could end up worse than J2EE.
I'm only saying this hypothetically b/c I don't have any data on that, but I see this sentiment over and over, that Rails is the most productive framework out there. But the question to ask is what is the real expected value of Rails productivity vs other frameworks.
Having said that, I personally hate Java and J2EE, love the JVM, and use Scala whenever possible now for that reason. Lift really hits the sweet spot of productivity, strong security, and maturity.
True, but as a first impression it's not positive, for me at least. I don't have the bandwidth to evaluate more deeply, so unfortunately signaling like this carries more weight than it probably should.
>As for J2EE, it's solid, but Java's security reputation may have been tarnished by the latest web-client exploits.
Not to those of us only interested in server-side Java. The recent vulnerability not only does not affect server-side Java, it also does not even affect client-side standalone Java apps. Just Java applets running in the browser. Those of us paying attention know that and aren't overly concerned by it.
>The other thing about both .NET and J2EE is that they don't strike me as terribly productive languages for programmers. This may ignite a flamewar, but I don't think anything can claim to replace rails unless it also replicates the productivity of rails. You may find that hard to do if you use a pointy-hair-approved solution.
One of the biggest cognitive mistakes people make that leads to misjudgments is not thinking in terms of expected value. For example, Rails may be more productive than J2EE up front, but if you lose significant developer time or worse, money, to breeches and exploits, then its total productivity could end up worse than J2EE.
I'm only saying this hypothetically b/c I don't have any data on that, but I see this sentiment over and over, that Rails is the most productive framework out there. But the question to ask is what is the real expected value of Rails productivity vs other frameworks.
Having said that, I personally hate Java and J2EE, love the JVM, and use Scala whenever possible now for that reason. Lift really hits the sweet spot of productivity, strong security, and maturity.
Haskell is a great choice. While there are fewer Haskell developers in absolute terms, there is a very disproportionate amount of good developers who know Haskell. Startups using Haskell, as well as companies using similar languages like OCaml, have reported that, paradoxically, it's actually easier to hire Haskell programmers because they get more well qualified applicants and fewer unqualified ones.
Moreover, if you're actually working with competent people, they should have no trouble learning Haskell. Chances are, everybody already is, and would be happy at a chance to use it at work.
All the FUD spread around about Haskell is unfortunate. It's a brilliant, practical and extremely productive language, and people are turned away from it for misinformed and poorly considered reasons.
Moreover, if you're actually working with competent people, they should have no trouble learning Haskell. Chances are, everybody already is, and would be happy at a chance to use it at work.
All the FUD spread around about Haskell is unfortunate. It's a brilliant, practical and extremely productive language, and people are turned away from it for misinformed and poorly considered reasons.
>All the FUD spread around about Haskell is unfortunate.
Not necessarily, Haskell's unofficial motto is after all, "Avoid success at all costs". ;)
http://www.codersatwork.com/simon-peyton-jones.html
Not necessarily, Haskell's unofficial motto is after all, "Avoid success at all costs". ;)
http://www.codersatwork.com/simon-peyton-jones.html
I love building stuff with Rails, but these last few weeks are making me glad I'm not maintaining it in production.
I get a little chuckle when I tell people I am building some app and they ask "Why aren't you using RoR and MongoDB?" Maybe I am not comfortable with them in production?
Before you chuckle, you should be sure that you're doing security better than Rails. Read this and see how your framework or custom code stacks up.
http://guides.rubyonrails.org/security.html
Also, ask yourself: "when I have a security vulnerability, how easy is it to fix?" Fixing a Rails vulnerability and deploying the fix to production takes about 2 minutes.
http://guides.rubyonrails.org/security.html
Also, ask yourself: "when I have a security vulnerability, how easy is it to fix?" Fixing a Rails vulnerability and deploying the fix to production takes about 2 minutes.
I am like Dr Hibbert, I chuckle at inappropriate times. But my point was just because something is popular, doesn't mean it is the best for everything. And that you _should_ understand how things work under the hood and not just choose these platforms blindly. I am not specifically hating on RoR, I feel that many developers choose it just because it is easy and popular without understanding what rails gives you and how it works.
This begs the question: Are the Rails devs reading that?
I am of the same opinion. Having trialled both extensively, we stuck with asp.net MVC and SQL server. Expensive but well engineered.
Hope you're not using default model binder, because M$ still allows for you to hang yourself with mass assignment attacks. Something they have yet to learn. Hope you're not running MVC 1 or MVC 2, you're still open to redirection attacks.
It's not called patch Tuesday for nothing.
It's not called patch Tuesday for nothing.
We have our own model binder implementation (with circuit breakers) and UI framework and are using mvc3. And yes we're always fully patched.
Really that's the point I'm trying to make. The default path in MVC isn't exactly secure. There is work to be done. I'd consider this particular rails update in line with a patch Tuesday update. Though I will say, I wish they had a better way of communicating when updates were available.
Wouldn't be so sure of safety - RoR just gets a lot more publicity when a vulnerability surfaces, although the huge amount of magic involved in RoR makes vulnerabilities more common than more static code.
http://forums.asp.net/1233.aspx http://www.troyhunt.com/2012/04/67-of-aspnet-websites-have-s... etc
Besides, most web app vulnerabilities are coding flaws in the user code itself, and very rarely in the framework.
http://forums.asp.net/1233.aspx http://www.troyhunt.com/2012/04/67-of-aspnet-websites-have-s... etc
Besides, most web app vulnerabilities are coding flaws in the user code itself, and very rarely in the framework.
The difference is that things like enabling remote errors or disabling request validation in ASP.NET requires that you explicitly change those settings. The default config doesn't expose either of those issues.
I've got a screen capture with bing showing me remote errors. People do make mistakes.
Of course people make mistakes. The point is that the framework doesn't expose you to those risks by default. You have to explicitly make those mistakes yourself.
Further, when ASP.NET does have the odd vulnerability crop up, patches roll out automatically as critical updates via Windows Update. So, these things get patched quickly even if the app or server is no longer actively maintained, as is the case with so much code out there on every platform. Ironically, it's a bit like Windows Server is the Google Chrome of server environments when it comes to frequency and pervasiveness of updates.
Further, when ASP.NET does have the odd vulnerability crop up, patches roll out automatically as critical updates via Windows Update. So, these things get patched quickly even if the app or server is no longer actively maintained, as is the case with so much code out there on every platform. Ironically, it's a bit like Windows Server is the Google Chrome of server environments when it comes to frequency and pervasiveness of updates.
Bing are Microsoft dogfooding new tech. They will make mistakes.
For those of us who are conservative there are very few opportunities to make mistakes. We have checklists, security policies, code reviews and even protection components in our framework as well as completely segregated web and back end systems.
For those of us who are conservative there are very few opportunities to make mistakes. We have checklists, security policies, code reviews and even protection components in our framework as well as completely segregated web and back end systems.
However framework vulnerabilities offer a consistent attack surface which needs little analysis or tailoring.
The only vulnerability we've seen (ms11-100) was swiftly dealt with and would have been eaten by our up front load balancers anyway.
Regarding our application, our test load is 134,000 test cases and 220,000 lines of assertions. I can sleep well at night.
The only vulnerability we've seen (ms11-100) was swiftly dealt with and would have been eaten by our up front load balancers anyway.
Regarding our application, our test load is 134,000 test cases and 220,000 lines of assertions. I can sleep well at night.
I've got to ask: could you share what app or at least industry that app is in? I've never seen 134,000 test cases before for a web app, and 220,000 assertions to boot. What's the ratio of test cases to code? It sounds like a record to me!
Financial services. Test ratio is 1 test per 6 loc.
Not a record. There are some seriously big apps behind closed doors. Its a different world to the public facing web.
Not a record. There are some seriously big apps behind closed doors. Its a different world to the public facing web.
Facebook is composed of around 10 million lines of code [1] - the public facing web is big.
I've no doubt Google looks at that and thinks it's almost trivially small (Chromium alone is 6.5 million lines [2]).
There's big apps in private, but very few companies are at that scale.
1 - http://www.quora.com/How-large-is-Facebooks-codebase
2 - http://www.ohloh.net/p/chrome
I've no doubt Google looks at that and thinks it's almost trivially small (Chromium alone is 6.5 million lines [2]).
There's big apps in private, but very few companies are at that scale.
1 - http://www.quora.com/How-large-is-Facebooks-codebase
2 - http://www.ohloh.net/p/chrome
I've worked in a number of medium to large financial institutions, and 10M LOC is nothing, really. They had subsystems that were bigger than that by a factor of 2.
yes one of our 3rd party quoting engines' source tops 20mloc of java.
Facebook is a really simple project compared to most of these sort of things.
Facebook is a really simple project compared to most of these sort of things.
I have to wonder how many of those tests are merely performing the kinds of checks that the compiler would automatically perform were a compiled language like, say, C# or Java being used instead of Ruby.
It's written in c#!
Just so that you do realize you have not proven that a bug nor a vulnerability exists - just the behavior of the current system.
Yes this is true but we proactively approach the problem rather than waiting for 3rd parties to find the holes. We are responsible for a couple of patch Tuesdays :)
[deleted]
SQL Server is anything but well engineered. What version of SQL Server are you currently running? Is it on the latest service pack only, or with the latest cumulative update applied? The later fixes critical bugs, but claimed to be "not fully tested" by Microsoft. This retarded release policy means there is no stable version of SQL Server.
I disagree. We're not using the latest patches. We're using an independently verified and tested set of patches. The baseline is 2008.
Now imagine if you'd written 10x as much code in Java and hit a Java vulnerability. The U.S. government told its citizens to uninstall Java recently. There have been a few other high profile Java vulnerabilities in the past few years. Does that mean Java is the wrong choice? Most jobs available in development are in Java (check indeed.com).
For years Microsoft was the butt of most security jokes. .Net dev jobs are #2 under Java in indeed.com.
Find me a well-used platform that hasn't had a massive security hole or a community that hasn't tended to write insecure code at some point.
For years Microsoft was the butt of most security jokes. .Net dev jobs are #2 under Java in indeed.com.
Find me a well-used platform that hasn't had a massive security hole or a community that hasn't tended to write insecure code at some point.
"Java" is a bunch of different things that run in a bunch of different places. It's a language, a bytecode interpreter, and a virtual machine. The virtual machine may run on a server, or client side. Most of the more significant Java security issues of late have been on the client-side JVM plugin support for browsers, which affects the ability to run Java applets client-side.
For most contemporary Web development, "Java development" translates as "server-side Java programmer". Which isn't without its warts (trust me on this), but it's not the place that has seen a lot of heat, despite Oracle's best efforts to fuck everything up.
The recent situation with RoR has been vastly worse, and has been server-side.
As for that well-used platform and community with few security holes, I'd suggest you look up the OpenBSD folk, if you count an OS as a platform. They take a preemptively secure approach on all system code, to the point of rewriting major libraries. Yes, it's a bit less free-form than all the cool kids like to play these days, but damned if it's not a solid platform. And that "secure by default" mentality means they avoid much of the pain other OS developers (including Linux, which I much prefer to admin myself) encounter.
RoR and Ruby have, to my mind and experience, a cultural problem with regards to security. And they're becoming widely enough used that it's starting to show.
For most contemporary Web development, "Java development" translates as "server-side Java programmer". Which isn't without its warts (trust me on this), but it's not the place that has seen a lot of heat, despite Oracle's best efforts to fuck everything up.
The recent situation with RoR has been vastly worse, and has been server-side.
As for that well-used platform and community with few security holes, I'd suggest you look up the OpenBSD folk, if you count an OS as a platform. They take a preemptively secure approach on all system code, to the point of rewriting major libraries. Yes, it's a bit less free-form than all the cool kids like to play these days, but damned if it's not a solid platform. And that "secure by default" mentality means they avoid much of the pain other OS developers (including Linux, which I much prefer to admin myself) encounter.
RoR and Ruby have, to my mind and experience, a cultural problem with regards to security. And they're becoming widely enough used that it's starting to show.
To be honest, at least since Rails, the Ruby community has had a "cultural problem" of denial; Ruby is an academic language designed in academia for academic and theoretical problem sets. It's not really practical in most cases, especially when compared to a language of the same class that was designed for pragmatism and real-world usage, like Python. One could say "PHP was designed for pragmatism" but then they'd have to argue PHP was "designed" in the first place, and not just kind of accidentally snowballed from a hobby into a major platform.
DHH latched on to Ruby via Rails and hyped it up and suddenly Rails became the cool kid on the block, but I don't really feel that's deserved from an engineering standpoint. Rails has always been a lot of sizzle and only a little steak, from ill-conceived and convoluted workflows dressed up as "awesome, because it's better than your PHP site!" and rigidity and inability to adapt to normal needs dressed up as "opinionated design".
DHH is the only notable programmer so thick that he actually asserts mathematical background is not helpful to development, and that you should take writing classes instead, and I think that tells a lot about his general practices and his uninformed attachment to Ruby, which has propagated across to others as 37signals got coverage in our communities and more posers jumped on the bandwagon.
DHH latched on to Ruby via Rails and hyped it up and suddenly Rails became the cool kid on the block, but I don't really feel that's deserved from an engineering standpoint. Rails has always been a lot of sizzle and only a little steak, from ill-conceived and convoluted workflows dressed up as "awesome, because it's better than your PHP site!" and rigidity and inability to adapt to normal needs dressed up as "opinionated design".
DHH is the only notable programmer so thick that he actually asserts mathematical background is not helpful to development, and that you should take writing classes instead, and I think that tells a lot about his general practices and his uninformed attachment to Ruby, which has propagated across to others as 37signals got coverage in our communities and more posers jumped on the bandwagon.
"Ruby is an academic language designed in academia for academic and theoretical problem sets"
You make that FUD up yourself? What about Chef, Puppet, writing Ruby scripts for general purpose apps, JRuby (better than Groovy when you can use both jars and gems!), the fact that RedHat's OpenShift (Cloud Hosting of J2EE, etc.) platform depends on Ruby- the list goes on and on.
You make that FUD up yourself? What about Chef, Puppet, writing Ruby scripts for general purpose apps, JRuby (better than Groovy when you can use both jars and gems!), the fact that RedHat's OpenShift (Cloud Hosting of J2EE, etc.) platform depends on Ruby- the list goes on and on.
>You make that FUD up yourself?
No. Matz built Ruby because he thought Perl and Python weren't object-oriented enough. This is decidedly an academic concern. Ridiculously, Matz decided to take Perl over Python as the inspiration for most of his syntax, and if you've looked at Ruby code and gotten Perl flashbacks as I have, there's a good reason for it: it's supposed to be like a super object-oriented Perl. If you love Perl then that's great for you, but there is no reason to presume that Ruby has any real-world applicability. It's basically just Matz's opinion on "how Perl ought to be".
It seems my timeline was a bit incorrect in that Matz apparently worked for a commercial entity when Ruby was conceived, but in a theoretical division ("head of research"). So perhaps the comment should be altered to "Ruby is an academic language designed for theoretical research applications". It has almost no practical redemptive features as compared to modern Python or Lua, MRI is slow and unusable for memory-intensive applications, the syntax is a jumble of esoteric symbols and inconveniences, and so on. There is really no reason, on either a linguistic or practical engineering basis, to prefer it over other scripting languages. People are, and have been since DHH successfully poured his coat of snake oil out, just jumping on the Rails bandwagon and buying that whole song and dance, which was originally produced to promote DHH's consulting firm.
That's not to say some people haven't taken the language and done cool stuff with it, but it's not relevant to the question of the language's individual worthiness.
No. Matz built Ruby because he thought Perl and Python weren't object-oriented enough. This is decidedly an academic concern. Ridiculously, Matz decided to take Perl over Python as the inspiration for most of his syntax, and if you've looked at Ruby code and gotten Perl flashbacks as I have, there's a good reason for it: it's supposed to be like a super object-oriented Perl. If you love Perl then that's great for you, but there is no reason to presume that Ruby has any real-world applicability. It's basically just Matz's opinion on "how Perl ought to be".
It seems my timeline was a bit incorrect in that Matz apparently worked for a commercial entity when Ruby was conceived, but in a theoretical division ("head of research"). So perhaps the comment should be altered to "Ruby is an academic language designed for theoretical research applications". It has almost no practical redemptive features as compared to modern Python or Lua, MRI is slow and unusable for memory-intensive applications, the syntax is a jumble of esoteric symbols and inconveniences, and so on. There is really no reason, on either a linguistic or practical engineering basis, to prefer it over other scripting languages. People are, and have been since DHH successfully poured his coat of snake oil out, just jumping on the Rails bandwagon and buying that whole song and dance, which was originally produced to promote DHH's consulting firm.
That's not to say some people haven't taken the language and done cool stuff with it, but it's not relevant to the question of the language's individual worthiness.
I use Ruby because it is clear and it is the most practical and effective language I've ever used. I'm glad you like Python. Have fun with it.
For others to compare, here are some examples on the c2 wiki:
http://c2.com/cgi/wiki?PythonVsRubyCodeExamples
and stackoverflow:
http://stackoverflow.com/questions/1113611/what-does-ruby-ha...
For others to compare, here are some examples on the c2 wiki:
http://c2.com/cgi/wiki?PythonVsRubyCodeExamples
and stackoverflow:
http://stackoverflow.com/questions/1113611/what-does-ruby-ha...
Since you brought up OpenBSD- there is an example of an OS where so much time and effort was spent on security, the adoption was lower. It's a fine OS, but if you have to wait for years for the DoD to start promoting it and you don't have the consumer adoption that you have with Windows, OS X, and Linux, then I'm sorry but no.
Market share isn't everything. OpenBSD is a perfectly suitable platform for a certain set of applications. If you're doing free-wheeling experimentation type stuff, you may want to use Linux, but if you're serving a fairly conventional web app that isn't going to depend on new language functionality any time soon, *BSD is probably better as a server platform.
A lot of jobs in Java are not for Java Applets running on peoples machines, a lot of the Java work is for client side apps, and for server side apps (think app development like RoR).
Java applets are not necessary.
The reason why the US government said to uninstall Java is because it is the quickest and easiest way for the layman to remove the ability for Java applets to run. If Sun^H^H^HOracle provided a way to just install Java so it can be used for client side apps without turning on Java applets in the browser, then it is not any less unsafe than C++/C#/Obj-C apps running on the same system.
Java applets are not necessary.
The reason why the US government said to uninstall Java is because it is the quickest and easiest way for the layman to remove the ability for Java applets to run. If Sun^H^H^HOracle provided a way to just install Java so it can be used for client side apps without turning on Java applets in the browser, then it is not any less unsafe than C++/C#/Obj-C apps running on the same system.
You missed my point, which was that well-used languages and platforms have vulnerabilities and we still use them. And Java web apps have had security issues too. Do you remember this one? http://www.oracle.com/technetwork/topics/security/alert-cve-...
I am not sure I missed your point. I was simply pointing out that people looking for Java developers has nothing to do with the fact that Java's applet stuff is completely vulnerable.
Yes, other vulnerabilities exist, and they too had to be patched, I don't think dropping an entire language if a flaw is found is a good idea, we wouldn't be left with any, however Ruby on Rails is a framework built on top of Ruby, that is what contains the issues, not Ruby.
Yes, other vulnerabilities exist, and they too had to be patched, I don't think dropping an entire language if a flaw is found is a good idea, we wouldn't be left with any, however Ruby on Rails is a framework built on top of Ruby, that is what contains the issues, not Ruby.
I wonder what DHH has to say about all of this? I seem to remember a few of his posts being pretty harsh on security and security of other platforms. I can't imagine DHH completely washes his hands of these vulnerabilities?
https://twitter.com/dhh/status/289669574427820032
This was his reaction last time there were posts on HN about security vulnerabilities in Rails.
This was his reaction last time there were posts on HN about security vulnerabilities in Rails.
Funny he calls HN a cesspool, "It appears that HN is following the law of large communities: they go to shit." [1] – using Twitter, a community of millions. Plus, he has posted here as recently as 10 days ago. :D
[1] https://twitter.com/dhh/status/289728046230028288
[1] https://twitter.com/dhh/status/289728046230028288
Again? We need a single website alerting RoR devs about vulnerabilities.
I shouldn't have to found out about these things on HackerNews.
Someone build this website for us RoR devs, pretty please? (ps. use PHP - heh)
I shouldn't have to found out about these things on HackerNews.
Someone build this website for us RoR devs, pretty please? (ps. use PHP - heh)
This is the Ruby on Rails Security mailing list:
https://groups.google.com/forum/#!forum/rubyonrails-security
you can view it in the browser but unlike with a vanilla website, you can also receive notifications via an email.
https://groups.google.com/forum/#!forum/rubyonrails-security
you can view it in the browser but unlike with a vanilla website, you can also receive notifications via an email.
Heroku does a good job of notifying its users.
Sounds like a RoR bat-signal!
Twitter works great for this.
You could always wait till the server gets compromised, then the customers could alert you?
Actually, that's how security vulnerabilities are normally handled in the Ruby on Rails world.
What, you think I'm joking? Think again: http://arstechnica.com/business/2012/03/hacker-commandeers-g...
What, you think I'm joking? Think again: http://arstechnica.com/business/2012/03/hacker-commandeers-g...
Good explanation, but it sounds like there is a second component to the issue that this doesn't address: the fact that user input can be converted to symbols, which will ultimately eat memory as new symbols are created.
Great job, Thomas!
Very good explanation - thanks.
Rails gets a lot of scrutiny. Just because your ad hoc Flask app doesn't does not mean it would hold up a lot better. If you believe it will, think very hard about the reasons.
(This is not to say you shouldn't use something else either — just that the gut instinct of "Well, my app on this little microframework won't be getting security advisories every couple of weeks" is not necessarily something you want to follow. Like I said, think very hard about whether you really believe you can do justice to your app better than the Rails security team. And read up on some anecdotes from people who do application security while you're thinking about it, because I find people tend to underestimate just how broken most software is.)