This reminds me of how PHP used to turn HTTP request variables directly into global programming variables by default. Now it only happens when you enable the register_globals option. I don't think I've ever met anyone who didn't consider it a huge security issue.
This rails behavior is actually even more powerful than the old PHP one for hackers because with this you get directly into the model and then the DB when everything is still left as generated, not just the temporary variables. It's actually pretty surprising how much resistance there is to fixing the issue.
It could be that the proposed whitelisting isn't the only solution. It does require annoying configuration. With PHP, nowadays, most people just access a particular array when they want their request variables. Similarly, maybe Rails could have a request model object and a DB model object with simple methods for copying state between the two. Maybe combine it into some sort of validation logic with user friendly error messages being specified. I guess it is still more work that default overwriting of the DB with request variables, though.
I was also thinking of PHP's register_globals. I was tempted to make a snide remark, so I'll make it now. The difference here is that the PHP group realized register_globals was a bad idea, deprecated it in 5.3 and removed it in 5.4. Furthermore the default has been OFF since 4.2.0. The resistance to fixing the Rails problem just makes me ever less likely to give Rails a shot, it should be really bad PR when you ignore security issues.
Inconsistent error handling, for example. Why do some functions fail silently, some functions return false, some functions produce warnings, some functions throw exceptions, and some functions tell you to call another function to retrieve the error code?
Ruby and Python are much more consistent in that regard.
If a field doesn't have any validation rules set it will be thrown out when you save the model. This way you won't mass-assign to a column that was never meant to be mutable. Its a little more work to get up and running, but I think its a good tradeoff.
(You do have the option of turning this off, but you'd have to do it intentionally).
This rails behavior is actually even more powerful than the old PHP one for hackers because with this you get directly into the model and then the DB when everything is still left as generated, not just the temporary variables. It's actually pretty surprising how much resistance there is to fixing the issue.
It could be that the proposed whitelisting isn't the only solution. It does require annoying configuration. With PHP, nowadays, most people just access a particular array when they want their request variables. Similarly, maybe Rails could have a request model object and a DB model object with simple methods for copying state between the two. Maybe combine it into some sort of validation logic with user friendly error messages being specified. I guess it is still more work that default overwriting of the DB with request variables, though.
reply