The problem is not because a CGI script is displaying SSI. The problem is when a CGI script has made an HTML file that then is processed, with SSI enabled (via mod_include instead of mod_cgi). That's where it'll get ya.

-- Randal L. Schwartz, Perl hacker

First of all the CGI.pm docs are particularly bad on this point. They do not even die on failed opens. In addition when done right you should be sure to address issues such as race conditions and not trusting user input for filenames.

And speaking of not trusting user input, the following Phrack article should give some food for thought on how easy it is to go very, very wrong. And note that simple taint checking may or may not help, often people just pass virtually anything through rather than thinking about why the check is there and what can happen.

Among other things it will show you why security concious programmers are likely to explicitly:

open (FOO, "<$foo") or die "Cannot read $foo: $!";
[download]

AgentM Systems or Nasca Enterprises is not responsible for the comments made by AgentM- anywhere.

In fact, now that I'm rereading the source for that SSI information, it specifically lists this as a problem with scripts that create static HTML pages.

tilly: thanks for the link. A hardcopy is sitting on my desk now. Amusingly enough, that comment about "they do not even die on failed opens" is particularly frustrating. Two days ago, I went down to an technical bookstore and scanned about 4 books dealing with Perl and CGI. Not one of those books were consistently checking return codes on file opens. That, of course, is in addition to all of the typical problem: no strict, -w, or -T. And these people are touting themselves as professionals!!! Some of them clearly know Perl better than I (which isn't hard to believe), so it was dismaying to see such dangerous programs being listed.

It's a sad, sad, world.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just go the the link and check out our stats.

When I first saw that I was shocked and dismayed.

Then I thought about it.

The problem is fundamental. One of the great shortcomings of a CGI environment is that there is not a great standardized error reporting scheme. If you die, that only gives an informative message if you have CGI::Carp or some equivalent installed. Is it the place of CGI.pm to discuss where to find your error logs? Another solution is centralized error reporting, but that is a site decision.

Without a standardized way to display meaningful errors, there is no good way to trap them. And CGI.pm cannot assume a good standardized way to display them. Hence there is a catch-22.

What I think is a good solution is to somewhere have a good online tutorial and then have CGI.pm point out the issue and direct people to that tutorial. Said tutorial will need to discuss options for error reporting and decide on one very early. Then use it consistently.

The books, OTOH, have no excuse. A book is a format which (like a tutorial) can cover error reporting early, settle on an option, then use it consistently in the examples.

Almost any book with both "PERL" and "CGI" in the titles (yes, capitalization is significant here) is worthless. Or if they call it "Perl 5". Instant clue of lack of clues.

-- Randal L. Schwartz, Perl hacker