让用户添加自己的 nginx 虚拟主机文件是否存在任何安全风险?

发布于 2024-11-17 10:26:45 字数 812 浏览 6 评论 0原文

假设我通过 nginx 为一些人提供托管帐户。如果我要在他们的虚拟主机配置文件中添加一行,其中包含驻留在其主目录中的额外配置文件,这是否会导致任何类型的安全漏洞?

这是一个用户的虚拟主机文件:

server {
    listen 80;
    server_name user.example.com;
    access_log /var/log/nginx/user.access.log;
    location / {
        root /home/user/htdocs;
        index index.html index.htm index.php;
    }
    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php-fastcgi/php-fastcgi.socket;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME  /home/user/htdocs$fastcgi_script_name;
        include /etc/nginx/fastcgi_params;
    }

    # The important bit
    include /home/user/extra_config;

}

理论上,这将与一个 cron 作业结合起来,该作业检查每个 extra_config 的时间戳,并在必要时重新加载 nginx。理想情况下,用户将利用它来拒绝访问私有文件/目录或创建重写 - 基本上,它将是 .htaccess 的替代品。但这种方法有什么陷阱吗?有没有更好的方法来实现它?

Let's say that I'm giving some people hosting accounts via nginx. If I were to put a line in their virtual host configuration files that includes an extra config file residing in their home directories, could this lead to any sort of security breach?

Here is a user's virtual host file:

server {
    listen 80;
    server_name user.example.com;
    access_log /var/log/nginx/user.access.log;
    location / {
        root /home/user/htdocs;
        index index.html index.htm index.php;
    }
    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php-fastcgi/php-fastcgi.socket;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME  /home/user/htdocs$fastcgi_script_name;
        include /etc/nginx/fastcgi_params;
    }

    # The important bit
    include /home/user/extra_config;

}

Theoretically, this would be combined with a cron job that checks the timestamp of each extra_config, and reloads nginx if necessary. Ideally users would utilize this to deny access to private files/directories or create rewrites - basically, it would be an alternative to .htaccess. But are there any pitfalls to this approach? Is there a better way to accomplish it?

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

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

发布评论

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

评论(1

软糖 2024-11-24 10:26:45

最好只允许白名单配置指令。您不希望恶意用户(“Eve”)劫持其他用户的流量。例如,我相信用户可以构建如下所示的配置:

} 
server {
   listen 80;
   server_name alice.example.com;
   root /home/eve/htdocs;
}
server {
   listen 80;
   server_name bob.example.com;
   root /home/eve/htdocs;
}
server {
   listen 80;
   server_name passwd.example.com;
   root /etc/passwd;

相反,在理想的世界中,您将通过某种专用的 UI 获取输入,并根据该用户输入自行构建适当的 nginx 配置。例如,我允许用户以类似的方式指定 IP 禁止 - 我有一个仅接受 IP 列表的 UI。然后,我通过正则表达式验证 IP 的格式,并写出 nginx 拒绝指令。

It's best to only allow whitelisted config directives. You don't want a malicious user ("Eve") to highjack another user's traffic. e.g., I believe a user could construct a config like the following:

} 
server {
   listen 80;
   server_name alice.example.com;
   root /home/eve/htdocs;
}
server {
   listen 80;
   server_name bob.example.com;
   root /home/eve/htdocs;
}
server {
   listen 80;
   server_name passwd.example.com;
   root /etc/passwd;

Instead, in an ideal world you would take input via some sort of purpose-built UI, and build the appropriate nginx config yourself from that user input. For example, I allow users to specify IP bans in a similar way -- I have a UI that accepts only a list of IPs. I then verify the format of the IPs via a regex, and write out nginx deny directives.

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