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::Carp qw(fatalsToBrowser);
my $cgi = new CGI;
my $p_type = $cgi->param('p_type');
die "\$someobject->make_$p_type failed: $@";
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
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