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.

Basic Plone system resources

To run Plone web site you need

* Some kind of machine (preferably Unix server, Windows works too) which is connected to Internet 24/7

* Ability to run arbitary daemon (background) processes on the server
* Ability to open arbitary ports. Zope wants to open its own port for incoming requests.
* Shell account for installing Plone + Zope and running control software

One could say that you need server root privileges to run Plone, though it’s technically possible without root privileges if the web hosting provider co-operates with you. Also, Plone gulps quite much RAM memory. Read more about it below. You might want to use virtual server, real server or Zope specific host company to run Plone web site, since most low end web hosting solutions don’t provide enough flexibility to run Plone. Google for “plone hosting” or “zope hosting”. One example company providing resourceful Zope hosting in Europe is Nidelven IT.

Plone performance measuring and caching

Plone doesn’t use any CPU when no pages are being loaded (in idle state).

When a page is being loaded, CPU usage maxes out to 100% per thread.

Because Plone CPU usage varies with the load, it’s useful to requets per seconds metric instead of CPU usage % to measure how much load the system can take.

Caching

Caching means that instead of regenerating the web page for each individual request, an old copy is kept lying around in memory/on disk and is served for consequent requests. Since the same once generated data is recycled, we improve performance by not going a long process of fetching data from a database, fitting it into page templates and finally converting to HTML.

Without caching, Plone is not suitable for heavy traffic sites (more than few visitors per minute).

Static caching

Here I use term ‘static caching’ for a method where the whole site is kept in the cache and real-time modified content is available for certain users only. This method is suitable for company web pages and other, closed, non-interactive content.

Pros

* Very easy to set-up
* Very efficient

Cons

* The site cannot have dynamic content (e.g. discussion) or other content which anyone could update

The easiest way to do static caching is to put a front end server at the front of Plone. The front end server takes all requests and caches them over a certain time period until it fetches new content from the server.

The most popular ways are using Apache web server’s mod_proxy module and Squid proxy.

With Apache 2 caching site content using mod_proxy, speed increase drastically (x 100). This is because pages are served directly from memory cache, instead of being regenerated each time a request is made. You should find plenty of tutorials from plone.org/documentation and Google how to put Apache 2 to the front of Zope to cache requets.

Also, Apache’s mod_deflate plug-in can used to GZip compress HTML, JS and CSS code before sending it over the wire. Most of desktop web browsers support GZip’ed content. This decreases bandwidth requirements, since HTML and other text based content compresses well.

Dynamic caching

Plone 2.5 ships with an add-on product called Cache Fu. Cache Fu allows fine tuned control of caching

* Caching only static items with a front end cache (Apache/Squid)
* Increasing Zope database performance by tuning internal database object caches
* Setting HTTP headers so that user web browsers itself cache the content propeply

Pros

* Propeply set up Cache Fu ensures that live content is always up-to-date (thus, the name dynamic caching), but static content is served at the maximum possible speed

Cons

* Setting up Cache Fu needs insight to HTTP request mechanisms and Plone internals

For more information see the documentation supplied with Cache Fu.

Note that Zope doesn’t reserve all memory on boot up. You need to browse around the site to make page loads and you can see memory usage increasing (until every page is load).

Spikes and Python memory management

When you upload a big content object (e.g. a high resolution image) Python memory usage spikes up since Python needs to allocate memory for processing the image. This image might not never freed back to the system and thus task manager utilities like top report Python to plenty of memory. However, this memory is not actively used and it’s swapped out. Read more about Python memory allocation.

Zope packing

Zope database stores information for all object revisions (each edit, delete) for undoing changes. Unless you want to have ability to track down each change, you can pack Zope database now and then to decrease it’s size. It can be done via Zope management interface control panel.

Source :

Other Information

• Pagerank 5.0
• Alexa rank :  614,454
• Amnesty International
  Fabian Kaspar, Erlachstrasse 16b
  CH-3012 Bern,
  SWITZERLAND
• info@amnesty.ch

The Plone Foundation proudly announces the members of the newly formed Plone 4 Framework Team:

David Glick is a web developer for ONE/Northwest, a Seattle-based consultancy that delivers tools and strategies for engaging people in protecting the environment.  He has been contributing to Plone add-on products and the Plone core for the past year, and is currently helping to build Dexterity, a tool for creating content types through the web.

Calvin Hendryx-Parker is co-founder and Director of Engineering for Six Feet Up, a CMS consulting company headquartered in the Indianapolis, Indiana. Calvin specializes in implementing Zope and Plone systems and has spoken frequently at symposia and conferences on Plone architecture and implementation.

Martijn Pieters is Senior Software Developer at Jarn, a longtime Plone consultancy. He’s been developing with and for Plone, Zope and Python since 1999. He has been involved with core development on the whole stack, from ZPT and ZODB via CMF to Plone itself.

Ross Patterson is an independent Plone developer and consultant in California.  He’s been developing with Zope and Plone for 9 years making contributions to various parts of the stack but mostly contributing add-ons and utilities.

Erik Rose is a core developer at WebLion, Penn State University’s internal Plone consultancy. He has written several popular Plone products—including FacultyStaffDirectory, WebServerAuth, and CustomNav—and spoken at Plone conferences about security, software architecture, and documentation.

Laurence Rowe works as a Software Developer for Jarn AS, Norway. He’s been consulting with Plone for 4 years, mostly focused around Systems Integration.

Matthew Wilkes is a Plone developer based in Bristol, in south-west England. As well as working a 3 day week at Team Rubber, he works as a freelance consult as Circular Triangle and spends the rest of his time reading German at Bristol University.

The new framework team was selected unanimously by a panel of current and past framework team members.

The job of the Plone 4 Framework Team is to evaluate, recommend, test and accept Plone Improvement Proposals (PLIPs) for version 4.0 of Plone, a versatile and popular open-source Content Management System based on Python and Zope. They’ll be working alongside the Plone 3 Framework Team, which will continue to incrementally develop the Plone 3.x series.

Plone is released under the GNU General Public License (GPL) and is designed to be extensible. Major development is conducted periodically during special meetings called Plone Sprints. Additional functionality is added to Plone with Products, which may be distributed through the Plone website or otherwise. The Plone Foundation owns and protects all copyrights and trademarks. Plone also has legal backing from the council of the Software Freedom Law Center.

The name Plone is an homage to the Warp Records band Plone, whose music is both simple and playful. The logo represents collaboration with three dots together in a group.

MediaWiki’s “Monobook” layout is based partially on the Plone style sheets.

History

The Plone project was begun in 1999, by Alexander Limi, Alan Runyan, and Vidar Andersen. It was made as a usability layer on top of the Zope Content Management Framework. The first version was released in 2001. The project quickly grew into a community, receiving plenty of new add-on products from its users. The increase in community led to the creation of the annual Plone conference in 2003, which is still running today. In addition, “sprints” are held, where groups of developers meet to work on Plone, ranging from a couple days to a week. In March 2004, Plone 2.0 was released. This release brought more customizable features in Plone, and enhanced the add-on functions. In May 2004, the Plone Foundation was created for the development, marketing, and protection of Plone. The Foundation has ownership rights over the Plone codebase, trademarks, and domain names. Even though the foundation was set up to protect ownership rights, Plone remains open source. In March 12, 2007, Plone 3 was released. This new release brought inline editing, an upgraded visual editor, and strengthened security, among many other enhancements. Up to September 2007, there have been over 200 developers contributing to Plone’s code. Plone won two Packt Open Source CMS Awards.

Design

Plone is built on the Zope application server, which is written in Python. Plone is made such that all information stored in Plone is stored in Zope’s built-in transactional object database (ZODB). Plone comes with installers for Windows, Mac OS X, and Linux, along with other operating systems. New updates are released regularly on Plone’s website. Plone is available in over 35 languages. Its interface follows the government standard WAI-AAA and U.S. section 508, which allows people with sight disabilities to properly access and use Plone. A major part of Plone is its use of skins and themes. When working with Plone, templates can be used to customize a website’s look. These templates are written with Cascading Style Sheets. In addition, Plone comes with a user management system called Pluggable Authentication Service. Introduced in Plone 2.5, “PAS” is used to properly sort actions from different users to their respective folders or accounts. PAS is also used to search for users and groups in Plone. Most importantly, PAS covers the security involved for users, requiring authentication in order to login to Plone. This gives users an increase in both security and organization with their content. A large part of Plone’s changes have come from its community. Since Plone is open source, the members of the Plone community regularly make alterations or add-ons to Plone’s interface, and make these changes available to the rest of the community via Plone’s website.

Community

Since its release, many of Plone’s updates and add-ons have come from its community. Events called Plone “sprints” consist of members of the community coming together for a week and helping improve Plone. The Plone conference is also attended and supported by the members of the Plone community. In addition, Plone has an active IRC channel to give support to users who have questions or concerns. Up through 2007, there have been over one million downloads of Plone. Plone’s development team has also been ranked in the top 2% of the largest open source communities.

Strengths and weaknesses

Plone excels when compared to other content-management systems in standards conformance, access control, internationalization, aggregation, user-generated content, micro-applications, active user groups and value. It’s available on many different operating systems, due to its use of platform-agnostic underlying technologies such as Python and Zope. Plone’s Web-based administrative interface is optimized for standards, allowing it to work with most common web browsers, and uses additional accessibility standards to help users who have disabilities. All of Plone’s features are customizable, and free add-ons are available from the Plone website.

Plone has an excellent security record compared to other popular content management systems.

Plone’s weaknesses include Python and Zope experience requirements for those wishing to add or extend the feature set, making for a considerable learning curve for developers. Plone has been rated as lagging in repository services when compared to other major CMSs.

Features

These are some of the features available in Plone 3.0:

• Inline editing
• Working Copy support
• Link and reference integrity checking
• Automatic locking and unlocking
• Collaboration and sharing
• Versioning, history and reverting content
• Upgraded visual HTML editor
• Workflow capabilities
• Authentication back-end
• Full-text indexing of Word and PDF documents
• Collections
• Presentation mode for content
• Support for the search engine Sitemap protocol
• Support for multiple mark-up formats
• Wiki support
• Automatic previous/next navigation
• Rules engine for content
• Auto-generated tables of contents
• Portlets engine
• Support, development, hosting & training
• LiveSearch
• Multilingual content management
• Time-based publishing
• Human-readable URLs
• Powerful graphical page editor
• Navigation and updated site maps
• Resource compression
• Caching proxy integration
• Drag and drop reordering of content
• XML exports of site configurations
• Localized workflow configuration
• Adjustable templates on content
• Standard content types
• Content is automatically formatted for printing
• Standards-compliant XHTML and CSS
• Accessibility compliant
• RSS feed support
• Automatic image scaling and thumbnail generation
• Free add-on products
• Cross-platform
• Comment capabilities on any content
• Microformat support
• Installer packages for multiple platforms
• WebDAV and FTP support
• In-context editing
• Backup support
• Cut/copy/paste operations on content

Other Information

• Developed by  Alan Runyan, Alexander Limi, Vidar Andersen and the Plone Team
• Latest release  3.1.7 / #REDIRECT Template:Start date and age
• OS  Cross-platform
• Platform  Zope
• Type  Content management system
• License  GNU General Public License
• Website  http://plone.org/