|
|
|
@@ -149,21 +149,45 @@ For details on having Synapse manage your federation TLS certificates |
|
|
|
automatically, please see `<docs/ACME.md>`_. |
|
|
|
|
|
|
|
|
|
|
|
Security Note |
|
|
|
Security note |
|
|
|
============= |
|
|
|
|
|
|
|
Matrix serves raw user generated data in some APIs - specifically the `content |
|
|
|
repository endpoints <https://matrix.org/docs/spec/client_server/latest.html#get-matrix-media-r0-download-servername-mediaid>`_. |
|
|
|
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 (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 |
|
|
|
|
|
|
|
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. |
|
|
|
|
|
|
|
|
|
|
|
Upgrading an existing Synapse |
|
|
|
|
Denis Kasak
GitHub