apache模块与cgi（关于安全性）之间有区别吗？
例如使用mod_php而不是php-cgi更安全吗？ 或者使用 mod_perl 而不是传统的 cgi-scripts 更安全？
我主要对安全问题感兴趣，但如果存在显着差异，速度可能是一个问题。
E.g. Is it more secure to use mod_php instead of php-cgi?
Or is it more secure to use mod_perl instead of traditional cgi-scripts?
I'm mainly interested in security concerns, but speed might be an issue if there are significant differences.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
使用内置模块肯定会比使用 CGI 更快。 安全影响取决于配置。 在默认配置中，它们几乎相同，但 cgi 允许一些内置模块无法提供的更安全的配置，特别是在共享托管的上下文中。 您究竟想保护自己免受什么侵害？
Using a builtin module is definitely going to be faster than using CGI. The security implications depend on the configuration. In the default configuration they are pretty much the same, but cgi allows some more secure configurations that builtin modules can't provide, specially in the context of shared hosting. What exactly do you want to secure yourself against?
来自 PHP 5.2.6 的 PHP install.txt 文档：
服务器模块提供了显着更好的性能和额外的功能
与 CGI 二进制文件相比的功能。
对于 IIS/PWS：
警告
通过使用 CGI 设置，您的服务器对多种可能的情况开放
攻击。 请阅读我们的 CGI 安全部分以了解如何防御
自己免受这些攻击。
From the PHP install.txt doc for PHP 5.2.6:
Server modules provide significantly better performance and additional
functionality compared to the CGI binary.
For IIS/PWS:
Warning
By using the CGI setup, your server is open to several possible
attacks. Please read our CGI security section to learn how to defend
yourself from those attacks.
mod_php 或 FastCGI 之类的模块比普通 CGI 快得多。只是不要使用 CGI。 正如其他人所说，PHP 程序本身是最大的安全威胁，但忽略了还有另一个考虑因素，即在共享主机上。
如果您的脚本与其他 php 程序位于共享主机上，并且该主机未在安全模式下运行，那么所有服务器进程很可能都以同一用户身份运行。 这可能意味着任何其他 php 脚本都可以读取您自己的脚本，包括数据库密码。 因此，请务必调查服务器配置，以确保其他人无法读取您的代码。
即使您控制自己的托管，请记住服务器上的另一个被黑客入侵的 Web 应用程序也可能成为进入其他应用程序的渠道。
A module such as mod_php or FastCGI is incredibly faster than plain CGI.. just don't do CGI. As others have said, the PHP program itself is the greatest security threat, but ignoring that there is one other consideration, on shared hosts.
If your script is on a shared host with other php programs and the host is not running in safe mode, then it is likely that all server processes are running as the same user. This could mean that any other php script can read your own, including database passwords. So be sure to investigate the server configuration to be sure your code is not readable to others.
Even if you control your own hosting, keep in mind that another hacked web application on the server could be a conduit into others.
大多数安全漏洞的发生都是由于脚本本身的糟糕编程造成的，因此如果它们作为 cgi 或模块运行，那就真的没有实际意义了。 也就是说，apache 模块可能会导致整个 Web 服务器崩溃（特别是使用线程 MPM 时），而 mod_php 正是因此而闻名。
cgi会慢一些，但是现在有解决方案，主要是FastCGI和朋友。
您的威胁模型是什么？
Most security holes occur due to lousy programming in the script itself, so it's really kind of moot if they are ran as cgi or in modules. That said, apache modules can potentially crash the whole webserver (especially if using a threaded MPM) and mod_php is kind of famous for it.
cgi will be slower, but nowadays there are solutions to that, mainly FastCGI and friends.
What is your threat model?
如果您运行自己的服务器，请采用模块方式，速度会更快一些。
如果您使用的是共享服务器，那么通常是在 CGI 方面已经为您做出了决定。 其原因是文件系统权限。 PHP 作为一个模块以 http 服务器（通常是“apache”）的权限运行，除非您可以 chmod 您的脚本到该用户，否则您必须将它们 chmod 为 777 - 世界可读。 唉，这意味着您的服务器邻居可以查看它们 - 想想您存储数据库访问密码的位置。 大多数共享服务器已经使用 phpsuexec 之类的东西解决了这个问题，这些东西在脚本所有者的权限下运行脚本，因此您可以（必须）将代码更改为 644。 Phpsuexec 仅使用 PHP 作为 CGI 运行 - 这或多或少是全部，这只是本地机器的事情 - 对整个世界没有任何影响。
If you run your own server go the module way, it's somewhat faster.
If you're on a shared server the decision has already been taken for you, usually on the CGI side. The reason for this are filesystem permissions. PHP as a module runs with the permissions of the http server (usually 'apache') and unless you can chmod your scripts to that user you have to chmod them to 777 - world readable. This means, alas, that your server neighbour can take a look at them - think of where you store the database access password. Most shared servers have solved this using stuff like phpsuexec and such, which run scripts with the permissions of the script owner, so you can (must) have your code chmoded to 644. Phpsuexec runs only with PHP as CGI - that's more or less all, it's just a local machine thing - makes no difference to the world at large.
什么意义上的安全？ 不管怎样，这实际上取决于正在运行的脚本以及它的编写情况。 现在有太多的脚本都是半途而废的，并且没有正确地进行输入验证。
与 mod_php 相比，我个人更喜欢 FastCGI，因为如果 FastCGI 进程终止，将会生成一个新进程，而我已经看到 mod_php 杀死了整个 Apache。
至于安全性，使用 FastCGI 从技术上讲，您可以在与默认 Web 服务器用户不同的用户下运行 php 进程。
另外，如果您正在使用 Apache 的新工作线程支持，您将需要确保您没有使用 mod_php，因为某些扩展不是线程安全的，并且会导致竞争条件。
Security in what sense? Either way it really depends on what script is running and how well it is written. Too many scripts these days are half-assed and do not properly do input validation.
I personally prefer FastCGI to mod_php since if a FastCGI process dies a new one will get spawned, whereas I have seen mod_php kill the entirety of Apache.
As for security, with FastCGI you could technically run the php process under a different user from the default web servers user.
On a seperate note, if you are using Apache's new worker threading support you will want to make sure that you are not using mod_php as some of the extensions are not thread safe and will cause race conditions.