shenme has asked for the wisdom of the Perl Monks concerning the following question:

Upon realizing that I had _not_ had taint mode on for awhile in a CGI app I was developing, I turned it back on and everything blew up. (as advertised, after all) But as I resolved issues I would see data items pop up as tainted that I 'knew' were untainted when I created them.

As I processed CGI forms I would validate and untaint data items, and then accumulate them in my session hash. Later in other CGI invocations I'd try to use those bits of information and blow up with taint errors.

After putting in some debug displays I realized I was simply hitting the taint mode restriction on input data - anything read from a data file is tainted. (My CGI::Session options were 'driver:File;serializer:Storable' and so session data is stored in files)

I'm really puzzled as I can't find previous mentions of this issue, and can't believe the combination of CGI::Session session files and taint mode hasn't been done. I mean, gosh, doesn't everybody use taint mode?

Has anybody dealt with this problem? That is, somehow untainting the session data string read from a file (or database record for that matter), before CGI::Session then uses thaw() to recreate the session hash?

  • Comment on CGI::Session, taint mode, and tainted session file input data

Replies are listed 'Best First'.
Re: CGI::Session, taint mode, and tainted session file input data
by emazep (Priest) on Apr 25, 2005 at 09:51 UTC
    That is, somehow untainting the session data string read from a file (or database record for that matter), before CGI::Session then uses thaw() to recreate the session hash?

    If you get your session data from a db server (via DBI) you don't need to untaint them (unless you've set the TaintOut or Taint DBI attributes and you run your program in taint mode -- both these attributes default to off, even if perl is in taint mode).
    Therefore switching from the file backend to a DBI backend (natively supported by CGI::Session for SQLite, MySQL and PostgreSQL) for your session data, can be a workaround (provided that you can trust your db of course).

    Ciao,
    Emanuele.

[reply]
Re: CGI::Session, taint mode, and tainted session file input data
by tlm (Prior) on Apr 25, 2005 at 02:19 UTC

    Couldn't you untaint the string with something like 

    $tainted =~ /^(.*)$/;
my $untainted = $1;

    [download]
    ??

    Mind you, I'm not necessarily proposing this; I'm just trying to figure out whether you already tried this and it did not appease taint, or it did, but you want some better approach.

    the lowliest monk

[reply]
[d/l]
      That would be the way to do it, with the realization that I'm trusting that no one has diddled with the session data file, presumably because I've taken other safeguards to prevent that from happening.

      No the problem is that CGI::Session is managing both the session data retrieval step (using CGI::Session::File from the 'driver:File' option) and executing the de-serialization step (using Storable because of the 'serializer:Storable' option). There doesn't seem to be a good way to insert untainting code between those two steps.

      Or, it seems that way. But since someone _must_ have figured this out before, I'm hoping... Meanwhile I've turned taint mode off again (this time on purpose) but know that I have to turn it back on real-soon-now.

      Also, I checked the beta 4.x versions of CGI::Session, and while that code is 'better' in that the retrieve() call doesn't directly call the thaw() method, the C::S code still doesn't seem to make it any easier to add code between the two calls.

[reply]

        Could you subclass Storable, and override the deserialization methods so that detainting is done before calling the SUPER method? (Of course, this assumes that you can specify your subclass as an alternative serializer module.)

        the lowliest monk

[reply]

Back to Seekers of Perl Wisdom