PHP 安全模式替代方案

发布于 2024-12-12 01:04:42 字数 513 浏览 0 评论 0原文

从 5.3.0 开始,安全模式已被弃用。我从来没有真正需要过它,而是因为权限错误等原因在过去多次发现它有问题。

但是我现在有一个要求,我认为安全模式会做得很好。

我构建了一个可通过模块扩展的网络应用程序。我计划自己托管该系统,并允许付费客户通过实现和编写连接到系统各个部分的模块来扩展他们的软件。

我担心的是,通过这样做,我无法确保他们上传的代码不会扫描我花了数年时间设计和测试的基础/框架。保持代码专有性对我来说非常感兴趣。

  1. 我编写了一个模块分析工具,以确保第三方模块中没有调用非法方法 - 不容易!!!

  2. 我在 php.ini 级别禁用有害函数,但这包括 fopen() 及其同类 - 这意味着框架将无法调用它自己的 include() 操作等。

  3. 最后,遗憾的是,安全模式限制用户模块能够读取不共享相同 ID、组等的文件。

对于这种情况,推荐的方法是什么?在我的框架上下文中执行之前,是否缺少手动检查或自动分析每个模块?

Safe Mode is deprecated as 5.3.0. I have never really required it and rather found it problematic many times in the past due to permission errors, etc.

However I now have a requirement where I think safe mode would have done great.

I have built a web application which is extensible via modules. I plan on hosting the system myself and allowing paying customers to extend their software by implementing and writing modules which hook into the various parts of the system.

My concern is, by doing so, I have no way of ensuring the code they uploaded is not scanning the foundation/framework I have spent literally years designing and testing. Keep the code proprietary is of great interest to me.

  1. I write a module analysis tool to ensure no illegal methods are being invoked in third party modules - not easy!!!

  2. I Disable harmful functions at the php.ini level but this includes fopen() and it's ilk - this means the framework won't be able to call it's own include() operations and such.

  3. Lastly and sadly obsolete, safe mode to restrict user modules from being able to read files which do not share the same ID, group, etc.

What is the recommended approach to such a thing? Short of manually reviewing or auto-analysing each module before being executed in the context of my framework?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

就像说晚安 2024-12-19 01:04:42

safe_mode 被删除是一件好事。这是一种错误的安全感,并且有很多方法可以绕过它。

更好的方法是使用 suphp 以被监禁的用户身份运行您的应用程序。这利用操作系统的安全性来保护您的应用程序。您可以将 php 代码作为无权访问 shell 的帐户运行,而不是禁止 exec()system()。您可以通过 chmod 500 -R / 删除该用户拥有的所有内容的写入权限,而不是禁止 fopen()。或者更进一步,在 chroot 中运行您的应用程序。

Its a good thing that safe_mode is being removed. Its a false sense of secuirty, and there have been many ways to bypass it.

A better approach is use suphp to run your application as a jailed user. This uses the security of the operating system to protect your application. Instead of banning exec() and system(), you run your php code as an account that doesn't have access to a shell. Instead of banning fopen() you remove write privileges from everything owned by that user chmod 500 -R /. Or go a step further and run your application within a chroot.

羞稚 2024-12-19 01:04:42

您可以使用带 chroot 的 php-fpm、mod_ruid 和 php-fpm 中的每个用户权限以及 php 中的 opendir 限制,而不是安全模式。通过这种方式,您可以使其比安全模式更加严格。

就我个人而言,我会推荐 php-fpm 与 chroot 并禁用 exec 和 system 等系统功能。无论如何,这些都是邪恶的。

Instead of safemode, you can use php-fpm with chroot, per user permissions in mod_ruid and php-fpm, and opendir restriction in php. This way, you can make it much more strict then safe mode could ever.

Personally, I would recommend php-fpm with chroot and disabling system functions like exec and system. Those are evil anyway.

滿滿的愛 2024-12-19 01:04:42

我在 /etc/php/7.0/fpm/php.ini 中使用 open_basedir 绕过安全模式

I use open_basedir in /etc/php/7.0/fpm/php.ini which bypasses safe mode

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文