• Print

Let’s do this the hard way

Being both liberal and safe in programming is hard

Recent discoveries of security vulnerabilities in Rails and MongoDB led me to thinking about how people get to write software.

In engineering, you don’t get to build a structure people can walk into without years of study. In software, we often write what the heck we want and go back to clean up the mess later. It works, but the consequences start to get pretty monumental when you consider the network effects of open source.

cartoon-37304_640You might think it’s a consequence of the tools we use—running fast and loose with scripting languages. I’m not convinced. Unusually among computer science courses, my alma mater taught us programming 101 with Ada. Ada is a language that more or less requires a retinal scan before you can use the compiler. It was a royal pain to get Ada to do anything you wanted: the philosophical inverse of Perl or Ruby. We certainly came up the “hard way.”

I’m not sure that the hard way was any better: a language that protects you from yourself doesn’t teach you much about the problems you can create.

But perhaps we are in need of an inversion of philosophy. Where Internet programming is concerned, everyone is quick to quote Postel’s law: “Be conservative in what you do, be liberal in what you accept from others.”

The fact of it is that being liberal in what you accept is really hard. You basically have two options: look carefully for only the information you need, which I think is the spirit of Postel’s law, or implement something powerful that will take care of many use cases. This latter strategy, though seemingly quicker and more future-proof, is what often leads to bugs and security holes, as unintended applications of powerful parsers manifest themselves.

My conclusion is this: use whatever language makes sense, but be systematically paranoid. Be liberal in what you accept, but conservative about what you believe.

tags: , ,
  • http://eddology.com/ Edd Dumbill

    More pertinent info in this article

    http://blog.sdelements.com/why-the-latest-rails-exploit-is-indicative-of-a-bigger-problem/

    Quote: [[

    Security-minded developers can protect themselves by taking the following steps:

    Turn off unnecessary extensibility in third party libraries and frameworks

    Do not use untrusted input in libraries that provide broad extensibility, such as Apache’s Xalan with extensions enabled

    Be vigilant about monitoring for and patching newly discovered vulnerabilities in frameworks and third party libraries. Wherever possible, sign up for security mailing lists or groups likeRuby on Rails Security

    ]]