Convenience in web frameworks is often insecure
For those of you who have not heard, GitHub was compromised today, or more exactly a long-standing vulnerability was demonstrated today. They were compromised because of a feature in Rails called 'mass assignment' that by default allows web operations to update any field of the model record.
(I don't know enough Rails to confidently say what web operations in
specific allow this, although some sources suggest
PUT operations. I
also don't know if they're tied to forms or can be submitted just out of
No doubt there are a certain number of people who are now pointing and laughing at Rails. They probably shouldn't be. Lots of web frameworks have a terrible history of this sort of vulnerability, because of a core conflict: convenience in frameworks is often insecure, by the nature of how web frameworks achieve convenience.
Fundamentally, a great deal of the convenience of frameworks comes from not having to say things; this is the mantra of 'convention over configuration'. The problem is that being secure invariably requires saying things, one way or another (either to allow access to some things when the default is no access or to block access to some things when the default is access to all). Thus the most 'convenient' way for a framework to operate, the one that requires saying the least, is to be insecure by default. This doesn't require your users to say anything unless they notice the security issues and care, whereas the other way around requires your users to say extra things to get access to stuff they want.
(Sometimes, if you're clever, you can figure out how to be both secure and convenient. This is great when it works and framework authors should do as much of it as possible; for example, these days there isn't any excuse for a framework that doesn't validate a received form submission against the form's allowed parameters. Note that this doesn't seem to have been the Rails problem here.)
And so over and over again, frameworks are insecure by default and people do not say the things to use them securely. Or, to put the blame where it belongs, the creators of frameworks decide that making them insecure is okay because people who need security will fix them, even though everyone has seen repeatedly that people don't do that.
(Thus, framework creators often fail to solve the real problem. If you create a system that people do not use securely you have failed to create a secure system in practice, even if it's secure in theory. Always remember, security is people, not math and theory.)