Below is a list of the 10 most common security vulnerabilities in web applications, and how Plone addresses these. The full background for this list can be found at the Open Web Application Security Project web site.

Problem A1: Unvalidated Input

How Plone handles this: All input in Plone is validated, and the framework makes sure you can never input data that is not of the required type. This is probably the number one reason why Plone sites — even when deployed and developed by people new to web security — are not compromised.

Problem A2: Broken Access Control

How Plone handles this: Plone is based on the well-proven (7 years in production), flexible and granular ACL/roles-based security model of Zope. In addition, Plone utilizes an innovative workflow approach to security, which means that end-users never see or modify the security settings — they only work with security presets that have been supplied to them by the developers of the application. This makes the potential for security errors orders of magnitude less likely to happen.

Problem A3: Broken Authentication and Session Management

How Plone handles this: Plone authenticates users in its own database using a SHA-1 hash of their password. Using its modular authentication system Plone can also authenticate users against common authentication systems such as LDAP and SQL as well as any other system for which a plugin is available (Gmail, OpenID, etc.). After authentication, Plone creates a session using a SHA-1 hash of a secret stored on the server and the userid (HMAC-SHA-1). Secrets can be refreshed on a regular basis to add extra security where needed. Note: Older Plone versions (i.e. before Plone 3) use a less secure method where a session cookie containing both the loginname and password for a user are used. It is highly recommended to enforce use of HTTPS encryption for such sites.

Problem A4: Cross Site Scripting

How Plone handles this: Plone has strong filtering in place to make sure that no potentially malicious code can ever be entered into the system. All content that is inserted is stripped of malicious tags like <script>, <embed> and <object>, as well as removing all <form> related tags, stopping users from impersonating any kind of HTTP POST requests. All destructive operations (like deletion of content) and privilege elevation (roles, permissions) are checked to be valid HTTP POST request in addition to the usual security checking. On an infrastructure level, the template language used to create pages in Plone quotes all HTML by default, effectively preventing cross site scripting.

Problem A5: Buffer Overflow

How Plone handles this: Buffers overflow vulnerabilities are not known to exist in the current versions of Python, and is usually more common in systems based on languages that do not have strict checking for this, like C.

Problem A6: Injection Flaws

How Plone handles this: This is usually common in systems that use SQL for its content storage. Plone does not use SQL by default, and when setting up SQL databases with Plone, they always communicate through a standard SQL connector that neutralizes injection attempts automatically.

Problem A7: Improper Error Handling

How Plone handles this: Plone provides almost information on the front end (no stack traces etc) when there is an error, but logs the error internally instead. All the front-end user will see is the log entry number of the error that was caused, allowing the error to be located in the logs if it is reported to the site admin.

Problem A8: Insecure Storage

How Plone handles this: All the cryptographic methods in use in the Plone stack are been exposed to public scrutiny for years, and have no known vulnerabilities.

Problem A9: Application Denial of Service

How Plone handles this: The most common setup for a Plone site is to utilize a caching proxy like Squid, Varnish, Apache or IIS. When configured in this way, it’s very hard to bring down a Plone site with DoS attacks. (Note: In versions earlier than Plone 2.1.4 and 2.5.1, there was a potential Denial of Service attack identified in the error page of Plone, which was unnecessarily heavy. This was fixed as part of a bigger security audit performed in the same timeframe, and the current releases of Plone do not suffer from this problem.

A10 Insecure Configuration Management

How Plone handles this: Plone has very strict security defaults out-of-the-box, and also runs as an unprivileged user on the server. Web users do not have access to the file system. Because of these factors, the most common security configuration vulnerabilities in this area are avoided.

Security track record

Measuring or quantifying security risks in software is hard — security is a process, not a product, and thus requires constant vigilance and good coding practices combined with security reviews. One interesting measure is the number of vulnerabilities reported by the MITRE’s Common Vulnerabilities and Exposures database, which is the main source for tracking and naming security issues.

Here are some counts of the numbers of known vulnerabilities and exposures in some common CMS platforms and their technology stacks – also note that the Python/Zope/Plone stack has existed for several years longer than the others mentioned:

• Plone/Zope/Python stack:
  • CVE Entries containing Plone: 3
  • CVE Entries containing Zope: 15 (only 3 since 2004)
  • CVE Entries containing Python: 17
• PHP-based stacks:
  • CVE Entries containing Drupal: 22
  • CVE Entries containing Mambo: 31
  • CVE Entries containing Joomla: 20
  • CVE Entries containing MySQL: 99
  • CVE Entries containing PHP: 1258
• Other stacks:
  • CVE Entries containing Perl: 97

These numbers do not prove anything by themselves, of course — but do suggest a general trend, and are a good approximation of our security track record compared to other systems.

Drupal has announced that there will be no new features added to 6.x or 5.x. They are holding the feature updates and implementation of new features until they are ready to release Drupal 7.x in the near future.

A 7th security update for version 6 and the 13th security update for version 5 may not mean a whole slew of new features, but they do address major security issues.

Security Issues

In both versions there are potential vulnerabilities to users for creating cross site request forgeries as well as cross site scripting. Both of these vulnerabilities could potentially result in database damage or unfiltered content being published inadvertently.

Whether you are using Drupal 6.x or Drupal 5.x, it is highly recommended by the community to update to the newest version to eliminate the potential for security infringements.

There are two options to upgrade:.
Patching or Upgrading Current Drupal Versions

The first option for updating your Drupal version 5.x or 6.x is to simply patch your current core files with the updated ones. This is not the best option as the patch files do not contain certain bug fixes.

The second and best option is to do a full upgrade. This will ensure that all security fixes and bug fixes are addressed in your particular core code. You will also be better prepared for the Drupal 7 update which is expected to contain a number of new features.

It is also highly recommended that you run update.php to refresh the menu cache and other website caches. If you are using custom .htaccess or robot.txt files, you will want to make sure that any custom changes are retained since the updates modify both of these files.

Full upgrade files and patch files can be found here:

* Drupal 5.13 upgrade files
* Drupal 6.7 upgrade files
* Drupal 5.13 patch files
* Drupal 6.7 patch files

If you are using PHP 5.1.x or lower there is a warning that comes up upon login. According to the Drupal Community, “That patch has been rolled back in CVS, and we will be doing a bug fix release on December 11th.”
Get Ready for Drupal 7

Want new Drupal features? You’ll have to wait for Drupal 7 to be released. Until then get the upgrade files and ensure that your site is secure against the malicious threats described above.

If you are interested in learning more about Drupal, DrupalCon DC, the premier conference for Drupal developers, is right around the corner in March. While final submissions for sessions is over, tickets are still available. Get yours today and learn all the ins and outs of Drupal.

CMSWire

Over the past few years, eZ Systems have made a name for themselves with eZ Publish, their open source content management software. They hit the 2.5 million download mark earlier this year, and show no signs of slowing down. As announced last week, eZ Publish is a finalist for Packt Publishing’s 2008 Open Source CMS Awards. It’s an honor to be nominated, goes the old saying, but it’s even better to win, and voting on Packt Publishing’s website is open until mid October.

In addition to the free open-source version of their content management software, eZ Systems offers a number of licensing options, some of which include a technical support subscription. That’s apparently where the bulk of their revenue comes from, and they announced this past week that they enjoyed 583% growth in new subscription sales with a renewal rate of over 90% for the first half of 2008. These are incredible numbers and have given eZ Systems two profitable quarters in a row, their first ever.

Finally, I wanted to mention the release of eZ Publish 4.0.1, 3.10.1, and 3.9.5, various versions of their flagship content management system. Although they include just a handful of enhancements, these releases focus mainly on addressing some security issues and bug fixes, reportedly over 300 for eZ Publish 4.0.1 alone.

eZ Publish is a solid, well-regarded platform with a substantial user community, and is certainly worth a look for organizations considering an open source content management system. And 2.5 million downloads is pretty convincing, too.