silverstripe-framework/docs/en/04_Changelogs/4.6.0.md

4.6.0

Overview

• MySQL tables are auto-converted from MyISAM to InnoDB
• Editing files directly in the insert-media modal
• MIME Type validation now a core module
• Solr no longer indexes draft/restricted content
• Simplify customisation of ModelAdmin
• Login forms module ships with installer

Security patches

This release contains security patches. Some of those patches might require some updates to your project.

• CVE-2020-9309 Script execution on protected files
• CVE-2019-19326 Web Cache Poisoning
• CVE-2020-6164 Information disclosure on /interactive URL path
• CVE-2020-6165 Limited queries break CanViewPermissionChecker

CVE-2020-9309 Script execution on protected files

Silverstripe can be susceptible to script execution from malicious upload contents under allowed file extensions (for example HTML code in a TXT file). When these files are stored as protected or draft files, the MIME detection can cause browsers to execute the file contents.

Risk factors

If your project already includes the silverstripe/mimevalidator module, it's already protected. CWP projects are already protected.

If your project includes the silverstripe/userforms module or allows anonymous users to upload files, it's at a higher risk because malicious users can create files without requiring a CMS access.

Actions you need to take

Upgrading to silverstripe/recipe-core 4.6.0 will automatically install the silverstripe/mimevalidator module.

Read MIME validator is now part of recipe-core to understand how this will impact your project.

CVE-2019-19326 Web Cache Poisoning

Silverstripe sites using HTTP cache headers and HTTP caching proxies (e.g. CDNs) can be susceptible to web cache poisoning through the:

• X-Original-Url HTTP header
• X-HTTP-Method-Override HTTP header
• _method POST variable.

In order to remedy this vulnerability, Silverstripe Framework 4.6.0 removes native support for these features. While this is technically a semantic versioning breakage, these features are inherently insecure and date back to a time when browsers didn't natively support the full range of HTTP methods. Sites who still require these features will have highly unusual requirements that are best served by a tailored solution.

Re-enabling the support for removed features

These features are best implemented by defining a Middleware.

The following example illustrates how to implement an HTTPMiddleware that restores support for the X-Original-Url header and the _method POST parameter for requests originating from a trusted proxy.

<?php

use SilverStripe\Control\Middleware\HTTPMiddleware;
use SilverStripe\Control\HTTPRequest;

/**
 * This is meant to illustrate how to implement an HTTPMiddleware. If you blindly
 * copy-paste this in in your code base, you'll simply replicate the vulnerability.
 */
class InsecureHeaderMiddleware implements HTTPMiddleware
{
    public function process(HTTPRequest $request, callable $delegate)
    {
        // Normally, you would validate that the request is coming from a trusted source at this point.
        // View SilverStripe\Control\Middleware\TrustedProxyMiddleware for an example.
        $trustedProxy = true;

        if ($trustedProxy) {
            $originalUrl = $request->getHeader('X-Original-Url');
            if ($originalUrl) {
                $_SERVER['REQUEST_URI'] = $originalUrl;
                $request->setUrl($originalUrl);
            }

            $methodOverride = $request->postVar('_method');
            $validMethods = ['GET', 'POST', 'PUT', 'DELETE', 'HEAD'];
            if ($methodOverride && in_array(strtoupper($methodOverride), $validMethods)) {
                $request->setHttpMethod($methodOverride);
            }
        }

        return $delegate($request);
    }
}

To learn more about re-implementing support for the disabled features:

• read how to configure trusted proxies on the Silverstripe documentation.
• read the documentation about HTTP Middlewares.

CVE-2020-6164 Information disclosure on /interactive URL path

A specific URL path configured by default through the silverstripe/framework module can be used to disclose the fact that a domain is hosting a Silverstripe application. There is no disclosure of the specific version. The functionality on this URL path is limited to execution in a CLI context, and is not known to present a vulnerability through web-based access. As a side-effect, this preconfigured path also blocks the creation of other resources on this path (e.g. a page).

CVE-2020-6165 Limited queries break CanViewPermissionChecker

The automatic permission checking mechanism in the silverstripe/graphql module does not provide complete protection against lists that are limited (e.g. through pagination), resulting in records that should fail the permission check being added to the final result set.

If your project implements custom GraphQL queries using the CanViewPermissionChecker, you should validate that they still work as expected after the upgrade.

Read Controlling who can view results in a GraphQL result set for more information on updating your GraphQL queries.

MySQL tables are auto-converted from MyISAM to InnoDB

Beginning with 4.4.0, our minimum requirement for MySQL is 5.6 (since MySQL 5.5 end of life reached in December 2018). Starting with MySQL 5.6, InnoDB is the new default storage engine, replacing the older MyISAM engine.

Silverstripe CMS already creates InnoDB tables by default, mainly in order to benefit from their better support for database transactions. Before MySQL 5.6, InnoDB didn't have a FULLTEXT search index, requiring us to enforce the MyISAM engine when devs opted into this index type in their particular setup. There are a few ways in which this opt-in can happen:

• Adding the FulltextSearchable extension to a DataObject, as described in our search docs
• Defining 'type' => 'fulltext' in DataObject::$db column definitions
• Implementing DBIndexable on a custom DBField subclass.
• Setting 'ENGINE=MyISAM' in DataObject::$create_table_options

This search index is not required to enable simple text search in the "Pages" section of the CMS, or any ModelAdmin implementations. We generally recommend to choose a more powerful search addon (e.g. based on Solr or ElasticSearch) for website frontend search use cases.

As of 4.6.0, a dev/build will automatically switch MyISAM tables to InnoDB, which automatically recreates any indexes required. If you have large indexes, this can extend the duration if this task. As usual, back up your database before upgrading, and test upgrades on non-production systems first. Our tests indicate that indexes with thousands of records and screen pages worth of content (15MB index size) are converted in a few seconds.

In order to opt out of this change, you can set the engine explicitly for your DataObject implementations:

use SilverStripe\ORM\Connect\MySQLSchemaManager;
use SilverStripe\ORM\DataObject;

class MyDataObject extends DataObject
{
    private static $create_table_options = [
            MySQLSchemaManager::ID => 'ENGINE=MyISAM'
    ];
}

Editing files directly in the insert-media modal

Editors can now directly edit file details when selecting a file in an UploadField or when inserting media in a HTMLEditorField. The "image placement" and "file link" forms that show when inserting an image or a link in an HTMLEditorField have been simplified.

This does mean that the order and structure of fields have changed somewhat. If you have customised the forms in the asset administration area or in the "Insert Media Modal", you should do some regression testing when upgrading to make sure your customisations still work as expected.

If your project uses the popular jonom/focuspoint community module, you should upgrade it as well.

MIME Type validation now a core module

The Silverstripe CMS installer now includes the silverstripe/mimevalidator. This change was implemented to address CVE-2020-9309 vulnerability and the inherent limits of controlling allowed file types by looking only at file extensions.

For most Silverstripe CMS projects, this will be a transparent upgrade. However, they are some situations where you might need to make some adjustments.

Who will get MIME validator installed automatically?

If your Silverstripe CMS project references silverstripe/recipe-core or silverstripe/recipe-cms in its composer.json file, silverstripe/mimevalidator will be automatically installed once you upgrade to Silverstripe CMS 4.6.0. Those recipes might also be indirectly installed via other recipes (e.g.: cwp/cwp-recipe-core). You can run this command from your project root to know for sure:

composer show silverstripe/recipe-core

If you get an error, you will not be automatically get silverstripe/mimevalidator following your upgrade.

After upgrading your project, composer should automatically create the following file in your project: app/_config/mimevalidator.yml. This file contains the default configuration for the new module. You'll need to commit mimevalidator.yml and your updated composer.json file to your source control system.

If you're not using recipe-core/recipe-cms?

If your project doesn't reference silverstripe/recipe-core or silverstripe/recipe-cms, you will need to manually add silverstripe/mimevalidator to your project dependencies. Run this command to install silverstripe/mimevalidator:

composer require silverstripe/mimevalidator

Then, add this code snippet to your YML configuration to enable MIME type validation:

SilverStripe\Core\Injector\Injector:
  SilverStripe\Assets\Upload_Validator:
    class: SilverStripe\MimeValidator\MimeUploadValidator

Customising allowed file types

If you've customised your project allowed file types, you might need to tweak the boilerplate MIME validator configuration and confirm the new module doesn't interfere with your existing logic.

Read Allowed file types in the Silverstripe CMS documentation to learn how to Control the type of files that can be stored in your project.

What if the MIME validator module is already installed?

If your project already requires silverstripe/mimevalidator, you probably don't need to do anything.

If you didn't have a pre-existing app/_config/mimevalidator.yml file and your MIME validator configuration is contained somewhere else in your project, feel free to discard mimevalidator.yml.

If you explicitly required silverstripe/mimevalidator in your composer.json file, you can remove the explicit reference and rely on the module being installed via the recipes.

If your version constrain for silverstripe/mimevalidator in your composer.json is too strict, you might get an error while upgrading to the latest version of recipe-core. If this occurs, either loosen the constraint for silverstripe/mimevalidator or remove it altogether.

What if I don't want the MIME validator module?

This is not advise, but you can upgrade to Silverstripe CMS 4.6.0 without installing the silverstripe/mimevalidator module.

To achieve this, you will need to "inline" recipes in your composer.json. This means you will have an explicit dependency for each individual Silverstripe CMS module. You can inline recipes by running this command.

composer require-recipe silverstripe/recipe-cms

Then you just need to remove the reference to silverstripe/mimevalidator.

Beware that this will make future upgrade more difficult because you will have to manually edit each module constraint.

File status icons in the file manager

Files and folders with permissions of either "Logged in users" or "Only these groups (choose from list)" now show a "Restricted access" icon in the file manager. These permissions can either be directly on the DataObject or they can be inherited from the parent folder.

Websites with the optional UserForms module installed will show a "Form submission" icon on files uploaded through a UserForm. UserForm uploaded files without a "Restricted access" icon show a "Form submission, unrestricted access" icon instead.

Solr no longer indexes draft/restricted content

At the time of this release a new version of the popular silverstripe/fulltextsearch module is also available, introducing more secure defaults. Most notably, draft and restricted content will no longer be indexed by default, due to a canView() check being performed against an anonymous user prior to (re)indexing. Restricted content means that it has a permission level of either 'Logged-in users' or 'Only these groups'.

If your project uses this module, after upgrading your website, ensure that you run the Solr_Reindex task on your production environment to remove previously indexed content that should no longer be there.

If your website requires draft or restricted content to be indexed, you can opt-out of the new secure defaults on a per-model basis.

This is a great opportunity to make sure that any custom indexes/search controllers in your project are correctly filtering results based on permissions and search visibility, which you can now achieve via a unified method (see SilverStripe\FullTextSearch\Search\Services\SearchableService::isSearchable().)

The silverstripe/fulltextsearch module readme provides additional information.

Simplify customisation of ModelAdmin

ModelAdmin::getEditForm() has been split into smaller more discrete protected methods:

• getGridField()
• getGridFieldConfig().

Two matching extension hooks have been added as well:

• updateGridField()
• updateGridFieldConfig().

This will make it easier for developers to customise GridFields in their ModelAdmins.

Learn how to alter the ModelAdmin GridField or Form

Login forms module ships with installer

The silverstripe/login-forms module is now part of the default installer. This alters the login form to provide consistent styling and behaviour that's independent from the specifics in your project. Only new projects will get the new login form. Older projects can manually require the silverstripe/login-forms module to get the new login form.

View the Silverstripe Login Forms readme on Github for more details.