FrameworksDefaultSecure written at 20:14:49; Add Comment
Web frameworks should be secure by default
In reaction to the recent GitHub Rails vulnerability, raganwald wrote in part (about the Rails security issue):
I understand why this view of insecure-by-default is popular, but it's making a fundamental mistake. The problem with the 'insecurity as a sharp tool' view is that insecurity is not like the other sharp tools in Rails' toolbox. When you misuse or misapply others of those sharp tools, you're very likely to find out right away because your webapp doesn't work right; things break, assuming that you actually test your features. You know that you've cut yourself and you need to fix it. With security issues, it's not at all obvious that you've just cut yourself on the edges of a sharp tool, because nothing obvious breaks or goes wrong. Security bugs are not like normal bugs; this is a large part of why they are hard to find.
(To extend the metaphor beyond the breaking point, default insecurity is not just a sharp tool, it is a sharp tool coated with an anti-coagulant and a numbing agent. Most people wouldn't want to work with such a thing.)
The real world argument for frameworks being secure by default is pragmatics. We pretty much know how most people develop web applications using frameworks; 90% or more of them do just enough to get their application working and tested (and many apps will not be fully tested, especially things like error paths). Only a very few people will go back and carefully audit their application for security issues (or probably even read your security documentation unless it's shoved in their face). If your framework ships as insecure by default, most of your developers will never notice and many of the web applications written in it will be insecure. This is not theoretical; as we've just seen with GitHub and Rails, it's what really happens, even with smart people and very good teams, and it happens over and over again. You cannot argue that people should be smarter and better than that, not if you are designing a framework for real people, because we know that they aren't.
(One fundamental reason it keeps happening is that security is almost always an overhead, not a selling feature. Teams are under relentless pressure to prioritize for features, because that's what people care about and can actually see. If they have to remember to do extra things for security, sooner or later those things are going to be overlooked in the rush to produce.)
ConvenientFrameworksAndSecurity written at 00:39:12; Add Comment
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
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.)
* * *