### 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.
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).
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.
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
## 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.