Mastering Perl, 2nd Edition

Chapter 2. Secure Programming Techniques

I can’t control how people run my programs or what input they give them, and given the chance, they’ll do everything I don’t expect. This can be a problem when my program tries to pass on that input to other programs. When I let just anyone run my programs, as I do with web applications, I have to be especially careful. Perl comes with features to help me protect myself against unchecked input, but they only work if I use them, and use them wisely.

Bad Data Can Ruin Your Day

If I don’t pay attention to the data I pass to functions that interact with the operating system, I can get myself in trouble. Take this innocuous-looking line of code that opens a file:

open my $fh, $file or die "Could not open [$file]: $!";

That looks harmless, so where’s the problem? As with most problems, the harm comes in a combination of things. What is in $file and from where did its value come? In real-life code reviews, I’ve seen people do such things as using elements of @ARGV or an environment variable, neither of which I can control as the programmer:

my $file = $ARGV[0];

# OR ===
my $file = $ENV{FOO_CONFIG};

How can that cause problems? Look at the documentation for open. Have you ever read all of the 400-plus lines in its entry in perlfunc, or its own manual, perlopentut? There are so many ways to open resources in Perl that it has its own documentation page! Several of those ways involve opening a pipe to another program:

open my $fh, "wc -l *.pod |"; open my ...