Do The Right Thing

A colleague noted that my posts tend to be “angry old man rants” of the “get off my lawn” (for the record, it is a nice lawn) ilk. I’m not sure if this was a slight against my age, but I do occasionally see the brighter side of our software development world and I’d like to highlight something that recently made me smile.

After several years of users pleading with (and the security wonks groaning at) the Rails development group to escape HTML by default, they’ve finally listened and the latest “Edge” version of Rails will escape output by default and developers will have to explicitly mark a string as “safe” to output unencoded HTML. Why is this such a big deal? Because as the BSIMM project has pointed out, secure-by-default frameworks are a much better approach towards long-term application security than bolt-on security.

John Steven at Cigital posted a few months back expounding upon the value of a secure-by-default framework. I’d like to draw attention to two of the bullet points that I feel are most important to get adoption from a development group:

• Maintains transparency, as best as possible – Those securing the framework can place implementation ‘under the hood’ allowing developers to call functions as normal;
• Moves security ‘lower in the stack’

My previous complaint with Rails (and apparently others had the same frustration) was that the Rails developers had the foresight to include the option for html escaping, but developers had to explicitly invoke it (‘<%= h’ to escape versus ‘<%=’). This made it *very* easy for developers to miss. This behavior was in direct conflict to the “Convention vs Configuration” mantra that Rails has adopted with regard to API design and usage.

That’s enough history for now though. Rails, welcome to the club with the other frameworks that are already doing the right thing:

• Grails -- The Grails gang has been incorporating security into their design since the beginning. The following is the default Grails behavior:

  • All standard database access via GORM domain objects is automatically SQL escaped to prevent SQL injection attacks
  • The default scaffolding templates HTML escape all data fields when displayed
  • Grails link creating tags (g:link, g:form, g:createLink g:createLinkTo and others) all use appropriate escaping mechanisms to prevent code injection
  • Grails provides codecs to allow you to trivially escape data when rendered as HTML, JavaScript and URLs to prevent injection attacks here.

  They have a web page that gives developers a highlight of common web vulnerabilities and how they can address these issues with Grails.
• Django -- As of Django 1.0, HTML escaping is on by default in the Django templates via the autoescape behavior. Unless the developer explicitly turns off escaping or the variable has had the “safe” filter applied, variables are HTML escaped before rendering the output.

If you know of any frameworks that also “Do The Right Thing”, let us know in the comments!

Technorati Tags: ruby on rails software security secure by default fortify