4 ms·

Ok, at risk of turning this post into a flame war, I feel I'm obligated to call out what it is: Ruby devs: stop making excuses! Security is hard, but ther

by wyuenho 14y ago

Ok, at risk of turning this post into a flame war, I feel I'm obligated to call out what it is: Ruby devs: stop making excuses! Security is hard, but there are also a lot of very simple and effective ways to minimize vulnerabilities, e.g. a mere excising of your cerebral cortex for a few minutes before you make a decision is a very good way in preventing security vulnerabilities from being introduced in the first place. The mere fact of deciding to default to using YAML as the default JSON parser without disabling arbitrary object construction is a mind-numbingly dumb decision. What's more fucked up is the fact that this commit actually made it into the code base, and it's not even a recent decision. Apparently it's been in the code base as far back as the 2.3 days. Basically, thousands and thousands of Rails devs have looked and used this "feature" and believed it's not a bug. This is a systematic and cultural failure and crime against reason perpetrated by the Rails community, which also happens to be a vast majority of the Ruby community. It's time you guys learn some proper security 101.

bradleyland 14y ago
I think you're being downvoted because you set up a bit of a strawman there. By my read, the central focus of this article is to explain a very dangerous vulnerability in an accessible way. It didn't come across as having made a lot of excuses.
- wyuenho 14y ago
  I'm just going to quote directly from the post: The holes in Rails XML and JSON parsers for different vulnerable versions have been fixed, and some have asked why they weren’t detected and patched earlier. The simple answer is: security is hard. These issues are only obvious in retrospect. Rails and Ruby aren’t any less secure than other frameworks and languages. Security vulnerabilities are bugs at their core, and very difficult to detect. There is almost guaranteed to be insecure software on your laptop/phone/server/garage- door-opener somewhere – it just hasn’t been discovered yet. I don't disagree with the last 2 sentences. But I don't agree with the first part of this paragraph at all and I have to call it out. I don't agree my example was a strawman, Rails has a track record of introducing 8 code execution vuln and 8 SQL injection vuln. Django has 1. The fact is, it's not just this article that was making excuses, it's the Rails devs that have their bottom-line at stake that have come out of the woodwork since Jan that have pissed me off. Example: This guy who wrote a response to the "What The Rails Security Issue Means For Your Startup" post: http://isotope11.com/blog/what-the-rails-security-issue-shouldnt-mean-for-your-startup They are also prevalent in the past HN threads discussing Rails vulns. Note to Rails devs: if you want to secure your bottom-line, you should probably do your part in writing secure(r) software.
  - bradleyland 14y ago
    There's very little you're saying here that I disagree with. I also agree with you on the matter of Ruby on Rails being less secure than other frameworks. A friend of mine quipped the other day that it's time for Ruby devs to "take of their brogramming cool-shades and embrace some of what the neckbeards have been telling us." I just don't interpret "security is hard" as an excuse. You just repeated the phrase yourself, yet your central point seems to hinge on that being an excuse. You saw fit to put it in its own block and indent it. There are also a community of Ruby developers who are trying very hard to improve the situation. I'm sure there are more, but the group at the forefront of my mind is Ronin Ruby [1]. In order to improve, we must first admit that we have failed. For my part in the Ruby community, I humbly admit that we can do better. [1]:http://ronin-ruby.github.com http://ronin-ruby.github.com
    - wyuenho 14y ago
      The central point I'm trying to make is this article is being disingenuous. Security is hard, but not so hard that a minute or two of thinking and filing a PR won't prevent the YAML exploits. I don't actually think the Rails community is dumb, that's why this whole thing pissed me off so much because the fact that it was even introduced and existed for so long tells me that thousands of Rails devs have just decided to turn a blind eye over the years. I'm well aware the Ronin guys BTW, I have mentioned them in a comment in another HN thread a few days back and called for help for those 2 guys. bauland42 who is behind http://www.rorsecurity.info/ http://www.rorsecurity.info/ also deserves an honorable mention. Good luck Rubyists.

by wyuenho 14y ago

bradleyland 14y ago

I think you're being downvoted because you set up a bit of a strawman there. By my read, the central focus of this article is to explain a very dangerous vulnerability in an accessible way. It didn't come across as having made a lot of excuses.

wyuenho 14y ago
I'm just going to quote directly from the post: The holes in Rails XML and JSON parsers for different vulnerable versions have been fixed, and some have asked why they weren’t detected and patched earlier. The simple answer is: security is hard. These issues are only obvious in retrospect. Rails and Ruby aren’t any less secure than other frameworks and languages. Security vulnerabilities are bugs at their core, and very difficult to detect. There is almost guaranteed to be insecure software on your laptop/phone/server/garage- door-opener somewhere – it just hasn’t been discovered yet. I don't disagree with the last 2 sentences. But I don't agree with the first part of this paragraph at all and I have to call it out. I don't agree my example was a strawman, Rails has a track record of introducing 8 code execution vuln and 8 SQL injection vuln. Django has 1. The fact is, it's not just this article that was making excuses, it's the Rails devs that have their bottom-line at stake that have come out of the woodwork since Jan that have pissed me off. Example: This guy who wrote a response to the "What The Rails Security Issue Means For Your Startup" post: http://isotope11.com/blog/what-the-rails-security-issue-shouldnt-mean-for-your-startup They are also prevalent in the past HN threads discussing Rails vulns. Note to Rails devs: if you want to secure your bottom-line, you should probably do your part in writing secure(r) software.
- bradleyland 14y ago
  There's very little you're saying here that I disagree with. I also agree with you on the matter of Ruby on Rails being less secure than other frameworks. A friend of mine quipped the other day that it's time for Ruby devs to "take of their brogramming cool-shades and embrace some of what the neckbeards have been telling us." I just don't interpret "security is hard" as an excuse. You just repeated the phrase yourself, yet your central point seems to hinge on that being an excuse. You saw fit to put it in its own block and indent it. There are also a community of Ruby developers who are trying very hard to improve the situation. I'm sure there are more, but the group at the forefront of my mind is Ronin Ruby [1]. In order to improve, we must first admit that we have failed. For my part in the Ruby community, I humbly admit that we can do better. [1]:http://ronin-ruby.github.com http://ronin-ruby.github.com
  - wyuenho 14y ago
    The central point I'm trying to make is this article is being disingenuous. Security is hard, but not so hard that a minute or two of thinking and filing a PR won't prevent the YAML exploits. I don't actually think the Rails community is dumb, that's why this whole thing pissed me off so much because the fact that it was even introduced and existed for so long tells me that thousands of Rails devs have just decided to turn a blind eye over the years. I'm well aware the Ronin guys BTW, I have mentioned them in a comment in another HN thread a few days back and called for help for those 2 guys. bauland42 who is behind http://www.rorsecurity.info/ http://www.rorsecurity.info/ also deserves an honorable mention. Good luck Rubyists.