如果上传的文件 (PHP) 不打算存储在服务器上,我是否需要验证它们?

发布于 2024-09-10 15:39:44 字数 1465 浏览 6 评论 0原文

我有一个带有选项页面的 WordPress 主题。我已经包含了基本的导出/导入选项功能。导出功能允许用户将选项下载到文本 .dat 文件并将其存储在自己的计算机上。导入选项按钮读取 .dat 文件并覆盖数据库中的当前选项。然后该文件在脚本执行结束时被删除(不存储在服务器中)。

没有单独的 uploads.php 文件,一切都发生在一个脚本中(导出、导入等)。

我尝试导入一些 php 文件和其他类型的文件,唯一发生的事情是选项被清除了。但这就是应该发生的事情,导入的文件应该替换数据库中的任何内容。

用户只有以管理员访问权限登录 WordPress 仪表板后才能访问此表单。

所以这个进口表格不需要有广泛的安全功能,是吗?除了,也许我应该尝试使用 .sql 文件,看看会发生什么?有人可能会创建一个 .sql 文件并清除整个数据库吗?为了安全起见,我应该将 .sql 文件列入黑名单吗?

这是我的导入代码:

   if ( $_GET['page'] == basename(__FILE__) ) {
        if ( 'export' == $_POST['action']) {
        cpress_export();
    }   
    if (isset($_FILES['settings'])){
        if ($_FILES["settings"]["error"] > 0){
            echo "Error: " . $_FILES["settings"]["error"] . "<br />";
          } else{
            $rawdata = file_get_contents($_FILES["settings"]["tmp_name"]);
            $cp_options = unserialize($rawdata);
            update_option('cpress_options', $cp_options);
            header("Location: themes.php?page=options_page.php&import=true");
          }
    }

这是我的导出代码(在同一文件中):

function cpress_export(){
$settings = get_option('cpress_options');
$file_out = serialize($settings);
header("Cache-Control: public, must-revalidate");
header("Pragma: hack"); 
header("Content-type: text/plain; charset=ISO-8859-1");
header('Content-Disposition: attachment; filename="cpress-options-'.date("Ymd").'.dat"');
echo $file_out;
exit;}

I have a wordpress theme with an options page. I have included a basic export/import options feature. The export feature allows the users to download the options to a text .dat file and store them on their own computer. The import options button reads a .dat file and overwrites the current options in the database. Then the file is deleted at the end of script execution (not stored in the server).

There are no separate uploads.php files, everything happens in one script (the export, import, etc).

I tried importing some php files, and other types of files, and the only thing that happened was the options were wiped out. But that's what's supposed to happen, the imported file is supposed to replace whatever is in the database.

The user can only access this form if they are logged in to the WordPress Dashboard with admin access.

So there is no need to have extensive security features on this import form, is there? Except, maybe I should try it with .sql files and see what could happen? Could someone potentially create an .sql file and wipeout the entire database? Should I blacklist .sql files to be safe?

Here is my import code:

   if ( $_GET['page'] == basename(__FILE__) ) {
        if ( 'export' == $_POST['action']) {
        cpress_export();
    }   
    if (isset($_FILES['settings'])){
        if ($_FILES["settings"]["error"] > 0){
            echo "Error: " . $_FILES["settings"]["error"] . "<br />";
          } else{
            $rawdata = file_get_contents($_FILES["settings"]["tmp_name"]);
            $cp_options = unserialize($rawdata);
            update_option('cpress_options', $cp_options);
            header("Location: themes.php?page=options_page.php&import=true");
          }
    }

And here is my export code (in the same file):

function cpress_export(){
$settings = get_option('cpress_options');
$file_out = serialize($settings);
header("Cache-Control: public, must-revalidate");
header("Pragma: hack"); 
header("Content-type: text/plain; charset=ISO-8859-1");
header('Content-Disposition: attachment; filename="cpress-options-'.date("Ymd").'.dat"');
echo $file_out;
exit;}

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

我也只是我 2024-09-17 15:39:44

我推荐一些改进;

  1. 在插件开头使用 if (!define('ABSPATH')) die() - 如果恶意用户尝试直接加载您的脚本,它将失败,因为 WordPress 常量ABSPATH 未定义。

  2. 使用WordPress nonces - 这至少会让一个讨厌的人的生活变得更困难:)

  3. 检查 unserialize() 不会失败(如果失败,结果将是 boolean false) - 如果序列化数据格式错误(或者一开始就没有序列化),就会发生这种情况。如果失败,请不要继续更新。

  4. 使用wp_safe_redirect()而不是header()< /code> 进行重定向(事实上,在重定向到其他 WP 管理页面时,您应该始终使用此函数 - 否则使用 wp_redirect())。

A couple of improvements I'd recommend;

  1. Use if (!defined('ABSPATH')) die() at the beginning of your plugin - if a malicious user tried to load your script directly, it would fail, since the WordPress constant ABSPATH isn't defined.

  2. Use WordPress nonces - this will at least make a nasty person's life a little harder :)

  3. Check that unserialize() does not fail (the result will be boolean false if it does) - this will happen if the serialized data was malformed (or wasn't serialized to begin with). If it fails, don't proceed with the update.

  4. Use wp_safe_redirect() instead of header() for your redirect (in fact, you should always use this function when redirecting to other WP admin pages - otherwise use wp_redirect()).

残疾 2024-09-17 15:39:44

如果您正在读取文件并将该文件加载到数据库中,那么当然就有被利用的机会。但是,如果仅对管理员启用此功能,那么我不知道应该付出多少努力来防范恶意活动。如果他们是管理员,他们可以做更容易的事情来清除数据库。

作为一般规则,可能值得付出一些努力,这样用户就不会意外搞砸任何事情,但阻止管理员用户做恶意的事情既不值得付出努力,也不符合“管理员”角色的理念。这就像在 Linux 机器上授予某人 su 权限,并试图确保他们无法在其上安装恶意软件。

编辑:我检查了Wordpress文档,以及update_option()函数在运行查询之前转义字符串。您应该不会受到 SQL 注入的影响。

If you are reading from a file and loading that file into the database, then there is an opportunity for exploitation, sure. However, if this is only enabled for admins, then I don't know how much effort should be put in to protecting against malicious activity. If they are admins, there are much easier things they could do to wipe out the database.

As a general rule, it is probably worth some effort to making it so users can't accidentally screw anything up, but keeping your admin users from doing malicious things is neither worth the effort nor consistent with the idea of an "admin" role. It is like giving someone su privileges on a Linux box and trying to make sure they can't install malicious software on it.

edit:I checked the Wordpress docs, and the update_option() function escapes the string before the query is run. You should be safe from SQL injections.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文