没有 Suhosin 的 php 5.4 是否安全？答案

【问题标题】：Is php 5.4 safe without Suhosin?没有 Suhosin 的 php 5.4 是否安全？
【发布时间】：2013-01-18 18:13:49
【问题描述】：

我目前正在开发一个最终会在商业上可用的 PHP CMF，我想使用特征。然而问题在于，trait 是 PHP 5.4 的一个特性，而且很明显流行的 Suhosin 安全补丁与 PHP 5.4 不兼容。

所以我的问题是：在没有 Suhosin 安全补丁的情况下运行 PHP 网站是否安全？如果不是，我会给自己和其他使用我的 CMF 的人留下哪些漏洞？

注意：我不关心共享主机。预计任何使用我的 CMF 的人都可以对其 Web 服务器进行管理控制。

【问题讨论】：

如果你可以使用<?php echo 'hello world'; ?> 来颠覆一个网站，那么你应该是一名渗透测试员。一个网站的安全与否与您所做的一样。
我不明白，为什么关闭了？这是一个完全有效的问题。
因为您只是在询问“我的系统是否安全”而没有任何关于您系统的详细信息。你的网站只是一个hello world吗？它会为美国银行做网上银行吗？它们在安全要求方面是完全不同的，对于如此广泛的问题，绝对没有人可以为您提供任何有效的答案。
不，这根本不是我要问的。我在问 PHP 5.4 是否有 Suhosin 为 5.3 修补的任何已知漏洞，因此我应该坚持使用 5.3 + Suhosin 还是升级到 5.4。我问这个是因为很多人建议不要在没有补丁的情况下使用 PHP。
我觉得这是一个有效的问题。我们可以将其重构为：Suhosin 在 PHP 5.3 中解决的漏洞在 PHP 5.4 中是否存在/显着。

标签： php suhosin

【解决方案1】：

Suhosin 是一个 PHP 强化补丁。它没有修补任何明确的安全漏洞——它只是让 PHP 脚本中的一些漏洞更难被利用。

Suhosin 所做的一些更改最终被纳入 PHP。例如，Suhosin 对输入中空字节的各种保护层在 PHP 5.3.4 中变得不必要了，这使得文件名中的空字节总是抛出错误（而不是在空字节处静默截断文件名）。

在没有 Suhosin 的情况下，PHP 5.4 通常被认为是相当安全的。展望未来，只要您的应用程序支持它，您最好使用更新 (5.4+) 版本的 PHP，而不是使用带有 Suhosin 补丁的旧版本。

【讨论】：

谢谢duskwuff，这正是我正在寻找的答案:)
-1（对不起，总是为此感到难过）以获得模糊的答案。 Suhosin 有a lot of features，如果有人能告诉我哪些这些功能已被纳入到更高版本的 PHP 中，哪些没有实现，我会感觉更舒服。
Suhosin 是一个补丁和一个扩展。您可以在没有补丁的情况下使用扩展并获得普通 PHP 中不存在的额外保护和安全功能（甚至在 5.4 中也不存在）。

【解决方案2】：

如果您无法禁用 eval()（一种语言结构，而不是函数）或在 eval 中设置黑名单来禁用 eval 中的大部分黑客工具箱，那么您正在运行黑客无法抗拒的带宽负载寻找带宽来运行他们的有效载荷。理想情况下，不能总是将什么列入黑名单，因为 3rd 方模块编写者甚至框架核心依赖于 eval() 上下文中的一些函数：

suhosin.executor.eval.blacklist=include,include_once,require,require_once,curl_init,fpassthru,file,base64_encode,base64_decode,mail,exec,system,proc_open,leak,pfsockopen,shell_exec,ini_restore,symlink,stream_socket_server,proc_nice,popen,proc_get_status,dl,pcntl_exec,pcntl_fork, pcntl_signal, pcntl_waitpid, pcntl_wexitstatus, pcntl_wifexited, pcntl_wifsignaled, pcntl_wifstopped, pcntl_wstopsig, pcntl_wtermsig, socket_accept, socket_bind, socket_connect, socket_create, socket_create_listen, socket_create_pair,link,register_shutdown_function,register_tick_function,create_function,passthru,p_open,proc_close,proc_get_status,proc_terminate, allow_url_fopen,allow_url_include,passthru,popen,stream_select

如果您无法过滤这些功能，那么安全性的主要组成部分就缺失了。

以下是远程管理工具 (RATS) 的一些示例，它们会通过任何易受攻击的第 3 方模块或站点用户帐户感染您的站点。

RAT 可以有多种形式，其中一些很容易用 grep 表示：

<?php error_reporting(0); eval(gzuncompress(base64_decode('eF5Tcffxd3 ...

<?php preg_replace("/.*/e","\x65\x76\x61\x6C\x28\ ...

有些更专业和混淆，无法真正被 grep 寻找，除非 suhosin 提示您他们执行了，否则无法找到：

<?php $_0f4f6b="\x70\x72\x65\x67\x5f\x72\x65\x70\x6c\x61\x63\x65";$_0f4f6b("\x7 ...

<?php require "./.cache/.%D59C%49AA%73A8%63A1%9159%0441"; ?>

（注意在这种情况下，CACHE 目录不能在源代码管理中，因此也无法跟踪）

【讨论】：

附带说明：当使用 /e 时，PHP 5.5 会通过发出弃用警告自行提示您；)
虽然你关于禁用 eval 的论点是有道理的，但它忽略了一个更明显的点：过滤用户输入和保护服务器访问——如果黑客不能用 eval 注入代码，他们就不能使用 eval 开始.了解如何将输入列入白名单并使用正确的输出编码是比将常用语言功能列入黑名单更广泛有用的安全概念。
哈哈，我的杀毒软件在这个网站上发出警报，说它有 PHP/Obfuscated.E。所以这就是原因。

【解决方案3】：

恕我直言，上面来自duskwuff 的声明，没有Suhosin 一切都会好起来的既不是权威也不一定是正确的（特别是考虑到自那时以来较新的PHP 版本出现了许多关键漏洞）。

在我看来，如果 Suhosin 可用于当前的 PHP 版本，那肯定会更好 - 从安全 POV 来看。当然，事实上并非如此，停留在旧的（最终未维护的）PHP 版本也不是一个解决方案。

通常 PHP，尤其是 PHP 应用程序以存在安全问题而闻名……所以问题不是“没有 Suhosin 的新 PHP 版本是否安全”……

【讨论】：

没有任何这些批评的证据或理由：只是很多通用的FUD — neither authoritative nor necessarily correct 是一个明显适用于 this 答案的陈述本页