For a demonstration of what they're talking about, say you have this code:
Code:
my $eqn = "2 + 2 * 4";
my $result = eval($eqn);
print "$eqn = $result\n";
# "2 + 2 * 4 = 10"
If $eqn is defined by the user (e.g. through a web form if used as a web calculator), there's nothing stopping them from doing this:
Code:
$eqn = "unlink (glob('C:/Windows'))"
Which, if on a Win32 machine, would delete files in the Windows folder.
So if you put a variable that is user-defineable into an eval statement, you run the risk of that user telling Perl to run *ANY* command Perl can do, which can seriously screw you over.
Here's a code for a calculator I wrote once which used eval, but didn't allow hacking like this:
Code:
if ($eqn =~ /[^0-9\+\-\/\*]/) {
print "Invalid operators: use only numbers, +, -, /, or *\n";
}
else {
print "$eqn = " . eval($eqn) . "\n";
}
That way, if they try anything funny, it won't eval $eqn. Also note that I allowed the forward slash / but not the back slash \, as the \ has special significance in Perl and can be used to execute code using escape codes (eg "\049" type of strings can be interpreted into text, so commands like "unlink" can be spelled out using \'s and numbers).
So, be sure to be as strict as possible on any variables being sent into eval.