Yesterday, one of my students in a Learning Perl class at $VERY_LARGE_COMPANY brought in some production code that she had inherited and wanted me to help decipher.

My jaw hit the floor when I saw:

use CGI;
use CGI::Carp qw(fatalsToBrowser);
my $cgi = new CGI;
...
my $p_type = $cgi->param('p_type');
...
eval "\$someobject->make_$p_type(\$some,\@args)";
die "\$someobject->make_$p_type failed: $@";
...
[download]

In other words, not only was unchecked data from a form field (presumably from a pop-up menu or radio button) being used directly in an eval, but quite helpfully, the syntax errors were being sent back to the browser to help you refine your breakin! (And I looked hard for some sort of screening or vetting of the $p_type value, and there was none.)

And this is live code, in production, on a customer-facing website that gets thousands of hits a minute.

And thanks to cutbacks, the owner of this code is someone who now has just barely taken her first Perl instruction from me, and has changes to make to the site within the next two weeks; thus she doesn't have time to take my PROM class, but must change code riddled with objects and references and modules, and as you see here, security holes the size of Kansas.

Is there really that lack of clues out there? I don't know whether to be more scared or saddened.

-- Randal L. Schwartz, Perl hacker