Ruby on Rails cheatsheet: the review

Jim Manico is a friend and a rinomated security
professional. He
in Owasp mailing list that a Ruby on Rails cheatsheet is

I asked Jim to introduce himself.

Jim Manico is the VP of Security Architecture for WhiteHat
Security, a web security firm. He authors and delivers developer
security awareness training for WhiteHat Security and has a background
as a software developer and architect. Jim is also a global board member
for the OWASP foundation. He manages and participates in several OWASP
projects, including the OWASP cheat sheet series and the OWASP podcast

This is a critical review about the cheatsheet. My concern, as well other
venerable Owasp leaders, is to provide content that it can be consumed by
developers rathern than only by security researchers with some coding skills.

The cheatsheet is authored by:

  • Matt Konda – mkonda [at]
  • Neil Matatall neil [at]
  • Ken Johnson cktricky [at]
  • Justin Collins justin [at]
  • Jon Rose – jrose400 [at]
  • Lance Vaughn – lance [at]
  • Jon Claudius – jonathan.claudius [at]
  • Aaron Bedra aaron [at]

Kudos for all those guys for their work and commitment.

The review

First of all, let me say one thing: the document Jim and other guys wrote is:

  • clear
  • with security in mind
  • almost practical

This cheatsheet has very valuable content in it and you can use it, right
, to improve your Ruby on Rails secure coding workflow.

The KISS paradigm is applied to this document and every item is shortly
described giving the reader the opportunity of going deeper with further

The first thing I found it would be better in terms of approach is that there
is no a logical organization for the item described in the cheatsheet. It would
better having them grouped by web application macro areas like authentication
& authorization
, input validation, error handling and stuff like that.

Command injection
wrote this way it’s not a Rails specific issue. Of course the important bit is
not to bind user controlled inputs to strings passed to the operating system as
commands to be executed.

The part about authentication
suggests about using Devise (and this is good) but in a cheatsheet there is no
enough space to cover how to create an autentication mechanism using Devise.
True to be told the code snippets provided are not enough for an early reader
knowing nothing about implementing a good authentication mechanism. You may
want to read a blog post I wrote in November about implementing an authentication mechanism for Padrino and omniauth
It would be a better approach to grab a list of authentication frameworks, with
pointers and blog posts, and give the reader some security tips for each of

For the forceful browsing
section, an example about how to use cancan to enforce some authorization

Finding business logic bugs
is a tricky task, the most difficult in a web application penetration test. As
a security tester one of your task is trying to subvert application business
logic in order to have the target application to do whatever you would do. And
the penetration test is missing from the key ways to protect your application
from business logic flaws.

We love

  • Upcoming Rails 4 is cited
  • Rails is growing up as web framework and it’s great having security material
    to create awareness

We love less

  • The overall document is for sure intented to be consumed by developers but
    it’s clear it has been written by security researchers
  • Pointers to Owasp attack detailed description must be placed in order to
    create awareness about risks. My experience is that a developer is not
    trained to see security risk so he couldn’t understand at first glance why he
    should change his working code.
  • Covers only ActiveRecord as ORM

Off by one

Of course, the
work is valuable and it’s pretty easy to use this cheatsheet in everyday
workflow as a reference. I’d like to see it improved with other Ruby powered
web frameworks like Sinatra or Padrino and for other ORMs like Datamapper.

This cheatsheet it’s a draft as authors say in the web page, so I can’t wait to see any great improvements, hopefully more about upcoming Rails 4.

*** This is a Security Bloggers Network syndicated blog from - the application security blog that gets the job done authored by Paolo Perego. Read the original post at: