221–230 of 294 posts
Patch right now.
Someone should change the title of this post. I didn't read it for a good 3 hours because I didn't realize it was related to Rails.
Earlier quoted context omitted.
As there have been many exploits / issues recently realized in parameters parsing, why isn't there more of a focus on security here? Specifically, this is where users/hackers can put ANY DARN THING THEY WANT and your server has to deal with it. As a simple solution, one could pass a signed auth-hash of the fields generated by form_for, and the server could re-hash the fields submitted to ensure the form data you aske…
>why isn't there more of a focus on security here? Because this is ruby we're talking about. A "Fun" language that has 100000 ways todo the same thing, so newbs find it fun and easy. You can almost guess how the language works and almost always be right. Thats cool, great for learning, makes you feel like a superstar when you're just getting started with programming... but its really not such a good thing when it com…
I can tell you that "security" is a topic that, unless handled carefully, will make anyone's eyes glaze over.
Earlier quoted context omitted.
+1 Steve Part of being a good developer is understanding your framework and making sure that your app has the level of security you need. The framework cannot protect you from everything. The team responded really quickly. Aaron is a really talented developer and a nice guy. We should all be thanking him. If you don't feel that enough emphasis is being put into security in rails beat away at it, find holes and then g…
http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulner... Here are some good and experienced Rails developers who apparently had no idea that Rails would automagically suck in XML and YAML and turn it into symbols instead of strings. Clearly they aren't the only ones who didn't "understand the framework" or we wouldn't have gone a week with the impression that CVE-2012-5664 was only exploitable in specific circ…
I made the "understand the framework" statement in response to some mistakes I have seen introduced by sloppy dev's on some rails projects I have worked on...That obviously wasn't the case here.......
If security is important you should periodically try to hack the system and consider incorporating automated penetration testing software against your application. I haven't had a need to go this far with my own recent apps so I cannot speak authoritatively on this, but I think there are some tools that can help with doing penetration testing etc..
In a past life I had to work on some pretty secure systems and did some crazy testing on things. I saw a lot of good developers introduce pretty big security holes....my favorite was when our /etc/password was served up by an application...and this was a well known team of craftsman that did this on a fairly large project. None of these have been limited to Ruby projects....they have included Java, C etc..
In my view security is a moving target. If the cost of a attack warrants the effort to protect against it then you do. If not then you don't. Even if the developers of the framework concentrate on security, there will always be ways to get around it. Safe's are rated on the amount of time it takes to break into them, if someone wants into bad enough they will get in. The same is true with software.
Should I be more aware of the security on my apps? probably. Should we as a community be better with it? Yup. But unless I've taken the time to really dig into it, offer constructive feedback and be willing to jump in to fix it I have no business criticizing the state of things.
And I say all of this as someone who loves Ruby.
Earlier quoted context omitted.
No, it's a vulnerability if your app SUPPORTS XML parameters, which all modern Rails apps do . This vulnerability is exploitable even if you don't have any exposed controllers.
Wait, what? What if the app does not parse ANY user provided XML or YAML at all?
Earlier quoted context omitted.
> why isn't there more of a focus on security here? More compared to what, exactly? This vulnerability was responded to pretty damn quickly after it was reported, given that almost nobody is even paid to work on Rails. If you saw Aaron tweeting about "working over the weekend" a few days ago, well, now you know. That said, you mention attr_accessible in your post: that's gone as of the next release of Rails. Basicall…
Nothing gives me confidence in a platform like "almost nobody is even paid to work on Rails."
http://www.insinuator.net/2013/01/rails-yaml/ Some explanation why YAML user input is evil. It works like this 1.9.3p327 :001 > id = YAML.load("--- !ruby/string:Arel::Nodes::SqlLiteral \"1 --\"\n") # if user input can contain arbitrary YAML "1 --" It looks like string, but it's not. 1.9.3p327 :002 > Keyword.where(:id => id).first Keyword Load (0.3ms) SELECT `keywords`.* FROM `keywords` WHERE `keywords`.`id` = 1 -- LI…
Hmm, looking around I am thinking that if you don't want random object instantiation, this monkey-patch: module YAML; @@tagged_classes.delete('tag:ruby.yaml.org,2002:object'); end makes user-supplied YAML a lot less dangerous. I am going to poke this into a production application and see if anything breaks - it really really shouldn't
Earlier quoted context omitted.
Thank you for your fast hard work on this - this is what makes the Rails community so great and why I love it over the other options out there. I know this has to have been a stressful weekend. Is there a tip jar anywhere for beer money for the team that worked on this?
You'll have to ask @bitsweat. I only accept hugs. <3
Earlier quoted context omitted.
Who'd have thought it? Hugely dynamic language turns out to be difficult to audit or analyse for security issues. It was never about Java(C, C++) vs. Ruby despite what fanboys on either side made out. It was about conservative vs. devil-may-care. All that "convenience" and "it's so clean" came at the price of a whole load of code executed behind the scenes. You didn't write it, and the Gods of TDD preached that you d…
Here's a very, very similar exploit from last year... in a popular enterprise Java stack: http://websec.wordpress.com/2012/01/04/multiple-vulnerabilit...
The link you posted illustrates that it is unfortunate that Java supports reflection, and even more unfortunate that various "enterprise" software stacks abuse reflection in ever more creative ways. Stay away of Java reflection and/or use C/C++, and you'll avoid this kind of vulnerabilities.
http://www.insinuator.net/2013/01/rails-yaml/ Some explanation why YAML user input is evil. It works like this 1.9.3p327 :001 > id = YAML.load("--- !ruby/string:Arel::Nodes::SqlLiteral \"1 --\"\n") # if user input can contain arbitrary YAML "1 --" It looks like string, but it's not. 1.9.3p327 :002 > Keyword.where(:id => id).first Keyword Load (0.3ms) SELECT `keywords`.* FROM `keywords` WHERE `keywords`.`id` = 1 -- LI…
Hmm, looking around I am thinking that if you don't want random object instantiation, this monkey-patch: module YAML; @@tagged_classes.delete('tag:ruby.yaml.org,2002:object'); end makes user-supplied YAML a lot less dangerous. I am going to poke this into a production application and see if anything breaks - it really really shouldn't