Re^3: Taint mode limitations

[chromatic]

However, I suspect that (c) would strongly encourage people to clean and untaint() their user intputs as soon as they acquire them...

Regardless of the existence or presence of taint mode, secure applications do this already.

I understand your argument (reusing capture groups for untainting was a mistake of the premature reuse of a feature), but I don't see the current situation as an onerous burden. Even without taint mode I would still write my code to perform input validation at the edges of the program, just as I handle encoding concerns at IO boundaries.

[Anonymous Monk]

I understand your argument (reusing capture groups for untainting was a mistake of the premature reuse of a feature), but I don't see the current situation as an onerous burden.

That's interesting and is getting me to wonder if I am not worrying about scenarios that don't happen in practice.

What do you make of the various situations that I outline in this page: http://www.perlmonks.org/?node_id=1002207. Are these things that typically don't happen in practice? And if so, can you explain why that is? Or maybe you don't find that checking for taintedness before every print to STDOUT, every regexp match and every call to a third party library is not onerous, and you feel confident that you never forget to do it?

BTW: I am not saying this to be sarcastic. I am more than open to the possibillity that I am imagining nightmare scenarios that don't happen in practice. I am also more than open to the possibilities that some programmers are able to think about checking for taintedness before every print, regexp match or third party library call (I'm just not one of them ;-)).

[Anonymous Monk]

Well, you're missing the obvious point that taint was designed to avoid DIRTY data from messing up system calls, and tainted data doesn't break print -- A browser/website vulnerable to XSRF is about 11 domains removed from domain of taint -- not taints job