没有Suhosin,PHP 5.4是否安全?

24

我目前正在开发一个PHP CMF,最终将会商业化,并且我想要使用traits。然而问题在于traits是PHP 5.4的特性,而广受欢迎的Suhosin安全补丁似乎不兼容PHP 5.4。

因此我的问题是:没有Suhosin安全补丁能否安全地运行PHP网站?如果不能,我和使用我CMF的其他人会面临哪些漏洞风险?

注意:我不担心共享主机。预计使用我的CMF的任何人都将对其Web服务器拥有管理控制权。


7
如果你可以使用 <?php echo 'hello world'; ?> 来破坏一个网站,那么你应该开办一家渗透测试公司。一个网站的安全性取决于你的维护措施。 - Marc B
4
为什么这个问题被关闭了,我不明白。它是一个完全合理的问题。 - Evan Byrne
5
因为你只是泛泛地问“我的系统安全吗”,却没有提供任何关于你的系统的细节。你的网站只是一个"Hello World"吗?还是要为美国银行(Bank of America)做在线银行业务?它们在安全要求方面是完全不同的宇宙,对于如此广泛的问题谁也无法给出任何有效的答案。请提供更多具体信息以便得到更准确的回答。 - Marc B
12
不,这完全不是我的问题。我的问题是PHP 5.4是否存在任何已知的漏洞,而Suhosin已经为5.3打补丁了,因此我应该坚持使用5.3 + Suhosin还是升级到5.4。我之所以问这个问题,是因为很多人建议不要在没有补丁的情况下使用PHP。 - Evan Byrne
4
我认为这是一个有意义的问题。我们可以重新表述为:Suhosin 在 PHP 5.3 中解决的漏洞,在 PHP 5.4 中是否仍然存在或者重要性是否减弱了。 - SoWhat
1
有一个由Suhosin作者创建的适用于PHP 5.4的Github存储库。因此,我认为不久将来会有适用于5.4的suhosin。 - MV.
3个回答

40

Suhosin是一种PHP加固补丁。它没有修复任何明确的安全漏洞——它只是使某些PHP脚本中的漏洞更难以利用。

Suhosin所做的一些更改最终被合并到PHP中。例如,PHP 5.3.4使文件名中的空字节始终引发错误(而不是在空字节处静默截断文件名),从而不再需要Suhosin对输入中的空字节进行各种保护层。

一般认为,没有Suhosin参与的情况下,PHP 5.4是相当安全的。未来,只要您的应用程序支持,使用新版本(5.4+)的PHP比使用带有Suhosin补丁的旧版本更好。


1
谢谢duskwuff,这正是我在寻找的答案 :) - Evan Byrne
9
Suhosin有许多功能,我希望有人能告诉我哪些功能已被整合到PHP的后续版本中,哪些功能未被实现,这样我会感觉更加安心。-1(抱歉,总觉得这样做不好)。请参考以下链接获取Suhosin功能列表:http://www.hardened-php.net/suhosin/a_feature_list.html - artfulrobot
1
Suhosin是一个补丁和扩展程序。您可以在没有补丁的情况下使用该扩展程序,并获得额外的保护和安全功能,这些功能甚至在原始的PHP(甚至在5.4中)中也不存在。 - MV.

7

如果您无法禁用eval()(语言结构,而非函数)或在eval内部设置黑名单以禁用大部分黑客工具箱,则您正在运行一大批不可抗拒的带宽,这对寻找带宽来运行其有效载荷的黑客来说非常吸引人。理想情况下应该列出哪些黑名单,但并非总是可行,因为第三方模块编写者甚至框架核心都依赖于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)的示例,它们将通过任何易受攻击的第三方模块或站点用户帐户感染您的站点。

RATS可以采取多种形式,其中一些很容易进行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目录不能在源代码控制中,因此也无法跟踪。)

顺便提一下:PHP 5.5会通过发出弃用警告来自动提示您何时使用/e。 - NikiC
2
虽然你禁用 eval 的理由很有道理,但它忽略了一个更明显的观点:过滤用户输入和保护服务器访问——如果黑客无法通过 eval 注入代码,他们就无法使用 eval。了解如何白名单输入并使用适当的输出编码比黑名单常用语言特性更广泛地有用于安全概念。 - Mark Fox
哈哈,我的防病毒软件在这个网站上发出警报,说它有PHP/Obfuscated.E。所以这就是原因。 - alexia

1

在我看来,duskwuff上面的陈述并不具有权威性,也不一定正确(特别是考虑到自那以后新版本的PHP所见到的关键漏洞数量)。

在我的观点中,如果Suhosin适用于当前的PHP版本,从安全角度来看,肯定会更好。 当然,由于它不可用,停留在旧的(最终未维护的)PHP版本也不是一个解决方案。

通常,PHP尤其是PHP应用程序因存在安全问题而臭名昭著...因此问题不在于"没有Suhosin的新版本PHP是否安全"...


6
这些批评没有任何证据或理由支持,只是一些泛泛而谈的“FUD”(即恐惧、不确定性和怀疑),“既不具有权威性也不一定正确”的说法明显适用于此回答,尤其是在本页面上。 - Mark Fox

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接