Security

The security team supports the current and the previous major release. Currently, Plone 5.0 and Plone 4.3 are receiving security patches.

From https://plone.org/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. Yet we have never received a report of a serious vulnerability in Plone being exploited in the wild.

An important metric is the severity of vulnerability, as well as how widely they are exploited in the wild. We have only had reports of a few sites ever being hacked and these were all sites that hadn't installed an emergency security fix within 6 months of its release. Due to Plone's advanced sandboxing and security features most vulnerabilities only affect the site itself. Most vulnerabilities found in Plone do not expose sensitive information or allow access to the server. We have never received a report of a serious vulnerability in Plone being exploited in the wild.

Unfortunately, there are no trustworthy statistics on vulnerability numbers available. This is mostly due to the fact that security databases are often outdated or incomplete. That said, Plone consistently has fewer vulnerabilities reported on databases than other content management systems. As our security team diligently reports any vulnerabilities found and works with vendors such as Red Hat to ensure our reports are complete and accurate this is strong evidence for Plone's security."

Plone.org lists the common web vulnerabilities out there and how they are addressed in the Plone CMS:

1. Problem A1: Injection. How Plone handles this: 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.
2. Problem A2: Broken Authentication and Session Management. How Plone handles this: 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.
3. Problem A3: Cross Site Scripting (XSS). 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. On an infrastructure level, the template language used to create pages in Plone quotes all HTML by default, effectively preventing cross site scripting.
4. Problem A4: Insecure Direct Object Reference. How Plone handles this: 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.
5. Problem A5: Security Misconfiguration. How Plone handles this: 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.
6. Problem A6: Sensitive Data Exposure. How Plone handles this: 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.
7. Problem A7: Missing Function Level Access Control. How Plone handles this: 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 customizing access levels is easily done.
8. Problem A8: Cross Site Request Forgery (CSRF). How Plone handles this: 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.
9. Problem A9: Using Components with Known Vulnerabilities. How Plone handles this: 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.
10. Problem A10: Unvalidated Redirects and Forwards. How Plone handles this: 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.

Doug Vann

Drupal

Let’s face it…. Security is always important. But for the Drupal Community, it's obvious that very large sites are running on Drupal and much bigger sites are coming. We can’t afford a front page tech-crunch article on “Drupal’s big Oooops!” For that reason, we spend a lot of money and time on security. Since we are a huge community and our sites can cost 6 and 7 figures, we have big reasons to maintain security and a great deal of resources to get the job done.

Drupal has an excellent Security Team. Officially, it is a 40 member international team. Some donate their time outright while many others work on Drupal security on the clock of their employer. Both are a means of giving back to the Drupal Community. Beyond the 40 listed team members, there are countless people teams and individuals who look after specific modules or installation-profiles and share anything they discover.

Any maintainer of a Drupal module (note: all modules are on Drupal.org) is familiar with someone fling an issue in their module’s issue queue and offering a patch to sanitize some variable that wasn’t being sanitized. Oddly… This often happens that the form field accepting data is only usable by site admins. Our tolerance for unsanitized variables is zero. We assume every user is a bad agent and make sure that we make it as near to impossible as it can be for them to do anything unwanted via any backend or url based actions.

To that extend.. There are many eyes constantly pouring through code looking for a Gotcha. Some inspections are just “because” while others are pre-launch checks by shops about to launch some high-profile enterprise or gov website. Many times Third Party security teams are brought in to sniff out any issues or potential issues. On occasions, we DO hear back from teams like that who wind up submitting patches OR ask that a patch be made and applied. More info https://www.drupal.org/docs/security-in-drupal

Drupal developers are advised to subscribe to the security mail-list to remain updated on the latest security releases of a given module or theme or library, etc. Often, these security updates are real but the only risk was presented when logged-in users with permissions to do one thing could do something else if they tricked out the URL. The Drupal community is very conservative. As I look at each security bulletin that comes in my mail, it is quickly clear if I or any of my clients are at any real risk. Often we will wait for a bigger risk then execute multiple updates at once.

Here's a list of actions taken by the Drupal community to enhance security:

1. Twig templates used for html generation: it's no longer possible to put dangerous PHP code in template files by accident OR intentionally.
2. Removed PHP input filter and the use of PHP as a configuration import format: for years developers were able to stuff PHP code into some strange areas within the Drupal backend. There was always a way to avoid doing that but now we have made it much more difficult to even think about doing it.
3. Site configuration exportable, manageable as code, and versionable: instead of exporting/importing php code, the community is now using YAML
4. User content entry and filtering improved: the core now tightly integrates with CKeditor (also new in core) to allow default filtering if user entered data within wysiwyg thus avoiding XSS and other common risks associated with editors on CMSs
5. Hardened user session and session ID handling: there are three distinct improvements to session and session cookie handling. 
6. Automated CSRF token protection in route definitions: links (GET requests) that cause some destructive action or configuration change need to be protected from CSRF, usually with a user-specific token in the query string that is checked before carrying out the action.
7. Trusted host patterns enforced for requests: see Handbook page on host header spoofing
8. PDO MySQL limited to executing single statements: if available, Drupal 8 will set a flag that limits PHP to sending only a single SQL statement at a time when using MySQL. This change would have reduced the severity of SA-CORE-2014-005 (a SQL injection vulnerability that was easily exploited by anonymous users) (7.x back-port) . Getting this change into Drupal 8 meant I first had to contribute a small upstream change to the PHP language itself, and to the PDO MySQL library that is available in PHP versions 5.5.21 or 5.6.5 and greater.
9. Clickjacking protection enabled by default: a small change, but Drupal 8 sends the X-Frame-Options: SAMEORIGIN header in all responses by default. This header is respected by most browsers and prevents the site from being served inside an iframe on another domain. This blocks so-called click-jacking attacks (e.g. forms or links on the site being presented in a disguised fashion on an attacker's site inside an iframe), as well as blocking the unauthorized re-use of site content via iframes. (7.x back-port).
10. Core JavaScript API Compatible with CSP: support for inline JavaScript was removed from the #attached property in the Drupal render API. In addition, the Drupal javascript settings variables are now added to the page as JSON data and loaded into a variable instead of being rendered as inline JavaScript. This was the last use of inline JavaScript by Drupal 8 core, and means that site builders can much more easily enable a strict content security policy (CSP) – a new web standard for communicating per-site restrictions to browsers and mitigating XSS and other vulnerabilities.