En Mon, 05 Feb 2007 23:01:51 -0300, Ben Finney <[EMAIL PROTECTED]> escribió:
> "Gabriel Genellina" <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list