DOC 4.6.0 additional changelog and security changelog

docs/en/04_Changelogs/4.6.0.md

@@ -1,18 +1,124 @@
-# 4.6.0 (Unreleased)
+# 4.6.0
 
 ## Overview {#overview}
 
  * [MySQL tables are auto-converted from MyISAM to InnoDB](#myisam)
  * [Editing files directly in the insert-media modal](#in-modal-editing)
  * [MIME Type validation now a core module](#mime-validator)
+ * [Solr no longer indexes draft/restricted content](#solr-updates)
+ * [Simplify customisation of ModelAdmin](#modeladmin-customisation)
+ * [Login forms module ships with installer](#loginforms)
+
+## 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](https://www.silverstripe.org/download/security-releases/CVE-2020-9309)
+* [CVE-2019-19326 Web Cache Poisoning](https://www.silverstripe.org/download/security-releases/CVE-2019-19326)
+* [CVE-2020-6164 Information disclosure on /interactive URL path](https://www.silverstripe.org/download/security-releases/CVE-2020-6164)
+* [CVE-2020-6165 Limited queries break CanViewPermissionChecker](https://www.silverstripe.org/download/security-releases/CVE-2020-6165)
+
+### CVE-2020-9309 Script execution on protected files {#CVE-2020-9309}
+
+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](#MimeValidator) to understand
+how this will impact your project.
+
+### CVE-2019-19326 Web Cache Poisoning {#CVE-2019-19326}
+
+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
+<?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](/developer_guides/security/secure_coding/#request-hostname-forgery) on the Silverstripe documentation.
+* read the [documentation about HTTP Middlewares](/developer_guides/controllers/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](/Developer_Guides/GraphQL/Verifying_CanView_Permission)
+for more information on updating your GraphQL queries.
 
 ## MySQL tables are auto-converted from MyISAM to InnoDB {#myisam}
 
 Beginning with [4.4.0](https://docs.silverstripe.org/en/4/changelogs/4.4.0/),
-our minimum requirement for MySQL is 5.6 (since MySQL 5.5 end of life reached in December 2018).
+our minimum requirement for MySQL is 5.6 (since MySQL 5.5 end of life reached
-Starting with MySQL 5.6, [InnoDB](https://dev.mysql.com/doc/refman/5.6/en/innodb-introduction.html)
+in December 2018). Starting with MySQL 5.6, [InnoDB](https://dev.mysql.com/doc/refman/5.6/en/innodb-introduction.html)
-is the new default storage engine,
+is the new default storage engine, replacing the older [MyISAM](https://dev.mysql.com/doc/refman/5.6/en/myisam-storage-engine.html)
-replacing the older [MyISAM](https://dev.mysql.com/doc/refman/5.6/en/myisam-storage-engine.html) engine.
+engine.
 
 Silverstripe CMS already creates InnoDB tables by default,
 mainly in order to benefit from their better support for database transactions.
@@ -58,24 +164,165 @@ class MyDataObject extends DataObject
 
 ## Editing files directly in the insert-media modal{#in-modal-editing}
 
-Editors can now directly edit file details when selecting a file in an UploadField or when inserting media in a
+Editors can now directly edit file details when selecting a file in an
-HTMLEditorField. The "image placement" and "file link" forms that show when inserting an image or a link 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
+This does mean that the order and structure of fields have changed somewhat. If
-asset administration area or in the "Insert Media Modal", you should do some regression testing when upgrading to 
+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](https://github.com/jonom/silverstripe-focuspoint) community
+If your project uses the popular [jonom/focuspoint](https://github.com/jonom/silverstripe-focuspoint)
-module, you should upgrade it as well.
+community module, you should upgrade it as well.
 
 ## MIME Type validation now a core module {#mime-validator}
 
-`silverstripe/mimevalidator` is now a core module and will ship by default on new projects. Projects referencing `silverstripe/recipe-core` will automatically install `silverstripe/mimevalidator` when they upgrade to 4.6.0.
+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.
 
-Read [Allowed file types](Developer_Guides/Files/Allowed_file_types) in the Silverstripe CMS doc for all the details.
+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:
+
+```bash
+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`:
+
+```bash
+composer require silverstripe/mimevalidator
+```
+
+Then, add this code snippet to your YML configuration to enable MIME type
+validation:
+
+```yml
+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](/Developer_Guides/Files/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.
+
+```bash
+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
+
+![File status icons](https://raw.githubusercontent.com/silverstripe/silverstripe-framework/blob/4/docs/en/04_Changelogs/_images/file-status-icons.png "A screenshot of file status icons being displayed 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](https://github.com/silverstripe/silverstripe-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 {#solr-updates}
+
+At the time of this release a new version of the popular [silverstripe/fulltextsearch module](https://github.com/silverstripe/silverstripe-fulltextsearch) 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](https://github.com/silverstripe/silverstripe-fulltextsearch).
+
+## Simplify customisation of ModelAdmin {#modeladmin-customisation}
+
+`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](/developer_guides/customising_the_admin_interface/modeladmin/#altering-the-modeladmin-gridfield-or-form)
+
+## Login forms module ships with installer {#loginforms}
+
+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](https://github.com/silverstripe/silverstripe-login-forms) on Github for more details.
 <!--- Changes below this line will be automatically regenerated -->
 
 <!--- Changes above this line will be automatically regenerated -->
-