From the perlsec manpage (read it!):

Laundering data using regular expression [sic] is the only 
mechanism for untainting dirty data
[download]

(it goes on to qualify this statement, but the mechanism that provides the exception to this rule goes deeper than we need to)

And tr/// doesn't really fall under 'regular expressions'. You have to use Perl's facility for capturing parts of pattern matches, i.e. you need to capture only those bits of data that you want using parentheses within regular expressions.

PERL DOES NOT KNOW WHICH DATA IS SAFE, it only knows when to no longer mark the data as tainted. So the programmer has to know what sort of input is safe, and what sort of input is not. What is 'dangerous' ? Well, shell metacharacters, usually. So this might be a start (adapted from Programming Perl, 2nd ed. p. 358):

sub untaint {
    my $data = shift;
    if ($data =~ /^([-\@\w.]+)$/) {
        $data = $1;
        return $data;
    } else {
        die "somebody tried something nasty, I think: '$data' contains
+ questionable characters.\n";
    }
}
[download]

The regex tests the string to see whether it contains anything other than @, -, a dot, or a word character. If it doesn't, it untaints it (by setting the data to the text captured within the parens in the regular expression), and will die with a warning if there's something not good with it. Depending on your needs, you could do various things, of course; you'll need to be handy with regular expressions, though!

HTH

Philosophy can be made out of anything. Or less -- Jerry A. Fodor

There's one small caveat with your code. If you are using CGI::Carp _and_ malicious data fails, the data will be printed out back to the browser, data, which could have been construed just to be sent back to the browser (for example, the Slashdot-Cookie-Stealer worked that way, by giving you an URL that was like http://www.slashdot.org/non-existing-directory/<SCRIPT>... evil JavaScript ... , which was then printed out by Slashdot back to the browser, and then run in the browser.

My strategy would be to just log taint-failed data into a file, as you never know exactly how that data got to your machine. Of course, maybe using HTML::Entities could prevent such misuse, as the text will then come back literally instead of interpretable ...

Good point. I just want to mention that one shouldn't be echoing such messages back to the browser in a production environment. i.e. turn this off when you go live with it:

use CGI::Carp qw(fatalsToBrowser);
[download]

the likes of which are required for this to be a problem.

Philosophy can be made out of anything. Or less -- Jerry A. Fodor

You usually untaint by matching "nice" stuff and using $1:

if(  $temp =~ m#([-\w./]*)#  ) {
# or if(  $temp =~ m#^(/?(?:[-\w.]+/)*[-\w.]*)$#  ) {
    $temp= $1;
} else {
    die "Invalid input...";
}
[download]

The die may not be the proper way to fail, depending on your environment.

I'm using CGI for the main data handling, I was unable to find a way with CGI to extract the commandline like I needed. I have printed out the CGI information and it seems to be more for creating forms rather then processings them, at leat the way I need them to be processed.

IF 
	you're getting info off the command line
THEN
	you probably want one of the Getopt modules

(Getopt::Std or Getopt::Long).

And CGI is DEFINITELY built for processing input from HTML forms -- in fact, it's very powerful that way (hint: check out the documentation for param in the CGI manpage!).

Philosophy can be made out of anything. Or less -- Jerry A. Fodor

Cheers,
KM