in reply to CGI Filenames and decode_entities

Marais:

I'd guess that the decode_entities routine is directly manipulating the @_ array containing the subroutine parameters. If it does that and makes any changes to the string, then it can do what you're describing.

Here's a cheesy example of what I'm talking about:

$ cat destructive_sub.pl use warnings; use strict; my $param = 'Now is the time'; print "$param\n"; do_it($param); print "$param\n"; sub do_it { $_[0] =~ s/([it])/uc($1)/ge; } krevulax:~ [roboticus] $ perl destructive_sub.pl Now is the time Now Is The TIme

Notice how the second print statement gives a slightly different result.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

Replies are listed 'Best First'.
Re^2: CGI Filenames and decode_entities
by kennethk (Abbot) on Jul 23, 2015 at 21:54 UTC
    And from the HTML::Entities documentation:
    If called in void context the arguments are decoded in-place.
    So the solution is to not call in void context:
    $filename = decode_entities($filename);
    As a side note, if you are migrating or securing an old script, you should take a read through perltaint. It'll help you protect yourself from classic exploits.

    #11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.

Re^2: CGI Filenames and decode_entities
by Marais (Novice) on Jul 23, 2015 at 21:54 UTC
    Well, it's an interesting idea, but why do other cgi parameters (other than the file name, that is) not experience the same problem? What's special about the file name?