[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 <rick at praxis.com.au> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20070912/47cced29/attachment-0002.htm>