I recently received an email whose question was quite reasonable but surprised me nonetheless. In my CGI course, I harp on security quite a bit. Don't do this. Don't do that. Really don't do that one!
The author of the email, however, started to wonder if Perl was more dangerous than other languages due to all of these warnings. He has experience with JSP, ColdFusion, PHP, etc. He wrote "I don't remember that the issue of code security in any of these environments was as serious as it appears to be for CGI/Perl." He wondered if perhaps Perl is more vulnerable than those other tools and should he therefore not use it?
On the surface, this question seems silly. However, it's not. Programmers are so rarely exposed to security issues that when they arise, they're frequently a surprise. Personally, I've never taken a programming class where I can remember the issue being raised. In fact, glancing through my texts on various languages I see that security is rarely if ever mentioned. As a result, my course seems out of step with current pedagogy, though I'm unlikely to change it. If anything, I'll add more security information.
In any event, what follows is my (edited) reply to his question.
--
Actually, the short and easy answer is: those other languages are just as dangerous.
The long answer is a bit more complicated, but I'll try to keep it brief.
Security takes many forms. "Promiscuous" code is a serious problem with any language, for example. Storing a username and password in a cookie or giving an attacker too much information by telling her "what failed and why" is a systemic problem. Leaving default or easily guessable passwords or letting someone try to log in as many times as they like without locking them out is nother common problem. Perl has nothing to do with this.
Other issues tend to be less visible but are also global. For example, SQL injection attacks are extremely common (you can google for them). If you can type a single quote mark into a form field and the script throws an error, that's a strong indication of the problem. (For some reason, I've seen this quite a bit in ASP code.) Another common problem would be storing user-supplied data in a database and later showing this on a Web page without escaping HTML entities. This is one of the ways cross-site scripting attacks are born. Perl also has nothing to do with this, though it can be handled wrong in Perl just as easily as other languages.
All tools have their specific weaknesses. The only Perl-specific hacks that I can think of right off the top of my head are null-byte hacks and algorithmic complexity attacks. The latter has been fixed in the latest versions of Perl and the former tends to be very uncommon (I've never heard of it actually being exploited.)
And the single most common security exploit -- buffer overflows -- is something Perl is not vulnerable to. (And Perl also tends not to suffer from "off by one" errors which are one of the most common sources of bugs, but that's another story.)
Perl, however, offers "taint mode." Very few languages do this. With taint mode, when Perl detects you're trying to do something unsafe with insecure data, it simply kills the program rather than allow things to proceed. This is one of the strongest protections against attack that any language can provide. I'm at a loss to know why this useful technique is not more widespread.
The reason you probably are not as aware of this is simple: not many people know much about security. Good Web programming courses in other languages would cover this stuff in depth, but they don't. This is one of the many reasons why you read about computers getting hacked all over the world. People's awareness of this issue simply has not been raised. Admittedly, some might think I'm being alarmist, but few fault my security advice.
And in a related anecdote which illustrates the problem well, a few years ago I was applying for a job working with Perl and C. The owner of the company was showing me one of their flagship products: a custom Web templating language. This was a proprietary language I had never seen before, but only a few seconds after he started showing me I mentioned that their code appeared to make them vulnerable to an SQL injection attack. The owner looked at me strangely and said "we've been selling this for years and only discovered that a couple of weeks ago."
A few minutes later, I noticed that they appeared to be creating cookies with sequential session ids. This allows for easy session hijacking and is a huge vulnerability.
This was a product that professionals had been developing for years and I, out of blind luck, looking at a language I had never seen before, spotted common serious security issues. I knew there were going to be many of them and I elected not to take the job they offered.
Trust me. This is not a Perl issue. Any time you expose your computer to other computers via a network you tremendously raise the chances that it will be attacked and compromised. I'm just doing my part to ensure that Perl programmers are not responsible for creating more victims :)
I now understand enough about security, to know that I don't actually know all that much. I'm now more careful than I use to be, and I think the code I write is safe enough.
This week I've started to learn about a SAP system. For security reasons the root password on the AIX and Linux boxen it runs on are changed every 90 days - an unpopular feature that an auditor insisted on, yet nobody bats an eye lid that they are all running telnet, rsh and NFS unprotected on the company intranet. Contrasting this we have my firm's humble web servers, that all use SSH, with pretty much every service turned off, and the latest one additionnaly runs iptables.
Things like a wide variety of ready-rolled strong encryption libraries and integration with standard SSL and SSH libraries, as well as the taint mode put it well ahead of languages like PHP, ASP and Cold Fusions.
The culture of testing and defensive programming is also stronger than in some other cultures - Java programmers are certainly hot on testing (at least there is a big overlap of Java and Test enthusiasts like Kent Beck), but not so much on defensive programming.
c# and python are probably the only other mainstream languages to have such a strong culture of testing and defensive programming because they, like perl have been taking these ideas on board.
