On: The Perl Jam: Exploiting a 20 Year-old Vulnerability [pdf]

[sarciszewski]

I love how, at the very end of the talk, when someone asked the speaker if he knew of any other languages that had this problem, and the speaker didn't know, someone decided to shout out "PHP!"

There is something that PHP developers should be made aware of, but it isn't something as weird as Perl's list behavior.

Test script:

    <?php
    header("Content-Type: text/plain;charset=UTF-8");
    var_dump($_GET);

If you access /test.php?a=1&a=2 you will be greeted with:

    array(1) {
      ["a"]=>
      string(1) "2"
    }

You can reason amongst yourselves about whether 1 or 2 is more desirable, but it's only one parameter. So the Perl list trickery is not applicable. Now visit /test.php?a[]=1&a[]=2

    array(1) {
      ["a"]=>
      array(2) {
        [0]=>
        string(1) "1"
        [1]=>
        string(1) "2"
      }
    }

If you're expecting a string in a GET/POST parameter, make sure you're not receiving an array. This is a HTTP feature, not a bug, but it can sometimes break code if you're not expecting it. (Break as in error messages)

So, no, PHP is not an example of a language with a similar vulnerability.

[eCa → sarciszewski]

The vulnerability in the talk is not in Perl. It is in the CGI module.

[sarciszewski → eCa]

The vulnerability is a Perl language feature that gets misused by the CGI module and subsequently by application code.

[chromatic → eCa]

The vulnerability is in the use of the CGI module.