Perl's taint checking to the rescue
Fri, 17-Nov-2006 by
Andy Lester
edit post
<![CDATA[
I read today in the November 15th issue of <a href="http://www.sdtimes.com">Software Development Times</A> (an actual paper publication!) that buffer overflows are no longer the most common update security problem reported by CVE (<a href="http://cve.mitre.org/">cve.mitre.org</a>).
<p>
The three most common types of security vulnerabilities in 2005 were cross-site scripting (16.0%), SQL injection (12.9%) and buffer overflows (9.8%). So far in 2005, buffer overflows has lost the #3 place to PHP remote includes.
<p>
The good news is that Perl has long had capabilities in the language and its most common libraries that effectively shut down many of these attacks.
<p>
It's not surprising that buffer overflows are on the way out. Perl programmers have long been able to not worry about buffer overflows. Dynamic strings mean no buffer overruns. Fortunately, all the new dynamic languages like Ruby, Python and PHP have dynamic strings as well, leaving only C and C++ programmers having to worry about the size of their malloc buffers.
<p>
Where Perl shines in web security is with its built-in "taint mode". When taint mode is enabled, all data from an external source, such as from a web input form, is assumed to be untrusted and tainted. If a user types in her name, the resulting string is marked internally as tainted. Most of the time, this effect is invisible.
<blockquote>
<pre>
print "Hello, $name, glad to see you.\n";
</pre>
</blockquote>
Perl will print out the the user's name, because no matter what $name is, it doesn't present a security risk. However, consider this common rookie programmer mistake.
<blockquote>
<pre>
$dbh = ... code to make a database connection ...;
$dbh->do( "insert into visitors (name) values ('$name')" );
</pre>
</blockquote>
That works fine for values of $name like "Bob Smith", but consider a string like:
<blockquote>
<pre>
'); drop table visitors;
</pre>
</blockquote>
Your SQL expands out into
<blockquote>
<pre>
insert into visitors (name) values (''); drop table visitors;')
</pre>
</blockquote>
That results in three statements, separated by semicolons: One inserts an empty value in the "visitors" table, the second deletes the "visitors" table, and the third a syntax error. The effect is that one well-crafted string from a miscreant means you've lost your data table. The possibilities are endless.
<h2>Taint mode to the rescue!</h2>
With Perl's taint mode, and DBI's TaintIn attribute enabled, SQL injection attacks can't happen. Perl's DBI module sees the tainted data, since any data created from tainted data is also tainted, and refuses to execute the command. In effect, DBI says "You don't know that the SQL command you're passing me is trustworthy, so I won't run it."
<p>
Of course, DBI handles the safe way of doing SQL calls, using placeholders:
<blockquote>
<pre>
$sth = $dbh->prepare( "insert into visitors (name) values (?)" );
$sth->execute( $name );
</pre>
</blockquote>
The data is passed to DBI, but entirely separately from the command. The command is not created using tainted data, so is safe for DBI to execute.
<p>
SQL injection prevention is just the beginning of the value of taint mode to Perl programmers. Tainted data also can't be used for executing system commands or reading source code, as in the PHP remote include exploits. For a more thorough discussion of how taint mode works, and why you want it on in every web program you write, see the <i>perlsec</i> documentation for Perl with <tt>perldoc perlsec</tt>, or online at <a href="http://perldoc.perl.org/perlsec.html">http://perldoc.perl.org/perlsec.html</a>
<p>
I hope that other dynamic languages continue to borrow Perl's features and add explicit taint-mode checking to their bags of tricks. Modern web development demands it.
]]>
Comments (1)
"With Perl's taint mode, and DBI's TaintIn attribute enabled, SQL injection attacks can't happen."
This isn't true. Taint checking does not prevent this. It simply doesn't allow it with tainted data. The user can still untaint data incorrectly, and SQL injection attacks can still happen.
