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

The test I had in mind was what you have but with: 

$ENV{REQUEST_URI} = q{/Products/bt-";system('ls -l');".aspx};

[download]

I tried that too, and it also doesn't do anything. That's because all eval sees is ""/s/Products/$1"". The variable gets interpolated, but it doesn't execute the result. Given that, maybe there really isn't anything the user can do.

Replies are listed 'Best First'.
Re^6: Using Regexp Patterns as Variables
by ikegami (Patriarch) on Mar 18, 2009 at 19:45 UTC
    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.

[reply]
[d/l]
[select]
      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]

      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