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

I am very happy with the answers, but I will offer a clarification just in case this produces a different answer - or at least a deeper answer. I am not casting doubt on the -T argument in perl. I absolutely see the point of that. I'll explain the example that is bugging me at the moment. In the form element I need to post back a $my_cgi->start_form() into the HTML::Template variable <TMPL_VAR NAME="form">. In HTML::Template I am using that module's force_untaint option and it is complaining about taint. Given that when the submit button is pressed, the arguments passed to the CGI script will be checked for taint, why do I need to check the HTML shown to the user for taint?

Replies are listed 'Best First'.
Re^3: Is the force_untaint option in HTML::Template overkill?
by Anonymous Monk on Sep 14, 2008 at 09:50 UTC
    why do I need to check the HTML shown to the user for taint?
    Same reason, security. From the docs:
    force_untaint - if set to 1 the module will not allow you to set unescaped parameters with tainted values. If set to 2 you will have to untaint all parameters, including ones with the escape attribute. This option makes sure you untaint everything so you don't accidentally introduce e.g. cross-site-scripting (CSS) vulnerabilities. Requires taint mode. Defaults to 0.
      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

      • By default would create and inherit from a CGI::Safe object.
      • By default would create and stash a CGI::Untaint object.
      • Would respect the CGI interface but would ensure that all functions in the CGI interface returned untainted values. Examples: param(), self_url(), start_form()
      • The constructor would accept an optional CGI-like object to inherit from and an optional CGI::Untaint object to stash.
      • The constructor would also accept an optional hash map (param() => CGI::Untaint handler) and an optional parameter specifying the INCLUDE_PATH paramater of the CGI::Untaint object.
      • The constructor would require a default untaint handler that would be used in all other cases.
        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.