G'day Raymond,
Raymond Wan wrote:
> server and B is a "live" server, then if I write code with tainting on
> A, test it, and ensure everything works with no errors...I can then move
> it to another server as B *without* taint enabled, and I would have got
> most of the important benefits of tainting. Is this statement true?
You get *some* of the advantages of taint for the code execution paths which
you have tested. If you've been taking untrusted data and passing it to a
dangerous function without checking it, and you catch this using taint, then
that's one less potential hole in your program. This is good.
Likewise, using taint mode rapidly gets you into the habit of validating
your input for correctness soon after getting it, and this is an excellent
habit to have. That's good too.
However if you turn off taint mode for production, and an attacker discovers
a way of injecting harmful data which you *haven't* tested, then you've
still got problems. Leaving taint mode on will give Perl one last chance to
catch untrusted data being used unexpectedly.
As an example, let's pretend your code includes:
<%args>
$file
</%args>
% open(my $fh, $file) or die "...";
% while (<$fh>) {
<!-- Do things with file contents -->
% }
Here we're using the two-argument version of open, we have specified an
access mode (read/write/append), and we haven't validated our input. If
we're opening the file for reading, taint doesn't get involved, and
everything seems fine. If we're only testing this with good filenames, we
don't even realise there's a problem.
However there *is* a problem, and it's nasty. If our input is the string
'>/etc/passwd', then we'll open an important file and overwrite it (if we
have permission), and that's bad. If our input file is 'echo pwned|' then
we've just executed some code given to us by the attacker. That code could
be *very* bad indeed[1].
Taint will catch these attempts to subvert our use of open(), but only if
it's turned on. With taint disabled, everything may seem fine during
testing, even though we have holes that taint could catch during production.
This means that the value of "taint only during testing" is directly
proportional to the quality of your testing. It's still enormously better
than not using taint at all, but just don't let it lull you into a false
sense of security.
So please, use taint mode on your test machine, it's a really good idea, and
it will improve your code. But if you get the chance, try to use it on your
production machine as well. ;)
Cheerio,
Paul
[1] Ideally one uses the three-argument version of open, which is less
vulnerable to these sorts of attacks.
--
Paul Fenwick <[EMAIL PROTECTED]> | http://perltraining.com.au/
Director of Training | Ph: +61 3 9354 6001
Perl Training Australia | Fax: +61 3 9354 2681
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Mason-users mailing list
Mason-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mason-users
