| Subject: | Don't use string eval |
You use string eval to store autoloaded methods in the symbol table
automatically.
This is not only a big performance penalty as the compiler needs to be
fired up again during runtime, but it's also a security risk:
my $meth = q[;print qq/code injection\n/;];
Object::AsHash->new->$meth;
The above causes the print statement to be executed, which is harmless
in that case, but using other, possibly malicious code snippets, as hash
keys and therefor as method names, might lead to unexpected results.
Why are you using string eval?
In case you only use it to store the generated method in the symbol
table you can excange it by the following statement which uses typeglobs
and code references:
{
no strict 'refs';
*{ $key } = sub {
my $v;
...; # and so on
};
}
This has the advantage of being
- more secure
any userdefined input like the hash key/method name can't result
in invalid perl or malicious code as it can when you're putting
together the code at runtime yourself
- faster
no compiling at runtime
- easier to maintain
the syntax is checked at compile time and your editor and other
tools may use that to indicate errors. Also you get rid of quite
a lot of quoting you currently need to do.
In case you're using the string eval just to catch exceptions you might
want to consider switching to block eval instead:
eval {
your(code => $here);
};
The same reasons as above apply.
Please let me know if it would help you if I provide a patch with tests.