Re: [Koha-devel] Re: FAQ: Why am I prompted to save a .pl file? was: Problems adding a biblio...

[Joe Atzberger]

On 9/12/07, Rick Welykochy <address@hidden> wrote:

> The manual entry for die suggests using Carp, which is what I
> suggested too.  Using core perl modules seems far safer ...

The "perldoc -f die" entry does not mention Carp.

Carp provides better formatting of message sent via die:

    "The Carp routines are useful in your own modules because
     they act like die() or warn(), but with a message which
     is more likely to be useful to a user of your module."

i.e. Carp is for terminating (via croak or confess)
or warning (via carp or cluck) in a "nicer way", to be
used for the benefit of CLIENTS of the software you are writing.

You are looking at Carp instead of CGI::Carp.   The latter is adapted to the task at hand (OPAC errors). 

> Why aren't you using the Carp modules or something based on them?

Carp does not provide exception catching.

But CGI::Carp can, and commonly does.

The following catches fatal errors, including "die":
  use CGI::Carp qw(fatalsToBrowser);

The following catches warnings, including "warn":
  use CGI::Carp qw(warningsToBrowser);

The messages get formatted and datestamped as appropriate for the logs and also (optionally) displayed to the browser.  I find it very useful, and it avoids the performance hit of having to defer compilation of everything to runtime evals. 

Carp does not provide the functionality I have demonstrated at

     http://praxis.com.au/demo_error.pl/showio

which intercepts an IO error, and displays detailed information to
the browser in addition to notifying the sysadmin.

The demo_error.pl example intercepts ALL errors and works for all
perl applications :)

I suspect upon examination you will agree such functionality is indeed present in CGI::Carp, with the same broad applicability.  Another difference is that CGI::Carp would allow you to, for example, toggle the browser notification at runtime, whereas the evals have to be built into the code.  

Leaving aside the question of functionality as largely settled, I want to revisit the question of security briefly.  I would suggest to MJ Ray and the rest of the list that fatalsToBrowser error messages are certainly helpful... helpful enough to constitute an increased security exposure.  Dependent on the implementation of course, a skilled observer could be able to discern:

• otherwise encapsulated file structure outside DOCROOT,
• presence and location of system executables,
• anything in $!, including STDERR from system calls,
• variable names and types, their relationship to query params, and the type of taint checking performed on them... or LACK of taint checking, etc.
  

Then it isn't much of a leap to start trying to overload a POST with something like:
> (??{$later_evaled_var="rm -f /file"})

That being said, I don't think the security issues are overriding.  The main problems would be where fatalsToBrowser was just dropped on top of system code.  Properly designed CGI would mitigate most of the additional exposure.  

I find using CGI:Carp accelerates the turnaround on bugfixing my own code, from both the log formatting and the delivery of a more sensible error message to the user (that also happens to match the logs).   In not very long, I hope to be able to contribute more directly to the OPAC codebase and help address this kind of problem.

--Joe Atzberger
INFOhio Technical Specialist
Metropolitan Educational Council