To taint or not to taint?

chromatic recently tweeted the question:

"Should Modern::Perl enable taint mode? (If so... hm, how do I do it?)"

...which surprised me, as I tend not to use taint mode.

"Yes, yes, taint mode is crucial. There's rarely a reason NOT to use it."

...which surprised me even more.

I tried using taint mode throughout my application at one stage, but found myself naively untainting paths with

    ($path) = ($path=~/(.+)/)
[download]

which kinda defeats the purpose. Almost always, I found that the stuff I was untainting would have required root access to mess with anyway, and so I gave up on taint mode. The places where exploits were possible, I added relevant code to deal with those particular situations, and all data coming from the user gets validated.

Of course, I may have missed some situations. Maybe I'm being naive. But is enabling taint mode by default the answer to that? Doesn't it mean that, for most people, their code will just fill up with:

    $path = untaint($path)
[download]

What do you think? To taint or not to taint?

Clint

Comment on To taint or not to taint? Select or Download Code

Replies are listed 'Best First'.
Re: To taint or not to taint? by moritz (Cardinal) on Mar 19, 2009 at 13:39 UTC
As always "it depends". When I write short do-one-task-once scripts I don't bother with tainting. When I write CGI scripts I'm paranoid and enable taint checking, and it's not much of a hassle since my applications typically only talk to the database. If I have to call external programs from CGI scripts my paranoia is even bigger, and I verify all parameter from the outside anyway (with regexes and white listing hashes), so it doesn't cause me any trouble. In fact two years ago I enabled taint checking for a collection of CGI scripts, and needed only one minor modification. So my answer is "yes, where appropriate".	[reply]
Re: To taint or not to taint? by tilly (Archbishop) on Mar 19, 2009 at 15:25 UTC
Do you trust your users? If not, then does what you're doing lead to any potential risks at all? If so, then do you consider your code perfect? If not then why would you give up a very cheap reminder that could catch an accidental severe mistake? My answer to the first question generally depends on whether my programs are facing the general internet or are internal to whoever I am working for. I tend to be a little paranoid in my answer to the second. The answers to the last two are that my code is not perfect, and I love cheap reminders that catch real mistakes. I therefore tend to use taint mode exactly when my code is facing the general internet.	[reply]
Re^2: To taint or not to taint? by clinton (Priest) on Mar 19, 2009 at 15:34 UTC
For data coming from users, yes, absolutely agree. For internal data, eg paths from your config files which are readable only by root, would you still want this enabled? Would you do any real checks on these, or just untaint them blindly?	[reply]
Re^3: To taint or not to taint? by tilly (Archbishop) on Mar 19, 2009 at 15:40 UTC
The point of taint checking is to make the programmer decide what is risky. Obviously the config file that is that protected is safe, and so blindly untainting it is reasonable. That is the cost of the double-check that the checks I care about on my users really are being done as I think they are.	[reply]
Re^4: To taint or not to taint? by clinton (Priest) on Mar 19, 2009 at 15:44 UTC
Re^5: To taint or not to taint? by tilly (Archbishop) on Mar 19, 2009 at 15:46 UTC
Re: To taint or not to taint? by JavaFan (Canon) on Mar 19, 2009 at 21:18 UTC
If your world is limited, and almost all you do is being a web monkey, by all means, drone yourself to always use taint. I only use taint if my program has to potential to do something the caller isn't able to - and if the caller is potentially hostile. But I write a large numbers of programs that run under the same privileges the user already has. I think one should always think whether you should use taint mode or not. And use it when appropriate. Neither "always use taint" nor "never use taint" appeals to me.	[reply]
Re: To taint or not to taint? by SFLEX (Chaplain) on Mar 21, 2009 at 11:48 UTC
I guess the answer is use Taint if you don't know why and don't use Taint if you know. Taint inst only for Perl, you can turn on taint for back-ends also. I find that most the time taint wants to error on root paths or things the user can never touch. This code can save you a few lines, it untaint's Environment paths. `# Clean up the environment. delete @ENV{qw(IFS CDPATH ENV BASH_ENV)};` [download] Spiel auf Hündinnen.	[reply] [d/l]
Re: To taint or not to taint? by ELISHEVA (Prior) on Mar 22, 2009 at 06:18 UTC
I like to write code that works under taint because it increases the number of contexts where my code can be used. You may already be aware of this, but one can significantly reduce the number of pointless taint complaints simply by setting `$ENV{PATH}=''; $ENV{CDPATH}='';` or other known (untainted/detainted) value. This applies to a few other variables, like IFS, as well. See perlsec for details. Best, beth	[reply] [d/l]
Re: To taint or not to taint? by DeadPoet (Scribe) on Mar 22, 2009 at 00:57 UTC
In a nutshell, Taint Mode is a collection of specific restrictions in Perl that collectively help you to write safer scripts by forcing you to think more carefully about how your script uses information. Specifically, it will prevent you from using or relying on data that was provided from outside the script within any action that will in turn affect something else outside of your script--unless you take specific steps to "clean" that data, first. Have a look at "Introduction to Perl's Taint Mode" at http://www.webreference.com/programming/perl/taint/ for a better understanding.	[reply]


We don't bite newbies here... much
	PerlMonks