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

I am doing something bad. I have a configuration file that is named via a CGI parameter. This file is config1 and I detaint it.

Now I open config1 and read another filename from it - config2. config2 I trust, because if someone has been able to edit config1 they've already breached my security. So I do this:

$index_file =~ /(.+)/;
$index_file = $1;

I realize this is kind of bad - is there a way someone can suggest to do this better? Or set my mind at ease and say there's no problem here ;P thanks
  • Comment on untainting that which needs no untainting

Replies are listed 'Best First'.
Re: untainting that which needs no untainting
by waswas-fng (Curate) on Aug 06, 2004 at 18:40 UTC
    What if it is set to /etc/passwd? Also take a look at CGI, by the use of $1 it looks like you are trying to roll your own.


    -Waswas
[reply]
Re: untainting that which needs no untainting
by etcshadow (Priest) on Aug 06, 2004 at 18:41 UTC
    Well, I'd change the regex to /(.*)/s. Just in case your $index_file name has a newline in the middle of it. I suppose that's not likely, but you asked us to put your mind at ease. 
    ------------
:Wq
Not an editor command: Wq

    [download]
[reply]
[d/l]
[select]
Re: untainting that which needs no untainting
by dave_the_m (Monsignor) on Aug 06, 2004 at 19:28 UTC
    Well, I'd do lots of checks on both filenames: make sure they aren't absolute, have no ..'s in them, or funny chars. Ie be as paranoid as possible.

    Dave.

[reply]
[d/l]
Re: untainting that which needs no untainting
by Aristotle (Chancellor) on Aug 06, 2004 at 23:55 UTC

    You don't just want to keep out crackers. You want to protect yourself from bugs and user error as well. In general, if your untainting is not ad-hoc, but relies on reusable code instead, such as by using one of the Untaint modules, it is easy to untaint variables for specific kinds of things, like "this is a number", "that's a relative filename", etc. In that case it's easy to properly taint-check everything, and that's what you should be doing.

    That said, the pattern you posted has two possible problems that might cause it to fail to match the entirety of everything you apply it to: you're using the + quantifier which requires at least one character, so the input string must not be empty; and you're not using /s, so that the dot won't match newlines.

    So as etcshadow pointed out, you want /(.*)/s instead.

    Makeshifts last the longest.

[reply]
[d/l]
Re: untainting that which needs no untainting
by graff (Chancellor) on Aug 08, 2004 at 03:22 UTC
    Now I open config1 and read another filename from it - config2. config2 I trust, because if someone has been able to edit config1 they've already breached my security.

    So in other words, if config1 gets screwed up, whether by malicious intent, or by honest ignorance, or by a simple typo, whatever consequence ensues is okay in your view?

    What's the cost of treating it the same as the CGI parameter that gives you "config1"? (You didn't say what you're doing to untaint that, but I guess we shouldn't doubt that you're doing it properly...)

    Maybe I'm wrong about this, but I would have thought that if a CGI parameter were untainted properly, such that you could derive from it a file name on the server that could be opened and read, then the data in that file should already be taint-safe (i.e. not need to be untainted).

    But if I am wrong about that, and data being read from a named file on the server is treated as tainted, I really don't see the point of handling it any differently than other tainted data. What are you saving by doing this?

[reply]

Back to Seekers of Perl Wisdom