今天一位同事与我打赌，他知道一种提供特殊格式字符串的方法，该字符串可以通过以下正则表达式检查并仍然提供扩展名为 .php 或 .jsp 或 .asp:

if (preg_match('/\.(jpeg|jpg|gif|png|bmp|jpe)$/i', $var) && preg_match('/\.(asp|jsp|php)$/i', $var) == false) 
{
    echo "No way you have extension .php or .jsp or .asp after this check.";
}

尽管我努力尝试并在网上搜索，但我无法找到使这种事情成为可能的缺陷。我可以忽略什么吗？鉴于“空字节”漏洞已得到处理，这里还有什么问题？

注意:我绝不暗示这段代码是检查文件扩展名的完整方法，preg_match() 函数中可能存在缺陷，或者文件内容可能是不同的格式，我只是根据正则表达式语法本身问这个问题。

编辑 - 实际代码:

if (isset($_FILES["image"]) && $_FILES["image"]["name"] && preg_match('/\.(jpeg|jpg|gif|png|bmp|jpe)$/i', $_FILES["image"]["name"]) && preg_match('/\.(asp|jsp|php)$/i', $_FILES["image"]["name"]) == false) {
        $time = time();
        $imgname = $time . "_" . $_FILES["image"]["name"];
        $dest = "../uploads/images/";

        if (file_exists($dest) == false) {
            mkdir($dest);
        }

        copy($_FILES['image']['tmp_name'], $dest . $imgname);

    }else{
        echo "Invalid image file";
    }

PHP 版本:5.3.29

编辑:结语

原来“漏洞”只出现在 Windows 上。尽管如此，它确实按照我的同事告诉我的那样做了——通过了正则表达式检查并保存了带有可执行扩展名的文件。以下是使用 PHP 5.3.13 在 WampServer 2.2 上测试的:

将以下字符串传递给 test.php:.jpg 上方的正则表达式检查(注意所需扩展名末尾的“:”冒号)将验证它并且函数 copy () 似乎省略了冒号后的所有内容，包括符号本身。 同样，这仅适用于 Windows。在 Linux 上，文件将使用与传递给函数的名称完全相同的名称写入。

最佳答案

没有一个单一的步骤或完全直接的方法来利用您的代码，但这里有一些想法。

在这个例子中你将它传递给 copy() 但是你已经提到你已经使用这个方法来验证文件分机一段时间了所以我假设你有其他可能使用过这个的情况在不同的 PHP 版本上也包含其他函数的过程。

将此视为测试过程(利用 include，require):

$name = "test.php#.txt";
if (preg_match('/\.(xml|csv|txt)$/i', $name) && preg_match('/\.(asp|jsp|php)$/i', $name) == false) {
    echo "in!!!!";
    include $name;
} else {
    echo "Invalid data file";
}

这将以打印“in!!!!”结束并执行“test.php”，即使它已上传，它也会从 tmp 文件夹中包含它——当然，在这种情况下，你已经被攻击者拥有，但让我们也考虑一下这个选项。 这不是上传过程的常见场景，但它是一个可以通过组合多种方法来利用的概念:

让我们继续 - 如果你执行:

//$_FILES['image']['name'] === "test.php#.jpg";
$name = $_FILES['image']['name'];
if (preg_match('/\.(jpeg|jpg|gif|png|bmp|jpe)$/i', $name) && preg_match('/\.(asp|jsp|php)$/i', $name) == false) {
    echo "in!!!!";
    copy($_FILES['image']['tmp_name'], "../uploads/".$name);
} else {
    echo "Invalid image file";
}

再次完美。该文件被复制到“uploads”文件夹中 - 您无法直接访问它(因为 Web 服务器会去掉 # 的右侧)但是您注入(inject)了该文件，攻击者可能会找到一个以后调用它的方式或另一个弱点。

此类执行场景的示例在共享和托管站点中很常见，其中文件由 PHP 脚本提供服务，(在某些不安全的情况下)可能会通过将文件包含在错误类型的函数中来加载文件，例如 require, include, file_get_contents 都是易受攻击的，可以执行文件。

空字节 空字节攻击是 php < 5.3="" 中的一个大弱点，但在="" 5.4+="" 版本中的一些函数中重新引入了回归，包括所有与文件相关的函数以及扩展中的更多函数。它被修补了好几次，但它仍然存在并且许多旧版本仍在使用。如果您正在处理较旧的="" php="">

//$_FILES['image']['name'] === "test.php\0.jpg";
$name = $_FILES['image']['name'];
if (preg_match('/\.(jpeg|jpg|gif|png|bmp|jpe)$/i', $name) && preg_match('/\.(asp|jsp|php)$/i', $name) == false) {
    echo "in!!!!";
    copy($_FILES['image']['tmp_name'], "../uploads/".$name);
} else {
    echo "Invalid image file";
}

将打印“in!!!!”并复制名为“test.php”的文件。

php 修复的方法是在将字符串传递给创建实际 char 数组的更深层次的 C 过程之前和之后检查字符串长度，如果字符串被空字节截断(这表示 C 中字符串的结尾) ) 长度将不匹配。 read more

奇怪的是，即使在已打补丁的现代 PHP 版本中，它仍然存在:

$input = "foo.php\0.gif";
include ($input); // Will load foo.php :)

我的结论: 您验证文件扩展名的方法可以得到显着改进 - 您的代码允许名为 test.php#.jpg 的 PHP 文件通过，而它不应该通过。成功的攻击大多是通过组合多个甚至是次要漏洞来执行的 - 您应该将任何意外结果和行为视为一个问题。

注意:关于文件名和图片的问题更多，因为它们会多次包含在以后的页面中，如果它们没有被正确过滤和安全包含，您就会面临更多的 XSS 问题但那是题外话。

关于PHP 正则表达式漏洞赌注，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33762339/