Programming Perl, 4th Edition

Handling Insecure Code

Taint checking is just the sort of security blanket you need if you want to catch bogus data you ought to have caught yourself, but didn’t think to catch before passing off to the system. It’s a bit like the optional warnings Perl can give you—they may not indicate a real problem, but on average the pain of dealing with the false positives is less than the pain of not dealing with the false negatives. With tainting, the latter pain is even more insistent, because using bogus data doesn’t just give the wrong answers; it can blow your system right out of the water, along with your last two years of work. (And maybe your next two, if you didn’t make good backups.) Taint mode is useful when you trust yourself to write honest code but don’t necessarily trust whoever is feeding you data not to try to trick you into doing something regrettable.

Data is one thing. It’s quite another matter when you don’t even trust the code you’re running. What if you fetch an applet off the Net and it contains a virus, a time bomb, or a Trojan horse? Taint checking is useless here because the data you’re feeding the program may be fine—it’s the code that’s untrustworthy. You’re placing yourself in the position of someone who receives a mysterious device from a stranger, with a note that says, “Just hold this to your head and pull the trigger.” Maybe you think it will dry your hair, but you might not think so for very long.

In this realm, prudence is synonymous with paranoia. What you ...