29 ms·

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 wher

• steveklabnik 14y ago
  > 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. Basically everyone agrees that strong_parameters is a better approach, which is why a gem was released that works with 3.2: you can use that better approach now. As was mentioned below, security is a process, not a result. Nobody wants these kinds of issues to happen, but they will happen, and do to every single framework that's used by lots of people.
  • mikeycgto 14y ago
    If you've recently started a new Rails project (or are thinking about it), you should use strong_parameters right off the bat!
    • steveklabnik 14y ago
      Agreed! That is what I teach when I do training.
    • pekk 14y ago
      Why is strong_parameters not the only way? Rails is pretty opinionated in many other respects...
      • jenius 14y ago
        It will be the default in rails 4... so soon : )
      • bratsche 14y ago
        It was opinionated to use attr_accessible until a better approach came along. Beginning in 4.0 it will be opinionated to use strong_parameters, but they can't just take attr_accessible away because a lot of people are upgrading apps.
      • steveklabnik 14y ago
        The downside of 'don't break APIs for minor version changes' means that you can't break APIs until the major version changes. ;)
    • joevandyk 14y ago
      I'm not 100% positive, but I don't think strong_parameters would do anything to protect you here.
      • steveklabnik 14y ago
        It would not have helped with this vulnerability, no. But it is a better way of handling filtering appropriate parameters.
  • nachteilig 14y ago
    This is actually the first I'm seeing about strong_parameters, since I don't follow Rails 4 stuff much right now. Thanks for the tip!
    • steveklabnik 14y ago
      Any time. Please let me know any issues/problems/thoughts you have with it.
  • lgleason 14y ago
    +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 get involved in developing fixes for them. That is the beauty of open source. Matz developed Ruby for adults. You get a lot of power, but also a lot of rope to hang yourself with. This is why testing in rails applications is so important.
    • marshray 14y ago
      http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulnerability-hold-your-horses-here-are-the-facts/ 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 circumstances.
      • lgleason 14y ago
        That's not my point.... 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.
  • subsystem 14y ago
    I really hope this isn't the sentiment of the RoR community. There has to be a place for critique when it's warranted. At this scale it's not a joke any more, you ask for what you need and otherwise you do less.
    • steveklabnik 14y ago
      I specifically asked them to elaborate on what could be made better.
      • lambda 14y ago
        Less magic. The more magic, unexpected behavior you have when parsing untrusted input, the more likely you are to have security holes. Instead of building up some complex object based on untrusted input, the author of the application should specify the values and types expected, and the parser should parse those and nothing more. This would lead to much simpler code paths, as the user never has an object that has unexpected keys, values, behaviors, etc. Don't parse the object using complex, general purpose code, then hand the user an object that they have to treat specially; if their form only expects 5 values of given types, then parse only those values and those types. The problem is, all of this kind of magic is at the very heart of what Rails is. I don't know if you could eliminate it all and still have Rails be Rails.
        • nthj 14y ago
          This sounds a lot like strong_parameters, which (I believe) will be the default in Rails 4, and is only a gem install away from Rails 3.2 apps. https://github.com/rails/strong_parameters https://github.com/rails/strong_parameters
          • steveklabnik 14y ago
            It will be the default, yes.
      • subsystem 14y ago
  • smackfu 14y ago
    Nothing gives me confidence in a platform like "almost nobody is even paid to work on Rails."
    • steveklabnik 14y ago
      I'm sure some Core developers would love your sponsorship to give even more time to devote to Rails development. Even without the money, this issue was dealt with swiftly. See the comments below about 'the Rails security team is the best vendor I've worked with.'
    • awj 14y ago
      Yes, judging platforms by how many people are paid to work on them instead of track record or other verifiable merits is totally the best way to go.
    • InclinedPlane 14y ago
      I agree, this is a dangerous sentiment. Whether money is involved or not, for a framework, developers should either be committed to their products or not. If this was a different sort of product then that limitation of not getting paid might carry some weight, but when you encourage people to develop on top of your platform and when it is shown to have egregious flaws there is no excuse. You either get to work fixing them or you tell the world to stop using your framework because it's broken and not going to be fixed. Fortunately, the Rails devs are seriously committed to their product, which is why these fixes came out so quickly. Edit: The Rails team is certainly deserving of many thanks, but they don't get a pass on problems just 'cause they work for free. Similarly, if someone gives me a free car I will thank them, but if that car starts a fire in the garage and burns down my house I will curse them too.
    • lgleason 14y ago
      I thought some come of the core committers had their work sponsored by their employers.
      • steveklabnik 14y ago
        Aaron is the only person on core who is paid to work on Rails. (Among other things.) I am a committer, and part of my job is to work on open source. Ish. Other than that, it's everyone else's spare time, IIRC.
  • sj26 14y ago
    Cost/benefit. There are always going to be security holes in anything we make. We can be a bank and focus two feet ahead on making sure everything is as secure as possible, or stay aware of security (and not do anything stupid) while moving fast enough that any flaws are irrelevant/fixed when exposed. It also highly depends on how much risk you're willing to accept. For the average rails app, absolute security is not as important as moving fast. Be an adult and make adult decisions about your tools and processes to suit your circumstances.
• halogen64 14y ago
  > 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 asked for is what you get (this solves the primary issue with attr_accessible). It does not solve the issue of javascript generated forms.
  • ghayes 14y ago
    Sure, but as with all things, it could be turned off. The more I think about it, the more I like this idea. I may as well try it out and mock up a pull request.
    • dasil003 14y ago
      If you turn it off then you're back to square one security-wise. Apps that have neither APIs nor JS are an increasingly small share these days. Also consider what is possible to sign. In most cases there will be some non-enumerable data in the field, leaving you with only being able to verify the field names, but there could be nested data and it seems like a 50/50 shot that whatever unforeseen vulnerability would not need to change the top-level params anyway. I don't think this would afford much of a security guarantee. The only way to fix this by "more of a focus on security" would have been not to do clever things with parameters in the first place, but the clever things provide a lot of value, so the next best thing is security auditing and be on top of patching any vulnerabilities.
• deleted 14y ago
  [deleted]
• alexanderh 14y ago
  >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 comes to maintainability, and security. This breads a community of people who arent very mindful of anything but having fun coding. (not always a bad thing, but certainly not conducive to good security) The second you talk about "Multi-platform" or "security" to your average ruby user, their eyes glaze over. They just want to make cool stuff on their Mac, not worry about Security and best practices. You could say the same thing about a lot of interpreted languages, but Ruby is especially bad.
  • Turing_Machine 14y ago
    Yes, you're right. There have never been any security problems with "serious" "nonfun" languages like C, or Java, or the .NET stack. :-/ This has nothing to do with the Ruby language, by the way, any more than a hole in IIS is a problem with .NET. If you're going to talk smack, at least learn what you're talking about.
    • marshray 14y ago
      Hey, did you hear that scanf() will accept XML and YAML and automatically convert it into pointers handy for you to dereference? Neither did I.
      • tptacek 14y ago
        Or how about when you put that 256th character in a ruby string and end up overwriting heap metadata? Man I hate it when that happens.
        • marshray 14y ago
          There are known undefined behaviours and there are unknown defined behaviors. Which is worse?
• bascule 14y ago
  That's an interesting suggestion but it has nothing to do with the problem at hand. The problem here was a feature somewhat haphazardly added to Rails for ActiveResource was turned on-by-default and enabled features that should only be active for interactions with trusted clients (i.e. authenticated services running in your own infrastructure) Your suggestion is not without merit, but this is a case of having to learn to walk before you learn to run. There are clearly much more egregious parameter parsing vulnerabilities which need to be solved before the things you're describing would ever make it into rails-core.