Common Vulnerabilities vs. Plone

All about Plone's baked-in security

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: Injection

This is usually found in connections with databases as SQL Injection. As Plone does not use a SQL based database this is not possible. The database that Plone uses is not vulnerable to injection as it uses a binary format that cannot have user data inserted.

Problem A2: Broken Authentication and Session Management

Plone authenticates users in its own database using a SSHA 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-256 hash of a secret stored on the server, the userid and the current time. This is based on the Apache auth_tkt cookie format, but with a more secure hash function. Secrets can be refreshed on a regular basis to add extra security where needed.

Problem A3: Cross Site Scripting (XSS)

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. On an infrastructure level, the template language used to create pages in Plone quotes all HTML by default, effectively preventing cross site scripting.

Problem A4: Insecure Direct Object Reference

Plone has multiple levels of security to prevent internal objects from being accessible through the web. Objects following industry standards to mark them as implementation details are not exposed through the web. In addition, Plone has a fine-grained permissions infrastructure that allows objects to be marked as requiring certain access permissions, including developer only. Finally, Plone ships with a restricted Python environment that prevents code not explicitly allowed from being accessed by untrusted sources.

Problem A5: Security Misconfiguration

The Plone installer follows best practices when adding a Plone site to a server, isolating the Plone process from its configuration. Even if an attacker obtains administrator access to the Plone site they cannot use that to attack the server running Plone. Plone also provides no information on the front end (no stack traces etc) when there is an error, but logs the error internally instead.

Problem A6: Sensitive Data Exposure

As Plone is a content management system, it is not designed for hosting data that must remain inaccessible. Plone does, however, allow multiple levels of user who have access to different types of content, much of which may be sensitive. Plone can also be configured to only be accessible within an internal network, for storing data that shouldn't be exposed to the outside world. Credit card data and similar types of data should be stored in external, certified services. Plone has add-ons available to integrate with many such services.

Problem A7: Missing Function Level Access Control

Plone has function level access control built in at all levels. A typical Plone site has over one hundred different permissions defined and all functions must define that they are either unrestricted, for developers only, or associated with one of these permissions. Add-on products routinely define their own permissions for internal use. As Plone's workflow and access control systems are built on these access controls customising access levels is easily done.

Problem A8: Cross Site Request Forgery (CSRF)

Administration operations are checked to be valid HTTP POST request that contains a secret authentication token in addition to the usual security checking. These authentication tokens cannot be predicted by external entities. This makes CSRF impossible.

Problem A9: Using Components with Known Vulnerabilities

With each new release of Plone checks are made for new versions of the libraries and frameworks we depend on, such as Zope, as Python. The installers and build tools are updated to use these new versions immediately. In addition, fixes to severe security vulnerabilities in libraries are included in our thrice annual security fixes.

Problem A10: Unvalidated Redirects and Forwards

Plone uses the same functionality used for annotating links to external sites with icons to check that all redirects are to locations within the site. This takes into account the different virtual hosts and port settings of a particular deployment, so even forwards to external sites on the same domain won't be allowed.