☰

常见的 PHP 设置不安全？

tag-icon • tag-icon apache-2.2 security php
常见的 PHP 设置不安全？

我在一所大学从事系统管理工作，偶然发现了一些可能很常见但对我来说相当震惊的事情。

所有 public_html 目录和 web 区域都存储在 afs 上，并具有 web 服务器的读取权限。由于允许用户在其 public_html 中拥有 php 脚本，这意味着他们可以从 php 内部访问彼此的文件（以及主 web 文件！）。

这不仅使任何 .htaccess 密码保护完全失效，还允许用户读取包含 mysql 数据库密码和类似敏感信息的 php 源文件。或者，如果他们发现其他人拥有 Web 服务器具有写访问权限的目录（例如用于个人日志或保存提交的表单数据），他们就可以将文件存储在这些帐户中。

一个简单的例子：

<?
  header("Content-type: text/plain");
  print file_get_contents("/afs/example.com/home/smith/public_html/.htpasswd"); 
?>

这是一个常见问题吗？您通常如何解决它？

更新：

感谢您的意见。不幸的是，似乎没有简单的答案。在像这样的大型共享环境中，用户可能不应该有这么多选择。我能想到的最佳方法是在主配置中为所有“public_html”目录设置“open_basedir”，运行 suphp 并仅允许干净的 php（没有 cgi 脚本，运行带有反引号的外部命令等）。

然而，像这样改变政策会破坏很多事情，而且很可能会让用户拿起干草叉追赶我们......如果我们决定如何改变设置，我会和我的同事讨论并在这里更新。

答案1

可以使用 suphp，它以其所有者的 uid 运行 php 脚本。

http://www.suphp.org

答案2

我的建议是限制 PHP 对文件的访问（通过open_basedir＆类似指令，基于每个虚拟主机）：您希望用户能够在他们的 webroot 下打开/读取/写入文件，也许在它上面一级（用于临时空间），但不是他们存储文件的目录htpasswd。

目录结构如下：

/Client
    /auth
    /site
        /www_root
        /www_tmp

满足以下要求：open_basedir可以安全地指向/Client/site，并且htpasswd文件存储在其中/Client/auth（使用.htaccess文件或httpd.conf修改文件以指向适当的位置）。
这可以防止您的客户端打开任何其他人的文件，并且恶意用户无法读取其中的内容/Client/auth（或您系统上的任何其他内容，例如/etc/passwd:-)

看http://php.net/manual/en/ini.core.php有关 open_basedir 和 per-vhost 实现的更多详细信息。

答案3

不，这不是一个常见问题，因为大多数共享主机会在每个用户的 public_html 目录下的 htaccess 文件中定义一个 open_basedir 配置（如果每个用户都有自己的 vhost，则在 vhost 中定义）。

例如.htaccess 文件：

# Assuming these are not set globally - its good practice to limit:
  php_flag magic_quotes_gpc off
  php_flag magic_quotes_runtime off
  php_flag register_globals off
  php_flag short_open_tag off
  php_value max_execution_time 60

# These set the user-specific paths
  php_value open_basedir /afs/example.com/home/smith:/usr/share/php/include
  php_value session.save_path /afs/example.com/home/smith/tmp
  php_value upload_tmp_dir /afs/example.com/home/smith/tmp

但请确保在 .htaccess 文件上设置了正确的权限，以防止用户更改 open_basedir（如果他们尝试在 subdir/.htaccess 中覆盖它，它应该不起作用 - 但您可能应该测试一下以确保）。

高血压

C。

答案4

AFS 忽略简单的 unix 用户权限。suPHP 在运行 php 程序之前执行 setuid，但这不会为该进程提供访问 AFS 所需的 kerberos 令牌，也不会限制其权限。suPHP 必须以某种方式进行修改才能获得这些令牌，然后才能以该用户的身份出现在 AFS 系统中。据我所知，这还没有做到。（事实上，我在查看是否有其他人这样做时发现了这个问题。）

相关内容