Taint (like in Perl) as a Python module: taint.py

[Gabriel Genellina]

En Mon, 05 Feb 2007 23:01:51 -0300, Ben Finney  
<bignose+hates-spam at benfinney.id.au> escribió:

> "Gabriel Genellina" <gagsl-py at yahoo.com.ar> writes:
>
>> I suppose you don't intend to publish the SafeString class - but if
>> anyone can get a SafeString instance in any way or another, he can
>> convert *anything* into a SafeString trivially.
>
> The point (in Perl) of detecting taint isn't to prevent a programmer
> from deliberately removing the taint. It's to help the programmer find
> places in the code where taint accidentally remains.

I'm not convinced at all of the usefulness of tainting.
How do you "untaint" a string? By checking some conditions?
Let's say, you validate and untaint a string, regarding it's future usage  
on a command line, so you assume it's safe to use on os.system calls - but  
perhaps it still contains a sql injection trap (and being untainted you  
use it anyway!).
Tainting may be useful for a short lived string, one that is used on the  
*same* process as it was created. And in this case, unit testing may be a  
good way to validate the string usage along the program.
But if you store input text on a database or configuration file (username,  
password, address...) it may get used again by *another* process, maybe a  
*different* program, even months later. What to do? Validate all input for  
any possible type of unsafe usage before storing them in the database, so  
it is untainted? Maybe... but I'd say it's better to ensure things are  
*done* *safely* instead of trusting a flag. (Uhmm, perhaps it's like "have  
safe sex; use a condom" instead of "require an HIV certificate")

That is:
- for sql injection, use parametrized queries, don't build SQL statements  
by hand.
- for html output, use any safe template engine, always quoting inputs.
- for os.system and similar, validate the command line and arguments right  
before being executed.
and so on.

-- 
Gabriel Genellina