-
Notifications
You must be signed in to change notification settings - Fork 236
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Synapse allows invalid usernames over federation #17740
Comments
This is due to the historical user names that were previously used. |
Well, empty user names could be considered a nogo even in historical usernames? As an aside: 1.93.0 is a seriously old Synapse server. |
They do exist though. MSC4044 aims to improve this. |
Historical usernames aren't allowed to use spaces. The space ASCII code is When interviewing people who created invalid usernames, my personal experience is that many users were pentesters who wanted to verify what Synapse permits over federation. I personally believe that it's a misguided thought to accept that such usernames exist and hence allow them. Synapse doesn't reject servers that break auth rules simply because of their existence. Unvalidated usernames leave room for security issues in the long run, and it breaks clients (source: the Elm SDK, which I develop) that wish to abide by spec. (The server in question has since been updated.) |
Description
Synapse server implementations do not parse usernames and allow arbitrary Unicode characters to be inserted into the username field.
As per the Matrix spec v1.11, usernames need to be restricted to the characters
a-z
,0-9
,.
,_
,=
,-
,/
, and+
. However, over federation, servers also need to support historical users, whose character set is defined as all ASCII printing chars except:
, or specifically 0x21 to 0x7E with the exception of 0x3A.Nevertheless, Synapse servers doesn't reject user IDs that break the spec's rules, with examples such as:
Steps to reproduce
Invite users such as
@s p a c e:maunium.net
or@:maunium.net
to a room, and the Synapse server will simply follow along.Homeserver
matrix.directory
Synapse Version
1.93.0
Installation Method
Docker (matrixdotorg/synapse)
Database
Not relevant.
Workers
Single process
Platform
Not relevant. These usernames are widely known across the ecosystem.
Configuration
No response
Relevant log output
Not relevant. These usernames are widely known across the ecosystem - and the whole point is that this issue DOESN'T raise any problems.
Anything else that would be useful to know?
No response
The text was updated successfully, but these errors were encountered: