in reply to writing a "CGI::Taint" module

I think that most people find it easier to do their escaping strategy on the way into the database than on output.

This would suggest that it would be more useful to have a version of DBI that did taint checks on the way into the database than something which did them on the way out.

Furthermore your suggested module is not at all CGI specific. You seem to be adjusting the print function to refuse to print tainted data. But print is used for all kinds of programs. Since its functionality is not specific to CGI, I would be leery of giving it a name indicating that it was.

Replies are listed 'Best First'.
Re: Re: writing a "CGI::Taint" module
by cLive ;-) (Prior) on Jul 12, 2003 at 20:29 UTC

    My point being that this is a specific case where data is output to the browser, hence CGI. Of course, there's also the issue of templating systems, so valid point about DBI storage as well.

    Perhaps then, an extension to DBI that wouldn't let you store tainted data would be useful, along with some pre-defined methods to untaint data - eg, (1) strip all html markup, (2) strip all html markup except for specified tags (a la HTML::TagFilter), (3) escape all html markup. 

    use DBI;
use DBI::Taint;

    [download]

    Hmm, still only a germ of an idea...

    cLive ;-)

[reply]
[d/l]

      Revisit your DBI documentation. While data tainting in DBI isn't officially finalized (per the documentation), it certainly exists right now. Also, see my other post for info on preventing tainted data from going out to STDOUT.

      DBI->connect('dbi:...', ... {
    Taint => 1,
    TaintOut => 1,
    TaintIn => 1 })

      [download]
[reply]
[d/l]

In Section Meditations