in reply to Re^3: Is the force_untaint option in HTML::Template overkill?
in thread Is the force_untaint option in HTML::Template overkill?

The link on cross-site scripting was very enlightening. The general lesson I guess is that these evil outsiders are cleverer than I am. This is making me think that I should write a module to lighten the load.

CGI::Paranoia

  • Comment on CGI::Paranoia - Re^4: Is the force_untaint option in HTML::Template overkill?

Replies are listed 'Best First'.
Re: CGI::Paranoia - Re^4: Is the force_untaint option in HTML::Template overkill?
by dsheroh (Monsignor) on Sep 14, 2008 at 16:39 UTC
    Would respect the CGI interface but would ensure that all functions in the CGI interface returned untainted values.

    I believe you have a stray "un" in there... All functions in the CGI interface should return tainted values (at least when said values are derived from an untrusted source) because only the code which ultimately uses the data is able to determine whether the data is safe or not. There's no way for this (presumably hypothetical) CGI::Paranoia module to make that determination on its own. Even an application-specified untaint handler can't readily resolve this (unless it's specifiable on a call-by-call basis, at which point you may as well just make the untainting call normally anyhow), as data which is safe in one section of the application may not be safe in another.

      My specification included (and requires) registering untaint handling callbacks with the CGI::Paranoia object on creation. This is the application's opportunity to say what is tainted and what not.

      Also in the case of functuons like self_url(), the application is not well placed to say what is tainted. The application is well placed to test each parameter for taint, but to test the result of self_url() for taint it has to parse an http address. The CGI module is better placed to do this albeit deferring to the application when it is reduced down to individual parameters.

      I clearly need to knock up a simple example, which I will endeavour to do before someone else posts.

      Update

      I have an example. First of all the template file "test.tmpl".
      <html> <head><title>test.tmpl</title></head> <body> <TMPL_VAR NAME="form"> <submit/> </form> </body> </html>
      Now the test script: test.pl.
      #!/usr/bin/perl -wT use HTML::Template; use CGI; my $q = CGI->new(); my $template = HTML::Template->new(filename => './test.tmpl',force_unt +aint=>1); $template->param(form=>$q->start_form()); print $template->output();
      The output is as follows:
      $> perl -T test.pl <html> <head><title>test.tmpl</title></head> <body> <form method="post" action="http://localhost" enctype="multipart/f +orm-data"> <submit/> </form> </body> </html> $> perl -T test.pl blah=1 HTML::Template->output() : tainted value with 'force_untaint' option a +t test.pl line 7
      I think the CGI module is better placed to produce an untainted start_form() value then the application.
        I think the CGI module is better placed to produce an untainted start_form() value then the application.
        No. You're severely confused about taint. Taint protects you from doing stupid things with system calls, like
        my $stupid = $q->param('unsafe');#unsafe=rm -rf/ $stupid = $q->start_form; system $stupid; # kill me now
        HTML::Template leverages taint to protect you from XSS.