After a recent post on our message board and reading up a little bit here and there, I figured
I’d go ahead and write an article on security for a change. Most of us (programmers that is)
already know what I’m about to write (or they -should- know) but for newbies it might
be interesting.
First of all, is Perl a secure language? That really depends on the programmer.After a recent post on our message board and reading up a little bit here and there, I figured
I’d go ahead and write an article on security for a change. Most of us (programmers that is)
already know what I’m about to write (or they -should- know) but for newbies it might
be interesting.
First of all, is Perl a secure language? That really depends on the programmer. It’s the same
as driving really, you can either drive like a maniac or drive defensively. It’s the same
with Perl programs. If you code like a maniac without thinking about what your code
actually does, well, let’s just say the results could be ugly.
Case in point, the message on the messageboard pointed out a rather simple flaw. Simple, yes,
far-fetching results, hell yes. I tried fiddling with it and ended up with a copy of /etc/passwd
(the Unix password file). In itself not that big of a deal, but still it’s information you
don’t want just anyone to read.
Here’s the trick to secure coding: Think. If you think about what your code does, where
the input from form fields goes, what’s done with the output, you are half way there.
The other 50% of the secure coding exercise is using Perl’s taint checking (the -t flag).
Taint checking will die() your script with an error if you are using data that is ‘contaminated’.
Contaminated means that it’s unchecked, and might (or might not) contain data that will get
you a whole lot of other results than the ones you hoped for.
Since taint checking is a rather long-winded subject, I’d like to refer everyone to their
perl documentation (those files you never read 😉 and read up on it.
Also, remember, shell commands are fun, but might cause some very serious security holes. Things
like executing shell commands using backticks or the system() call. If someone puts the
appropriate characters in that string, bad voodoo is going to come over your script. I won’t give
you detailed instructions, after all, this is not a course on hacking but an article on how
to code securely.
And so it ends, the main point here is that you should think about what your script does,
visualise it’s flow in your head, and work from there. If you have any more questions, feel
free to contact me at madcat@perlcoders.com
