Content Repository Threat / 'Security Note' Background

[maxbeckmann]

Hey Team,

I am wondering about the security note from the Readme, advising against co-locating Synapse with other web-applications. My understanding is that users might upload arbitrary files, to the content repository / media repository. This potentially allows XSS, as HTML/JavaScript is allowed and returned unfiltered.

A glance into the Matrix docs however states that all responses are always either returned with Content-Type set to application/octet-stream or Content-Disposition to attachment (
https://spec.matrix.org/latest/client-server-api/#get_matrixmediav3downloadservernamemediaid).

As far as I know, every modern browser should hence trigger a download to disk instead of rendering and executing potential XSS content (see https://stackoverflow.com/questions/30897884/is-it-safe-to-rely-on-content-type-text-plain-to-mitigate-malicious-javascript#30910792).

My questions now are:

• Is the Security Note still applicable assuming users are ever only using modern browsers or am I missing a crucial detail?
• Of course there may always be undiscovered XSS vulnerabilities but beyond that, are there any inherently insecure endpoints in the server?

I couldn't find any more elaborate discussion on this topic in the matrix/synapse resources and therefore thought to create an issue for documentation purposes. My apologies up front should I have missed an existing resource or hit the wrong channel to put this question.

Thanks for your insights and of course for the great project you keep going here!

Best,
Max

[TheArcaneBrony]

"Assuming users are only using modern browsers", hello from firefox 47!

With unrestricted media uploads, especially given the context of Matrix, it's always a good thing to remain vigilant in regards to security.

[erikjohnston]

Sorry for the delay in responding.

Basically yes, we believe the current headers returned in Synapse should be sufficient to protect anyone using modern browsers. However, it's an incredibly fiddly area and the attack service is relatively large, so the likelihood of vulnerabilities in browsers in this area is definitely a risk worth considering. Using separate domains adds an additional layer of protection against those vulnerabilities.