4 ms·

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, y

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
  There are specific things that could be said about the bug in question, like not being secure by default, but this doesn't fix the underlying problem. The development team should recognize that security is an important part of the project and act accordingly.
  - steveklabnik 14y ago
    Seems reasonable. How did they not 'act accordingly' in this case? What should be different about the security process currently in place?

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
There are specific things that could be said about the bug in question, like not being secure by default, but this doesn't fix the underlying problem. The development team should recognize that security is an important part of the project and act accordingly.
- steveklabnik 14y ago
  Seems reasonable. How did they not 'act accordingly' in this case? What should be different about the security process currently in place?