From 76be057ca3cde4a6fbee54ad1371b08e9440897b Mon Sep 17 00:00:00 2001 From: Denis Kasak Date: Mon, 25 Jan 2021 14:52:10 +0100 Subject: [PATCH 1/3] Clarify security note regarding the domain Synapse is hosted on. --- README.rst | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/README.rst b/README.rst index 1a5503572ee4..3f6846060076 100644 --- a/README.rst +++ b/README.rst @@ -149,21 +149,24 @@ For details on having Synapse manage your federation TLS certificates automatically, please see ``_. -Security Note +Security note ============= -Matrix serves raw user generated data in some APIs - specifically the `content -repository endpoints `_. +Matrix serves raw, user-supplied data in some APIs -- specifically the `content +repository endpoints`_. -Whilst we have tried to mitigate against possible XSS attacks (e.g. -https://github.com/matrix-org/synapse/pull/1021) we recommend running -matrix homeservers on a dedicated domain name, to limit any malicious user generated -content served to web browsers a matrix API from being able to attack webapps hosted -on the same domain. This is particularly true of sharing a matrix webclient and -server on the same domain. +.. _content repository endpoints: https://matrix.org/docs/spec/client_server/latest.html#get-matrix-media-r0-download-servername-mediaid -See https://github.com/vector-im/riot-web/issues/1977 and -https://developer.github.com/changes/2014-04-25-user-content-security for more details. +Whilst we make a reasonable effort to mitigate against XSS attacks (such as +using `CSP`_), ideally a Matrix homeserver should be hosted on a dedicated +domain name not shared by other web applications. This particularly applies to +sharing the domain with Matrix web clients and other sensitive applications +like webmail. + +.. _CSP: https://github.com/matrix-org/synapse/pull/1021 + +Using a separate domain ensures that even if an XSS is found in Synapse, the +impact to other applications will be minimal. Upgrading an existing Synapse From 10ccc2c54e59ebd10512dcc293ffc2d07c79e9d3 Mon Sep 17 00:00:00 2001 From: Denis Kasak Date: Tue, 26 Jan 2021 11:27:24 +0100 Subject: [PATCH 2/3] Add newsfile for #9221. --- changelog.d/9221.doc | 1 + 1 file changed, 1 insertion(+) create mode 100644 changelog.d/9221.doc diff --git a/changelog.d/9221.doc b/changelog.d/9221.doc new file mode 100644 index 000000000000..9b3476064b39 --- /dev/null +++ b/changelog.d/9221.doc @@ -0,0 +1 @@ +Clarify security note regarding hosting Synapse on the same domain as other web applications. From 52ee284d87db4b35ee5182e64892809b917de1f6 Mon Sep 17 00:00:00 2001 From: Denis Kasak Date: Wed, 26 May 2021 17:28:41 +0200 Subject: [PATCH 3/3] Revise after review. --- README.rst | 33 +++++++++++++++++++++++++++------ 1 file changed, 27 insertions(+), 6 deletions(-) diff --git a/README.rst b/README.rst index 3f6846060076..a14a687fd1b4 100644 --- a/README.rst +++ b/README.rst @@ -157,15 +157,36 @@ repository endpoints`_. .. _content repository endpoints: https://matrix.org/docs/spec/client_server/latest.html#get-matrix-media-r0-download-servername-mediaid -Whilst we make a reasonable effort to mitigate against XSS attacks (such as -using `CSP`_), ideally a Matrix homeserver should be hosted on a dedicated -domain name not shared by other web applications. This particularly applies to -sharing the domain with Matrix web clients and other sensitive applications -like webmail. +Whilst we make a reasonable effort to mitigate against XSS attacks (for +instance, by using `CSP`_), a Matrix homeserver should not be hosted on a +domain hosting other web applications. This especially applies to sharing +the domain with Matrix web clients and other sensitive applications like +webmail. See +https://developer.github.com/changes/2014-04-25-user-content-security for more +information. .. _CSP: https://github.com/matrix-org/synapse/pull/1021 -Using a separate domain ensures that even if an XSS is found in Synapse, the +Ideally, the homeserver should not simply be on a different subdomain, but on +a completely different `registered domain`_ (also known as top-level site or +eTLD+1). This is because `some attacks`_ are still possible as long as the two +applications share the same registered domain. + +.. _registered domain: https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-2.3 + +.. _some attacks: https://en.wikipedia.org/wiki/Session_fixation#Attacks_using_cross-subdomain_cookie + +To illustrate this with an example, if your Element Web or other sensitive web +application is hosted on ``A.example1.com``, you should ideally host Synapse on +``example2.com``. Some amount of protection is offered by hosting on +``B.example1.com`` instead, so this is also acceptable in some scenarios. +However, you should *not* host your Synapse on ``A.example1.com``. + +Note that all of the above refers exclusively to the domain used in Synapse's +``public_baseurl`` setting. In particular, it has no bearing on the domain +mentioned in MXIDs hosted on that server. + +Following this advice ensures that even if an XSS is found in Synapse, the impact to other applications will be minimal.