Tools can never guarantee security. They can simply encourage good behavior and good practices. You're correct though; the tools can lull one into a false sense of security. But making them more effective without taking options away from the programmer is quite difficult. There's a fine line between encouraging good behavior, and hampering creativity.
I agree. No tool safeguard can garantee 100% safety, and the safer you try to make it, the more you may hamper the programmer's creativity.
I guess the point I am trying to make is that taint mode doesn't seem to be hitting the right sweet spot on that continuum. For example, I don't see how forcing programmers to explicity untaint a variable by calling a method called say, untaint(), would take options from them. Yet, it would sure be much safer than assuming that a regexp group matched from a tainted variable is untainted.
Similarly, I don't see how reporting all tainted variables that have not been explicitly untaint()ed by the end of the process hamper creativity. And that too would be safer than assuming that a tainted variable doesn't have to be untainted unless it's going to be used in a context that we know to be dangerous.
It seems to me that the current taint mode is really optimized for situations where you are using a large code base that was developed without security in mind. In that situation, what I proposed earlier would probably fire a lot of alarms. Most of those might be false positive where either (a) the tainted variable IS being cleaned up through the use of a regexp match or (b) the tainted variable is never actually being used in a dangerous context. My proposed taint mode would force you to explicitly add a call to untaint() on all those false positive tainted variables, and this may not be palatable for some developers.
In a situation like this, the current taint mode implementation may be more palatable to some developers, because it automatically deduces that many of those user inputs are in fact OK. But it also lets a lot of false negatives through. For examples, inputs that either have been derived from a tainted variable trhough a group regexp match, but where this regexp match was never intended to clean security threats. Or inputs that are being used in situations that, while not recognized as dangerous by Perl, are indeed dangerous (ex: writing JS code to STDOUT).
Personally, when dealing with security, I would rather have to deal with lots of false positives and manually label them as being OK, than have lots of false negatives slip through the cracks. I understand that not everyone may have that bias, so maybe the ideal would be for taint mode to be configurable. Those who are bothered by false negatives can choose lenient options, while those who like me are paranoid and want to let as few false negatives through, can choose a more restrictive option.
I'm surprised that this is not a possibility.
In reply to Re^4: Taint mode limitations
by alain_desilets
in thread Taint mode limitations
by alain_desilets
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |