ch23_01.htm

编程珍珠,里面很多好用的代码,大家可以参考学习呵呵,

doing when you use them.</p>

<p>
<a name="INDEX-3982"></a>
Sometimes, though, you can't tell how many arguments you're passing.
If you supply these functions with an array<a href="#FOOTNOTE-2">[2]</a> that contains just
one element, then it's just as though you passed one string in the
first place, so the shell might be used.  The solution is to pass an
explicit path in the indirect-object slot:
<blockquote>
<pre class="programlisting">system @args;                 # Won't call the shell unless @args == 1.
system { $args[0] } @args;    # Bypasses shell even with one-argument list.</pre>
</blockquote>
</p>
<blockquote class="footnote">

<a name="FOOTNOTE-2"></a>
<p>[2]Or a
function that produces a list.</p>

</blockquote>


<h3 class="sect2">23.1.1. Detecting and Laundering Tainted Data</h3>

<a name="INDEX-3983"></a><a name="INDEX-3984"></a><a name="INDEX-3985"></a><a name="INDEX-3986"></a>
<p>To test whether a scalar variable contains tainted data, you can use
the following <tt class="literal">is_tainted</tt> function.  It makes use of
the fact that <tt class="literal">eval</tt><em class="replaceable">STRING</em> raises an exception if you try to
compile tainted data.  It doesn't matter that the
<tt class="literal">$nada</tt> variable used in the expression to compile
will always be empty; it will still be tainted if
<tt class="literal">$arg</tt> is tainted.  The outer <tt class="literal">eval</tt><em class="replaceable">BLOCK</em> isn't doing any compilation.  It's
just there to catch the exception raised if the inner
<tt class="literal">eval</tt> is given tainted data.  Since the
<tt class="literal">$@</tt> variable is guaranteed to be nonempty after each
<tt class="literal">eval</tt> if an exception was raised and empty
otherwise, we return the result of testing whether its length was
zero:
<blockquote>
<pre class="programlisting">sub is_tainted {
    my $arg = shift;
    my $nada = substr($arg, 0, 0);  # zero-length
    local $@;  # preserve caller's version
    eval { eval "# $nada" };
    return length($@) != 0;
}</pre>
</blockquote>

But testing for taintedness only gets you so far.  Usually you know
perfectly well which variables contain tainted data--you just have to
clear the data's taintedness.  The only official way to bypass the
tainting mechanism is by referencing submatches returned by an earlier
regular expression match.<a href="#FOOTNOTE-3">[3]</a> When you write a pattern that contains
capturing parentheses, you can access the captured substrings through
match variables like <tt class="literal">$1</tt>, <tt class="literal">$2</tt>, and
<tt class="literal">$+</tt>, or by evaluating the pattern in list
context. Either way, the presumption is that you knew what you were
doing when you wrote the pattern and wrote it to weed out anything
dangerous.  So you need to give it some real thought--never blindly
untaint, or else you defeat the entire mechanism.</p>
<blockquote class="footnote">

<a name="FOOTNOTE-3"></a>
<p>[3]An unofficial way is by
storing the tainted string as the key to a hash and fetching back that
key.  Because keys aren't really full SVs (internal name scalar
values), they don't carry the taint property.  This behavior may be
changed someday, so don't rely on it.  Be careful when handling keys,
lest you unintentionally untaint your data and do something unsafe
with them.</p>

</blockquote>

<p>It's better to verify that the variable contains only good characters
than to check whether it contains any bad characters.  That's because
it's far too easy to miss bad characters that you never thought of.
For example, here's a test to make sure <tt class="literal">$string</tt>
contains nothing but "word" characters (alphabetics, numerics, and
underscores), hyphens, at signs, and dots:
<blockquote>
<pre class="programlisting">if ($string =~ /^([-\@\w.]+)$/) {
    $string = $1;                     # $string now untainted.
}
else {
    die "Bad data in $string";        # Log this somewhere.
}</pre>
</blockquote>
<a name="INDEX-3987"></a>
</p>

<p>This renders <tt class="literal">$string</tt> fairly secure to use later in
an external command, since <tt class="literal">/\w+/</tt> doesn't normally
match shell metacharacters, nor are those other characters going to
mean anything special to the shell.<a href="#FOOTNOTE-4">[4]</a> Had we used <tt class="literal">/(.+)/s</tt>
instead, it would have been unsafe because that pattern lets
everything through.  But Perl doesn't check for that.  When
untainting, be exceedingly careful with your patterns.  Laundering
data by using regular expressions is the <em class="emphasis">only</em>
approved internal mechanism for untainting dirty data.  And sometimes
it's the wrong approach entirely.  If you're in taint mode because
you're running set-id and not because you intentionally turned on
<span class="option">-T</span>, you can reduce your risk by forking a child of
lesser privilege; see the section <a href="ch23_01.htm#ch23-sect-cuye">Section 23.1.2, "Cleaning Up Your Environment"</a>.</p>
<blockquote class="footnote">

<a name="FOOTNOTE-4"></a>
<p>[4] Unless you were
using an intentionally broken locale.  Perl assumes that your system's
locale definitions are potentially compromised.  Hence, when running
under the <tt class="literal">use locale</tt> pragma, patterns with a
symbolic character class in them, such as <tt class="literal">\w</tt> or
<tt class="literal">[[:alpha:]]</tt>, produce tainted
results.</p>

</blockquote>

<p>The <tt class="literal">use re 'taint'</tt> pragma disables the implicit
untainting of any pattern matches through the end of the current
lexical scope.  You might use this pragma if you just want to extract
a few substrings from some potentially tainted data, but since you
aren't being mindful of security, you'd prefer to leave the substrings
tainted to guard against unfortunate accidents later.</p>

<p>Imagine you're matching something like this, where
<tt class="literal">$fullpath</tt> is tainted:
<blockquote>
<pre class="programlisting">($dir, $file) = $fullpath =~ m!(.*/)(.*)!s;</pre>
</blockquote>

By default, <tt class="literal">$dir</tt> and <tt class="literal">$file</tt> would
now be untainted.  But you probably didn't want to do that so
cavalierly, because you never really thought about the security
issues.  For example, you might not be terribly happy if
<tt class="literal">$file</tt> contained the string "<tt class="literal">; rm -rf *
;</tt>", just to name one rather egregious example.  The
following code leaves the two result variables tainted if
<tt class="literal">$fullpath</tt> was tainted:
<blockquote>
<pre class="programlisting">{
    use re 'taint';
    ($dir, $file) = $fullpath =~ m!(.*/)(.*)!s;
}</pre>
</blockquote>

A good strategy is to leave submatches tainted by default over the
whole source file and only selectively permit untainting in nested
scopes as needed:
<blockquote>
<pre class="programlisting">use re 'taint';
# remainder of file now leaves $1 etc tainted
{
    no re 'taint';
    # this block now untaints re matches
    if ($num =~ /^(\d+)$/) {
        $num = $1;
    }
}</pre>
</blockquote>

Input from a filehandle or a directory handle is automatically
tainted, except when it comes from the special filehandle, <tt class="literal">DATA</tt>.
If you want to, you can mark other handles as trusted sources
via the <tt class="literal">IO::Handle</tt> module's <tt class="literal">untaint</tt> function:
<blockquote>
<pre class="programlisting">use IO::Handle;

IO::Handle::untaint(*SOME_FH);          # Either procedurally
SOME_FH-&gt;untaint();                     # or using the OO style.</pre>
</blockquote>

Turning off tainting on an entire filehandle is a risky move.  How
do you <em class="emphasis">really</em> know it's safe?  If you're going to do this, you
should at least verify that nobody but the owner can write to the
file.<a href="#FOOTNOTE-5">[5]</a> If you're on a Unix filesystem (and
one that prudently restricts <em class="emphasis">chown</em>(2) to the superuser), the
following code works:
<blockquote>
<pre class="programlisting">use File::stat;
use Symbol 'qualify_to_ref';
sub handle_looks_safe(*) {
    my $fh = qualify_to_ref(shift, caller);
    my $info = stat($fh);
    return unless $info;

    # owner neither superuser nor "me", whose
    # real uid is in the $&lt; variable
    if ($info-&gt;uid != 0 &amp;&amp; $info-&gt;uid != $&lt;) {
        return 0;
    }

    # check whether group or other can write file.
    # use 066 to detect for readability also
    if ($info-&gt;mode &amp; 022) {
        return 0;
    }
    return 1;
}

use IO::Handle;
SOME_FH-&gt;untaint() if handle_looks_safe(*SOME_FH);</pre>
</blockquote>

We called <tt class="literal">stat</tt> on the filehandle, not the filename, to avoid a
dangerous race condition.  See the section <a href="ch23_02.htm#ch23-sect-hrc">Section 23.2.2, "Handling Race Conditions"</a>
later in this chapter.</p>
<blockquote class="footnote">

<a name="FOOTNOTE-5"></a>
<p>[5] Although you can untaint a directory handle,
too, this function only works on a filehandle.  That's because given
a directory handle, there's no portable way to extract its file
descriptor to <tt class="literal">stat</tt>.</p>

</blockquote>

<p>Note that this routine is only a good start.  A slightly more
paranoid version would check all parent directories as well, even though you
can't reliably <tt class="literal">stat</tt> a directory handle.  But if any parent directory
is world-writable, you know you're in trouble whether or not there are race conditions.</p>

<p>Perl has its own notion of which operations are dangerous, but it's
still possible to get into trouble with other operations that don't
care whether they use tainted values.  It's not always enough to
be careful of input.  Perl output functions don't test whether their
arguments are tainted, but in some environments, this matters.  If
you aren't careful of what you output, you might just end up spitting
out strings that have unexpected meanings to whoever is processing
the output.  If you're running on a terminal, special escape and
control codes could cause the viewer's terminal to act strangely.
If you're in a web environment and you blindly spit back out data that
was given to you, you could unknowingly produce HTML tags that
would drastically alter the page's appearance.  Worse still, some
markup tags can even execute code back on the browser.</p>

<p>Imagine the common case of a guest book where visitors enter their own
messages to be displayed when others come calling.  A malicious guest
could supply unsightly HTML tags or put in
<tt class="literal">&lt;SCRIPT&gt;...&lt;/SCRIPT&gt;</tt> sequences
that execute code (like JavaScript) back in the browsers of subsequent
guests.</p>

<p>Just as you should carefully check for only good characters when
inspecting tainted data that accesses resources on your own system,
you should apply the same care in a web environment when presenting
data supplied by a user.  For example, to strip the data of any
character not in the specified list of good characters, try something
like this:
<blockquote>
<pre class="programlisting">$new_guestbook_entry =~ tr[_a-zA-Z0-9 ,./!?()@+*-][]dc;</pre>
</blockquote>

You certainly wouldn't use that to clean up a filename, since you
probably don't want filenames with spaces or slashes, just for
starters.  But it's enough to keep your guest book free of
sneaky HTML tags and entities.  Each data-laundering case is a
little bit different, so always spend time deciding what is and
what is not permitted.  The tainting mechanism is intended to catch
stupid mistakes, not to remove the need for thought.</p>

<a name="INDEX-3988"></a><a name="INDEX-3989"></a><a name="INDEX-3990"></a>





<a name="ch23-sect-cuye"></a>
<h3 class="sect2">23.1.2. Cleaning Up Your Environment</h3>

<a name="INDEX-3991"></a><a name="INDEX-3992"></a><a name="INDEX-3993"></a><a name="INDEX-3994"></a>
<p>When you execute another program from within your Perl script, no
matter how, Perl checks to make sure your <tt class="literal">PATH</tt>
environment variable is secure.  Since it came from your environment,
your <tt class="literal">PATH</tt> starts out tainted, so if you try to run
another program, Perl raises an "<tt class="literal">Insecure
$ENV{PATH}</tt>" exception.  When you set it to a known,
untainted value, Perl makes sure that each directory in that path is
nonwritable by anyone other than the directory's owner and group;
otherwise, it raises an "<tt class="literal">Insecure directory</tt>"
exception.</p>

<p>You may be surprised to find that Perl cares about your
<tt class="literal">PATH</tt> even when you specify the full pathname of the
command you want to execute.  It's true that with an absolute
filename, the <tt class="literal">PATH</tt> isn't used to find the
executable to run.  But there's no reason to trust the program you're
running not to turn right around and execute some
<em class="emphasis">other</em> program and get into trouble because of the