Kevin Meltzer <[EMAIL PROTECTED]> writes:
> On Wed, Mar 12, 2003 at 08:33:47PM +0000, Brian McCauley ([EMAIL PROTECTED]) said
> something similar to:
> > You've got the wrong end of the stick. -T will completely prevent
>
> You keep referring to a stick. I don't have a stick here with me.
You have but you can't see it. Trying to help you see it is a waste
of time. If you can get the wrong end of the stick then so can anyone
else so I've already re-writen it in such a way as to avoid the
possibility. So let's just drop it, OK.
> > This will not work, and for good reason, if $text is com-
> > ing form a tainted source. For explanation of how $text
> > could contain arbitrary Perl code see ``How do I expand
> > function calls in a string?'' in this section of the FAQ.
> >
> > If $text is coming from a source external to the Perl
> > script (typically a file) and you would content to trust
>
> "typically a file, database, or CGI input" maybe
No, typically it would not come from a CGI source. I'd accept
database. If you are going to give an essetially complete list of all
possible external sources you may as well drop the parenthetic clause
altogether.
Also if I mention CGI sources that are almost certainly not safe to
treat as untainted I'm going have to start talking about Safe
compartments. If I'm talking about string interpolation using Safe
compartments I'm going to have to talk about String::Interpolate and I
really want to avoid that as I don't want to appear to be trying to
revise the FAQ to advertise my modules.
> "and you would content to trust" ?? typo?
Yes, insert the word "be" in the obvious place :-).
> > executable code from that source then you simply make the
> > source untainted. This is no more or less dangerous than
>
> You would untaint the 'content' or 'data', no?
Matter ot taste. For a file or database that contians only message
templates I'd just mark the source (the filehandle or database handle)
untaineted.
I'll change it to "make data from that that source untainted" that
covers both cases.
> I'd also suggest a "see perlsec" somewhere in here.
Yep.
> I think this is much better. But, I've said my peace, chimmed in,
> tossed about $.06 out there :)
Thankyou for your help.
How can I expand/interpolate variables in text strings?
You can process a string through Perl's interpolation
engine like this:
$text = 'this has a $foo in it...\n ...and a $bar';
# Assume $text does not contain "\nEND\n"
chop ( $text = eval "<<END\n$text\nEND\n" );
die if $@;
This will not work, and for good reason, if $text is com-
ing form an tainted source. For explanation of how $text
could execute arbitrary Perl code see ``How do I expand
function calls in a string?'' in this section of the FAQ.
If $text is coming from a source external to the Perl
script (typically a file) and you would be content to
trust executable code from that source then you simply
make data from that source untainted. This is no more or
less dangerous than using "do()". For an explaination of
tainting see the perlsec manpage.
If you do not trust the source that much then you can
limit and launder the parts of the string that are passed
to eval() something like this:
$text =~ s/(\$\w+)/$1/eeg; # needed /ee, not /e
This still gives unrestricted access to your scalar vari-
ables. It is often better to use a hash:
%user_defs = (
foo => 23,
bar => 19,
);
$text =~ s/\$(\w+)/$user_defs{$1}/g;
For other variations on the theme of text templates see
the sprintf() function and numerous modules on CPAN.
