diff --git a/en/02_Developer_Guides/03_Forms/Field_types/03_HTMLEditorField.md b/en/02_Developer_Guides/03_Forms/Field_types/03_HTMLEditorField.md index 8ac526c33..b7762ddde 100644 --- a/en/02_Developer_Guides/03_Forms/Field_types/03_HTMLEditorField.md +++ b/en/02_Developer_Guides/03_Forms/Field_types/03_HTMLEditorField.md @@ -299,7 +299,7 @@ SilverStripe\Core\Injector\Injector: - proxy: '111.222.333.444:55' ``` -## Limiting oembed URLs +### Limiting oembed URLs HTMLEditorField can have whitelists set on both the scheme (default HTTP & HTTPS) and domains allowed when inserting files for use with oembed. @@ -335,7 +335,29 @@ of the above values. By default live sites (see [environment types](/developer_guides/debugging/environment_types/)) will not attempt to resolve oembed urls that point to localhost to protect your site from cross site request forgery. -### Doctypes +### Sandboxing oembed HTML + +In order to prevent any malicious oembed providers from injecting XSS payloads into the current webpage, HTML content that is returned is sandboxed in an `iframe` tag. + +With the [`EmbedShortcodeProvider.domains_excluded_from_sandboxing`](api:SilverStripe\View\Shortcodes\EmbedShortcodeProvider->domains_excluded_from_sandboxing) configuration property, you can explicitly declare domains which should be excluded from sandboxing if you find it is interfering with embeds from specific domains. For example if a YouTube embed was not rendering correctly as a result of the sandboxing you could use this YAML configuration: + +```yml +SilverStripe\View\Shortcodes\EmbedShortcodeProvider: + domains_excluded_from_sandboxing: + - 'youtube.com' +``` + +Do not include the protocol (i.e. don't include `https://` or `http://`). + +You can also change the attributes of the iframe itself with the [`EmbedShortcodeProvider.sandboxed_iframe_attributes`](api:SilverStripe\View\Shortcodes\EmbedShortcodeProvider->sandboxed_iframe_attributes) configuration property: + +```yml +SilverStripe\View\Shortcodes\EmbedShortcodeProvider: + sandboxed_iframe_attributes: + allow: 'fullscreen' +``` + +## Doctypes Since TinyMCE generates markup, it needs to know which doctype your documents will be rendered in. You can set this through the [element_format](https://www.tiny.cloud/docs/tinymce/6/content-filtering/#element_format) configuration variable. diff --git a/en/02_Developer_Guides/09_Security/05_Secure_Coding.md b/en/02_Developer_Guides/09_Security/05_Secure_Coding.md index 35c91b951..682ed19c6 100644 --- a/en/02_Developer_Guides/09_Security/05_Secure_Coding.md +++ b/en/02_Developer_Guides/09_Security/05_Secure_Coding.md @@ -215,8 +215,7 @@ displaying a blog post in HTML from a trusted author, or escaping a search param redisplaying it). > [!WARNING] -> Note: Silverstripe CMS templates do not remove tags, please use [strip_tags()](https://php.net/strip_tags) for this purpose -> or [sanitize](https://htmlpurifier.org/) it correctly. +> Note: Make sure you use the [correct casting](/developer_guides/model/data_types_and_casting/#casting) when including content in a Silverstripe CMS template. See the [OWASP article on XSS](https://owasp.org/www-community/attacks/xss/) for more information. @@ -226,6 +225,8 @@ For `HTMLText` database fields which aren't edited through `HtmlEditorField`, yo have the option to explicitly whitelist allowed tags in the field definition, e.g. `"MyField" => "HTMLText('meta','link')"`. The `SiteTree.ExtraMeta` property uses this to limit allowed input. +You can also use the [`XssSanitiser`](api:SilverStripe\Core\XssSanitiser) to remove some known XSS attack vectors from HTML content. Note that this should be used only in scenarios where the HTML content can't be completely removed, and should not be considered a complete protection against all XSS attack vectors but rather as simply one of many tools in your security tool box. + ### What if I need to allow script or style tags? The default configuration of Silverstripe CMS uses a santiser to enforce TinyMCE whitelist rules on the server side,