常见的PHP设置不安全吗？

10

我在大学的系统管理部门工作，偶然发现了一些可能很常见的东西，但对我来说是很震惊的。

所有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脚本，使用反引号运行外部命令等）。

像这样更改策略会破坏很多事情，并且很有可能使用户抓住他们的干草叉并追我们。。。如果我们决定如何更改设置，我将与同事讨论并在此处进行更新。

apache-2.2 security php

— 蓬图斯
source

这是个有趣的问题。我敢肯定在主要的共享主机提供商（例如DreamHost）上，这是不可能的。但是我会对他们如何保护这一点感兴趣。正如cstamas所提到的，suphp看起来是一个很好的解决方案，但这是大多数托管服务提供商所使用的吗？

— 冒犯君主

1

我open_basedir在生产共享主机系统上使用了以下解决方案，但我们将每个人都分成了自己的虚拟主机-不确定它是否适用于单个目录...

— voretaq7 2010年

8

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

http://www.suphp.org

— sta骨
source

这可能无法解决上述问题（至少在共享托管环境中。htpasswd文件通常由拥有站点和组（apache）或世界（因为用户不了解/不在乎安全性）的用户可读）拥有，因此即使使用suphp，他们也能够读取这些文件）

— voretaq7 2010年

@ voretaq7：可以应用其他一些限制。据我记得，您甚至可以拒绝访问您不拥有的文件。因此，这排除了上述攻击。

— cstamas 2010年

我知道您可以限制文件的权限（“组/其他/任何人都不能写”），但是我不知道有什么方法可以阻止超出FS权限的读取。它们具有check_vhost_docroot，但是AFAIK仅适用于正在执行的脚本（？我可能对此有误）

— voretaq7 2010年

1

我不确定在这样的环境中suphp是否是一个好的解决方案。用户可能具有www用户所没有的各种权限。通过php找到方法的攻击者可以找到ssh密钥或keytab，或更改用户的登录脚本以创建后门。而且“ vhosts”设置不是很有用，因为public_html目录可通过主虚拟主机上的“ /〜username”获得。我想也许public_html中的脚本应该被完全禁用。

— Pontus 2010年

4

我的建议是限制PHP对文件的访问（通过open_basedir和类似的指令，在每个虚拟主机的基础上）：您希望用户能够在其Web根目录下，也许在其上一个级别下打开/读取/写入文件（从头开始）。空格），但不是目录（例如htpasswd文件）。

目录结构如下：

/Client
    /auth
    /site
        /www_root
        /www_tmp

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

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

— voretaq7
source

1

suphp正如cstamas所指出的那样，在共享主机环境中也是一个好主意-设置它会产生一些开销，但是我要说安全上的收获是完全值得的。在FreeBSD Jail或专用虚拟机之类的所有PHP站点中，将所有PHP站点沙盒化都是最大的安全胜利之一。

— voretaq7 2010年

只要将“ public_html”通过其自己的虚拟主机提供服务，“ open_basedir”似乎是一种将主Web文件与用户文件分开的简单方法。但这并不能保护用户彼此，因为他们没有自己的虚拟主机。对？

— Pontus 2010年

我没有尝试open_basedir在<Directory>指令中进行设置，但我认为它应该是可以允许的（“尝试一下”-最糟糕的是它不起作用:)

— voretaq7 2010年

1

到目前为止，看起来大多数商业Web主机都使用open_basedir（通常订户拥有自己的付费域或获得免费的子域），但是对于像在学术机构中那样的基于目录的主页，suphp似乎是最好的答案。

— 冒犯君主

1

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

例如.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。

— 豆
source

2

这可能有助于为新帐户提供一些初始保护。但是用户无法编辑它的事实可能使您很想删除.htaccess文件（他们可以这样做，因为它只需要对public_html目录的写访问权限）并创建自己的。在每个用户的主配置中添加一个“ <Directory>”-块是可行的，但是在这里仍然允许他们反选php中的外部命令，这意味着很容易绕开open_basedir。

— Pontus 2010年

@Pontus：关于删除文件的好处（我不确定afs是否支持不可变文件属性）。如果您说在chroot监狱中运行Web服务器可以防止各种程序执行漏洞，我会给+1。

— symcbean 2010年

1

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

— 查尔斯·B
source