in reply to CGI::Paranoia - Re^4: Is the force_untaint option in HTML::Template overkill?
in thread Is the force_untaint option in HTML::Template overkill?

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.

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

Replies are listed 'Best First'.
Re^2: CGI::Paranoia - Re^4: Is the force_untaint option in HTML::Template overkill?
by SilasTheMonk (Chaplain) on Sep 14, 2008 at 17:03 UTC

    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.