Saturday, November 15, 2008

Language Vulnerabilities

Cruel Fate has lately had me doing a great deal of work in ColdFusion. Comparing this with my UCW/Clsql experience has really driven home to me why there are so many html and sql injection vulnerabilities out there on the web. ColdFusion strongly encourages you to just spit whatever was passed to you back out to the user, and practically punishes you for safely constructing sql strings. In UCW and Clsql, on the other hand, you had to actively try in order to open yourself up to an injection attack on either front.

This got me thinking about how other languages tend to lend themselves to certain vulnerabilties. We're all aware of buffer overflow exploits; these are due almost entirely to the fact that C/C++ force you to waste time managing memory. Such things are virtually non-existent in languages like Lisp or even Java.

So what kinds of vulnerabilities does Lisp usage tend to open you up to? The only thing I can think of are the potential hazards involved in using read. As we had to keep in mind when developing Paragent, you absolutely must set *read-eval* to nil wherever you use read. Otherwise, you are at great risk from the #. macro, which will essentially allow an attacker to (easily) run any code they want on your machine. Happily, it's easy enough to avoid once you're aware of it.

Beyond that, I'm at a loss. Can anybody else think of some security issues that are particular to Common Lisp?