146 | Chapter 5: Security
The message passed in to that method will always be the third parameter tosvn,no
matter what kind of shell metacharacters it contains.
Object Tainting
Taintingis an idea that came to Ruby from Perl. Because data that comes from the
outside is not to be trusted, why not force it not to be trusted by default? Any data
read from the environment or outside world is marked as tainted. Depending on the
current value of a special Ruby global,$SAFE, certain operations are prohibited on
tainted data. Objects may only (officially) be untainted by calling theiruntaint
method.
This is a good idea that, because of implementation details, has not gained much
traction in the Rails community. It can become a pain to deal with every piece of
data that was derived from user input. There is one Rails plugin, safe_erb, which
leverages tainting to ensure that all user-supplied data is HTML-escaped before being
displayed again. Request parameters and cookies are tainted upon each request, and
an error is raised if tainted data is attempted to be rendered. (The Ruby tainting facil-
ity is not used other than as a flag on the objects, because anything more would
require a $SAFE level greater than zero, which is Rails-unfriendly.) This reduces the
possibility of cross-site scripting attacks. The plugin is available at http://
agilewebdevelopment.com/plugins/safe_erb.
Further Reading
The HTTP/1.1 specification, RFC 2616, has some guiding principles for security at
the HTTP level (http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html).
Current Rails best practices for security are summarized athttp://www.quarkruby.com/
2007/9/20/ruby-on-rails-security-guide. This guide provides “cookbook”-style solu-
tions for many real-world problems such as authentication; mitigating SQL injection,
XSS, and CSRF; handling file uploads; and preventing form spam.