in reply to Re^5: Using Regexp Patterns as Variables
in thread Using Regexp Patterns as Variables

Or if that doesn't reach the translator, the following surely would: 
$ENV{REQUEST_URI} = q{/Products/bt-foo.aspx?evil=";system('ls -l');".a
+spx};

[download]

The solution is to use a more restrictive pattern: 

my $in = '/Products/bt-(\w+).aspx';

[download]

That something as innocent as using .* in the pattern opens such a big security hole indicates a fundamental problem with the approach.

Replies are listed 'Best First'.
Re^7: Using Regexp Patterns as Variables
by Rodster001 (Pilgrim) on Mar 18, 2009 at 20:28 UTC
    Yeah, I ran that too and eval did not execute that code. I have tried quite a few different variations and have been unable to get anything to execute.

    Believe me, if this is possible then I will find another way. But, so far it seems there is no risk.

    Here is the code I used: 

    #!/usr/bin/perl

use strict;
use warnings;

$ENV{REQUEST_URI} = q{/Products/bt-foo.aspx?evil=";system('ls -l');".a
+spx};

my $in  = '/Products/bt-(.*?).aspx';
my $out = '/s/Products/$1';

$ENV{REQUEST_URI} =~ s#$in#eval qq{"$out"}#ie;

print "$ENV{REQUEST_URI}\n";

    [download]
    Maybe you can modify that to demonstrate the security risk, you are talking about?
[reply]
[d/l]
Re^7: Using Regexp Patterns as Variables
by kyle (Abbot) on Mar 18, 2009 at 20:03 UTC

    That doesn't do anything either. I'm still suspicious, but I don't see how you can put anything in the URL which can cause code execution with the code I showed.

[reply]
      Ah, I misread. I thought you were giving an example where it did work.
[reply]

In Section Seekers of Perl Wisdom