RealPath 安全吗？答案

【问题标题】：Is RealPath safe?RealPath 安全吗？
【发布时间】：2022-04-06 20:15:51
【问题描述】：

<?php
if (preg_match('/^[a-z0-9]+$/', $_GET['p'])) {
$page = realpath('pages/'.$_GET['p'].'.php');
$tpl = realpath('templates/'.$_GET['p'].'.html');
if ($page && $tpl) {
    include $page;
    include $tpl;
} else {
    include('error.php');
}
}
?>

你觉得这有多安全？

【问题讨论】：

\w 匹配字母数字和 _，使用它会产生与预期不同的模式
你是偏执狂吗？ stackoverflow.com/questions/524908/dynamic-include-safety stackoverflow.com/questions/536688/include-safety

标签： php realpath

【解决方案1】：

我将它用于模板文件，因此它可以包含“页面”，而不必将单个文件与大量函数/字符串/switch-cases/elseifs（随你选）或创建大量文件相同的布局。

检查包含的目录的realpath应该在和要包含的文件的realpath，如果文件的realpath以include目录开头，则允许包含。

<?
#If you're worried about funky characters messing with stuff, use this
#preg_replace("/[^A-Za-z0-9_\-]+/","",$str);

if (isset($_REQUEST['page'])) {
    $path=realpath("../inc/page").DIRECTORY_SEPARATOR;
    $full_page=realpath($path.$_REQUEST['page'].".php");
    if (file_exists($full_page)&&(strpos($full_page,$path)===0)) {
        include($full_page);
    } else {
        echo "FAILED";
    }
}
?>

【讨论】：

【解决方案2】：

嗯，实际上它realpath 在这种情况下不提供任何安全性。实际上，在这种情况下它根本没有任何作用，因为include 在内部会扩展路径。您的安全实际上取决于preg_match。但是请注意，您使用的正则表达式不允许您使用任何带有大写字母、下划线或破折号的页面。

无论如何，我不认为包含基于请求中传递的参数的文件是个好主意。如果您需要，您的设计有问题。

【讨论】：

AllowEncodedSlashes 仅与路径部分有关 ($_SERVER['PATH_INFO']);编码的斜杠在查询字符串中仍然会出现，因此 $_GET[].

【解决方案3】：

realpath 在这种情况下对您没有帮助，因为include 可以将页面路径解析为同一文件，无论它是真实路径还是原始相对路径。它“似乎”是有效的，但我个人不会相信那段代码。我确信有人想出了一种巧妙的方法来将空字符注入输入，从而对字符串终止造成严重破坏。

为了安全起见，您需要做的是保留所有允许的输入/页面的白名单（或黑名单，如果它恰好更适合，但更喜欢白名单）。

【讨论】：

【解决方案4】：

好像很安全....

但效率不高。在 MVC 中，你有控制器和视图目录预设和预先知道。没有必要进行统计来检查视图/控制器是否存在。

【讨论】：

【解决方案5】：

realpath() 在这种情况下实际上会产生一些影响，因为如果目标文件不存在，它将返回FALSE。但正如其他海报已经说过的那样——这不会给代码增加任何安全性。

这是一种在指定文件不存在的情况下的错误处理方式。

【讨论】：

【解决方案6】：

最好在 $_GET['p'] 上运行 basename()。肯定没有目录遍历攻击。

【讨论】：

【解决方案7】：

我无法评论 PHP realpath，但如果它只是系统的 realpath 函数的包装器，那么需要注意一件事：在某些系统（例如 Solaris）上，如果进程在 realpath 执行时收到信号'将返回空字符串...在这种情况下，您必须确保您的代码已设置为处理这种情况（除非 PHP 实现为您解决了该特定困境）

【讨论】：