andye has asked for the wisdom of the Perl Monks concerning the following question:

Honest Monks,

Please aid me in my untainted plight. I am trapped inside a piece of middleware, which embeds my Perl in HTML.

This means I can't do #!/usr/bin/perl -T
- yet my Perl takes variables from perfidious web users!

How can I switch on taint mode without using -T?

This node answers not my question (alas), and the Wise Dromedary remains silent (Chapter 23 of it does, anyway). As do the Fabled Oracles and the Secondary Sources.

I could taint my data using Taint.pm, but will this have any effect if I'm not in taint mode? Anyway, input I remember to taint will be input I remember to validate.

I could pass control to another script which was in taint mode, but that seems like overkill (and might be tricky with the middleware).

Any ideas?
If it's not possible, any alternatives?

Cheers,
andy.
(New to Perl, apologies if this is an obvious question)

Replies are listed 'Best First'.
(Ovid) Re: A Quest for Taint
by Ovid (Cardinal) on Dec 12, 2000 at 23:34 UTC
    Unfortunately, the Perl executable must be started with taint mode enabled. That means you're going to have to be ultra careful. Taint will not be terribly useful here as you can't use it to taint data unless taint checking is already enabled.

    If you can pass control to the other script which is in taint mode, that might be an idea, but it's going to be very slow.

    What I try to do in a situation like this is I group all of the scalars that should normally be tainted close to the top of the program and I attempt (if possible), to "untaint" them there. Often, if taint checks are enabled, untainting is scattered throughout the program. If taint checks are not enabled, it's much tougher to easily determine where you want to untaint data. By grouping this data -- and liberally commenting so others understand why it's being done -- you can create a "red flag" for programmers that follow.

    I, for one, would KILL to be able to enable taint checking "on the fly," but I suspect that it would not be a trivial task to accomplish.

    Cheers,
    Ovid

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[reply]

      I would think undef-ing all remaining tainted variables once you're done untainting would add a little more security, as it would prevent re-using them by mistake.

[reply]
      I, for one, would KILL to be able to enable taint checking "on the fly," but I suspect that it would not be a trivial task to accomplish.

      Does anyone know if there was an RFC for this for Perl 6? I've seen it come up a few times here, which means need for it is not just an isolated incident.

      =Blue
      ...you might be eaten by a grue...

[reply]

        This is more than just something that would be 'nice' to have. I'm working hard to get perl accepted as a approved development language where I work, and insisting on taint mode is a big key on selling perl security.

        We are a large corporation with tons of beaurocratic steps at every phase of development, staging, and production. We have one brave development group that's pushing forward with a huge perl dependant application that's just hit a huge problem with taint mode.

        The application is actually part of numerous enviornments so the paths to the libraries change with each execution depending upon $ENV{USR_LOCAL_LIB_PATH}. With no way to untaint the $ENV{USR_LOCAL_LIB_PATH} prior to execution time there is no way to update the @INC at compile time.

        The only way I can see around this is to establish separate perl binaries/libraries for each enviornment... not an easy thing to do with separate sysadmin, security, and development beaurocracies all with hands mucking up the machinery of progress.

        I don't suppose anyone see's another way around this? (Hardcoding the lib paths is NOT an option.)

        coreolyn Duct tape devotee.
        -- That's OO perl, NOT uh-oh perl !-)

[reply]
Re: A Quest for Taint
by repson (Chaplain) on Dec 13, 2000 at 09:11 UTC
    One way you could do it could possibly be to develop/transfer the code in a normal perl program, then if nothing you are doing sets off taint, warnings and strict you can assume that your code is safe and run it in the future without the checks (as long as you change nothing significant).

    So what I'm trying to say is that you don't need to always run under taint if you can verify your code or dangerous parts of it under taint.

[reply]

Back to Seekers of Perl Wisdom