Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re^3: Taint mode limitations

by davido (Archbishop)
on Nov 03, 2012 at 16:25 UTC ( #1002117=note: print w/ replies, xml ) Need Help??


in reply to Re^2: Taint mode limitations
in thread Taint mode limitations

Maybe I'm completely arrogant here, but it seems that taint mode is in fact counterproductive, because it lulls you into thinking that it spots all the places where you forgot to explicitly address (as in "at least think about") malicious inputs. But it doesn't, again because of its poor assumptions (a) and (b).

Within their respective problem domains, the same could be said for strict, warnings, Perl::Critic, Safe, prove, and so on. The tool is not the problem unless it's inaccurately or inadequately documented. The problem is the misunderstanding, which is hard to eliminate, because people tend not to read the documentation past the point of "getting it to work."

I think the challenge with respect to user input is one of education. With a constant deluge of new programmers in the field, the near total lack of discussion of security issues in many university CS programs, the low barrier to entry into scripting languages, and the high stakes involved that make malicious attacks profitable for the hacker, we've been fighting it for decades and will probably continue to do so. It's hard enough to get people to use the tools that are available. It's even harder to get them to take the time to understand them. There are plenty of posts on the net where the mantra is reiterated; don't cargo-cult code without understanding it. This is especially true in any type of programming where security if an issue.

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 remember an old saying that I'll paraphrase: "If you make it so easy even a fool could use it, only fools will use it."

This is a healthy discussion, and I'm glad you brought it up. I'm glad that you make the observation that taint mode isn't completely effective. The more attention the subject gets, hopefully the more people will become aware that the programmer has to assume some responsibility for educating herself on safe practices.


Dave


Comment on Re^3: Taint mode limitations
Re^4: Taint mode limitations
by alain_desilets (Beadle) on Nov 03, 2012 at 17:08 UTC
    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1002117]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (9)
As of 2014-08-20 21:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (124 votes), past polls