Re: [Cgi-session-user] CGI::Session driver:File - tainted session data?

[Mark S. <ma...@su...>]

On Sat, Sep 03, 2005 at 11:52:50PM -0500, Thomas L. Shinnick wrote:

> I am having problems with tainted session data, using CGI::Session 3.95 and "driver:File".  I am putting together another session module for Catalyst, and want to verify that it works under 3.95 before installing 4.0x.
> 
> Using "driver:MySQL" I have no problems.  After switching the DSN to "driver:File" I blow up the first time I try to use a value from retrieved session data in a 'sensitive' way.  Note that this is the same code - I'm only changing the DSN. 
> 
> So I'm left to wonder:
>   - is session data from 3.95 File always tainted?
>   - is session data from 3.95 MySQL _not_ tainted?

For definitive answer, I would check the source of those driver modules. 

>   - and will 4.0x act any differently?

Generally, if it does act differently it's a bug, unless something
managed to be badly broken all along. 

>   - is there a 'nice' way to untaint a whole session data ref?

My opinion is "No". From 'perldoc perlsec': 

"don't just blindly untaint anything, or you defeat the entire mechanism".

My approach is to not use "-T", and handle data that would be tainted
carefully. Too often I see solutions that /do/ blindly untaint things,
defeating the point of it. 

Even the current CGI::Session source for the default driver does this:

 # blindly untaint...
 my ($safe_string) = $string =~ m/^(.*)$/s;

It allows you to say "look, I'm using taint mode!", but it not actually
performing any checks on the data before considering it safe.

Now at this point, I imagine we would break backwards compatibility if
this behavior changed. 

    Mark

-- 
http://mark.stosberg.com/