Whitepaper "Selecting a secure Open Source CMS"

Posted on August 03, 2009 by .

In the last week, ZION Security - a company that is "securing web applications" -  has published a whitepaper on "Selecting a secure Open Source Content Management System".

In my opinion, some information is missing in this document, some information is wrong.

Following are my personal comments (page-based on the PDF):

 

PAGE 5:

Drupal - "High quality platform"
This positive criteria is only mentioned for Drupal. As reader I'm asking myself what does this exactly means and why only Drupal qualifies for it.


Drupal - Extensive documentation
TYPO3 also offers extensive Core documentation. Please have a look at
http://typo3.org/documentation/document-library/core-documentation/!


Drupal - Real multi-site-feature
This is a default core feature in all currently supported TYPO3 versions, too.
(1 installation in file system manages different domains)


Drupal - Powerful templating system. Any [...] template can be easily converted to Drupal.
IMHO, the easiest solution in TYPO3 is by using the widely known TemplaVoila extension. With an existing layout - one HTML file with referenced css/js files - and sample content on it, it's a matter of minutes to create a basic "mapping". There's no need to modify this html document, it just needs to be uploaded as is. With a wizard you decide which CMS records (menu, columns, teaser, etc..) are to be shown where. This is graphical based (TemplaVoila understands the html structure); you click on the sample content of the above mentioned html page and tell, what is generally to be displayed at this location.


TYPO3: missing ECMS features
All currently officially supported TYPO3 versions provide (aka "what makes TYPO3 different from the other CMS")

• versioning
• localization
• workspaces (different draft workspaces, live workspace)
• customizable publishing workflow ("copy the publishing process of printing media")
• tree-based website structure
• really extensive very granular user (rights) management
• clear separation between TYPO3 frontend (website as shown to website users) and TYPO3 backend (administration interface)
• extension management in TYPO3's administration interface (installing/upgrading extensions from the central TYPO3 extension repository [TER] is a matter of seconds; you don't have to manually download modules/extensions and to upload them to the website file system)

 

PAGE 6:

TYPO3 - development lifecycle for extensions is complicated
I cannot follow this argument at all. The only restriction in development lifecycle is the need to set version numbers of extensions.



PAGE 11f:
Any mentioned time offset between the disclosure of a vulnerability and
the available fix is completely wrong.
Example 1 - civserv extension:

• fix available: June 16, 2009 (ext:civserv v4.3.3)
• bulletin/advisory available: June 16, 2009 (TYPO3-SA-2009-007)

Fix and advisory have been published at the same time - I did it myself.


I guess the mentioned time offset is based on time difference between secunia's release date and last update (Secunia SA35479). I furthermore guess that on April 19, Secunia only added the CVE ID.

I'd really like to see this information fixed in the whitepaper. The whitepaper author failed to actually look up the mentioned example issues and is therefore publishing wrong data. Then you additionally have to slightly modify the red-box conclusion on page 20. 

To my knowledge - I can only say this for sure from beginning 2008 when I joined the Security Team - in the history of TYPO3 there was never a vulnerability disclosed before a security fix was available. Why that you might ask - choose one:

• security researchers don't care about TYPO3 (probably not)
• security researchers do contact us first (responsable disclosure)

I consider this to be a sign of appreciation. We're kindly working together with any vulnerability reporter, keep them up-to-date, give them proper credits. We communicate in a nicely way, reporters and extension developers do not hesitate to contact us in case of questions.
At conferences I often hear that the TYPO3 Security Team has a good reputation among the TYPO3 Community.

Here's a quote from a vulnerability reporter (employee of Raiffeisen Informatik Austria):
"The Typo3 Security Team were very quick to respond to the issue, and I found them very good to work with during the disclosure process. If only some larger companies were so easyto work with, and responsive."
(http://c22blog.wordpress.com/2009/01/20/typo3-weak-encryption-key/)

 

PAGE 15:
You're right about the password policy. Thanks for pointing to this problem. As a result of this whitepaper, this problem is about to be addressed in the near future.



PAGE 16:
In the TYPO3 Security Team website section there's a page that points to ressources about secure coding in regards to TYPO3.
http://typo3.org/teams/security/resources/

 

PAGE 20:
Quote: "[...] more importantly the vulnerabilities in Drupal have lesser impact when compared to TYPO3 and Joomla! vulnerabilities."
Well, it depends what kind of rating you apply. If you're using the Common Vulnerability Scoring System (CVSS) [the higher, the worse] and doing it for CMS Core only issues in 2008 it makes

• a total score of 167.2 for Drupal vs. 19.4 for TYPO3
• an average score of 5.57 for Drupal vs. 4.85 for TYPO3

Source: Comparison of PHP-based CMS

In the end I'd like to add that I'm not happy that the author is also considering third-party modules in this whitepaper (or at least the way the whitepaper author is mixing them up in the vulnerability issue examples). For TYPO3 and AFAIK also for Drupal, there are no restrictions in place that prevent uploads of insecure/insuffciently secure extensions/modules to the central third-party module repository. It's the Security Teams' task to keep the repositories safe.
I'd rather see a whitepaper on CMS Cores only.