element-hq / element-hq/synapse
Don't serve user-uploaded files with correct mime/content type
- Dominant language
- Python
- Stars
- 4.6k
- Forks
- 600
- Avg merge
- 5d 22h
- Merged PRs (30d)
- 51
Description
This issue has been migrated from [#2877](https://github.com/matrix-org/synapse/issues/2877).
---
Yes this tackles [your known problem](https://github.com/matrix-org/synapse#security-note). So it's good you use some CSP there to prevent the execution of JavaScript, but that is not nearly enough.
And no, I don't accept that you tell users to use another server/domain. That may be an additional mitigation, but you cannot require each user to do so and it is just not a good idea to think that each user could do so.
Also it e.g. has a phishing risk. When I click on such a file in Riot, it just directs me to the new server and displays that file. That means if the HTML file just emulates the Riot login screen, some users may be tricked with that. (And as the website opens in the same window it is not the same as if I just click an arbitrary external link, which opens in a new tab.)
Nobody needs to display a website when one sends a HTML file! These may be devs or so and they can just open it locally… (it also makes less sense when JS is broken anyway, thanks to the CSP.)
That also tackles you spec, so…
But in Riot and everywhere users also just use this thing to download files. So why not simply instruct the browser for a download? Set `application/octet-stream` as the content type. That's a very simple solution.
As for JPGs showing inline in a browser, that's also no problem. One AJAX call to download the file and then you can load it via `data:` anyway. (I think, that may be done when encryption is enabled, anyway.)
So the spec requiring `Content-Type` to be correct, is not only useless, but just really harmful.
Contributor guide
Assessment
This issue has not been assessed yet.