Drupal 的安全性与 Plone 相比如何？
Drupal 的安全性与 Plone 相比如何？
注意：
如果比较包括 Drupal 的 V.7 和 Plone 的 V.4，那就太好了。
谢谢
How does Drupal's security compare to Plone's?
Note:
It will be great if the comparison includes V.7 for Drupal and V.4 for Plone.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这里很好地概述了 Plone 如何处理 Web 应用程序世界中的十大安全问题：
http:// /plone.org/products/plone/security/overview
FBI、CIA 和欧洲网络与信息安全局 (ENISA) 等组织都在使用 Plone（如果有迹象表明的话）。
Plone 在所有主要 CMS 中拥有最好的安全记录，我们对此非常重视。我们拥有一个围绕沙箱、适当的 ACL 和强大的安全模型构建的架构。
Drupal 的安全记录非常糟糕（请参阅另一条评论中引用的 CVE 数字），其他两个主要的基于 PHP 的框架（Wordpress 和 Joomla）也是如此。 Plone 是基于 Python 的，但您可能已经知道了。
Plone 使编写安全的附加组件变得更加容易，因为我们有一个适当的安全模型，使得编写本质上不安全的代码变得非常困难。这与任何其他系统不同，也是另一个核心差异化因素。
（是的，这个答案有偏见，我是创始人之一；）
There's a good overview of how Plone handles the top 10 security issues in the web app world here:
http://plone.org/products/plone/security/overview
Organizations like the FBI, CIA and European Network and Information Security Agency (ENISA) all use Plone, if that is an indication.
Plone has the best track record in security of any major CMS, and we take it very seriously. We have an architecture that is built around sandboxing, proper ACLs and a powerful security model.
Drupal has a pretty horrible security record (see the CVE numbers quoted in another comment), as do the other two major PHP-based frameworks (Wordpress and Joomla). Plone is Python-based, but you probably know that already.
Plone makes it easier to write secure add-ons, since we have a proper security model that makes it pretty hard to write code that is inherently insecure. This is different from any other system out there, and is another core differentiator.
(And yes, this answer is biased, I'm one of the founders ;)
在这两种情况下，主框架的安全性都相当可靠；问题几乎总是出现在附加模块中，因此您需要单独评估计划使用的每个模块。
The security of the main framework is pretty solid in both cases; the problems are almost always found in the add-on modules, so you need to evaluate each module you plan to use individually.
在搜索“CVE”官方常见漏洞数据库时，您会得到以下数字：
最近3年：plone 8，drupal 282。
最近3个月：plone 0，drupal 9
plone的基本架构显然更加安全。事实上，我不知道drupal，但我知道plone。不存在 sql 注入错误，因为其背后有一个非 sql 对象数据库。基本上，它是一个长时间运行的 python 程序，而不是 PHP 脚本，这使得更容易拥有一个更难以破坏或误处理的良好可靠的安全机制。
（注：我只是在 http://web.nvd.nist 上进行了简单的关键字搜索。 gov/view/vuln/search 并不是我看到的所有 drupal 结果都可以归因于 drupal，似乎有一些操作系统级别的漏洞以某种方式出现在搜索结果中。
When searching the "CVE" official common vulnerabilities database, you get the following figures:
Last 3 years: plone 8, drupal 282.
Last 3 months: plone 0, drupal 9
The basic architecture of plone is apparently much more secure. I don't know drupal, actually, but I do know plone. There are no sql injection bugs as there's an non-sql object database behind it. It is a long-running python program, basically, instead of PHP scripts, which makes it easier to have a good solid security mechanism that's harder to break or mis-handle.
(Note: I just did a simple keyword search at http://web.nvd.nist.gov/view/vuln/search . Not all the results I see for drupal can be attributed to drupal, there seem to be some os-level vulnerabilities that somehow show up in the search results).
很难在同等指标上比较 Plone 和 Drupal。 CVE 并不是最终的比较，而且作为软件相对安全性的指示，它的价值甚至是有争议的。在这 282 个 Drupal CVE 中，有多少是针对 Drupal 核心的？不是 282。limi
可以辩称该架构更安全，并指出 Plone 对 OWASP 前十名的回应。 Drupal 也可以做同样的事情。还有“谁使用它”的争论？嗯，whitehouse.gov 使用 Drupal，以及大量其他政府和“企业”组织。
It's difficult to compare Plone and Drupal on equal metrics. CVEs is not the end-all comparison, and it's arguable how valuable it even is, as an indication of the relative security of the software. Of those 282 Drupal CVEs, how many were for Drupal core? Not 282.
limi can argue that the architecture is more secure, and point to Plone's response to the OWASP Top Ten. Drupal can do the same. And the "who uses it" argument? Well, whitehouse.gov uses Drupal, as well as a large number of other governmental and "enterprise" organizations.
使用 Drupal 的开发人员数量增加了几个数量级；发现的漏洞数量较多也很容易归因于更多的人费心寻找它们。这些统计数据很容易通过默默无闻来保证安全。
There are several orders of magnitude more developers using Drupal; the higher numbers of vulnerabilities found can just as easily be attributed to more people bothering to look for them. These stats could easily be security by obscurity.