A fair warning: this post is technical. You need to have at least basic understanding of how the ADC protocol works in order to get anything meaningful out of this post.
Completely basic stuff, not covered elsewhere:
The hub MUST make sure the client sends the correct SID as previously assigned by the hub, for every incoming message to the hub that would contain an originating SID.
Such messages include broadcast messages (Bxxx), direct messages (Dxxx), echo messages (Exxx) and subscriber/feature messages (Fxxx).
Likewise, on NMDC one would have to ensure one used the correct nick name when sending a chat message.
Sending a message that looks like it came from user "good" when it actually comes from user "evil" is just that -- evil, and must not be allowed by any hub.
INF message parsing
Most processing that needs to be performed on the hub is related to the INF-message, so here goes a few of them.
- The PD-field should always be stripped by the hub, and never relayed to the other users. This is stated explicitly in the ADC spec, although it does not explain why the PD has to be such a "secret" (it has nothing to do with security, that's for sure).
- The ID-field which contains the CID must not be allowed to be updated after a client has logged in. Updating the ID-field is allowed if it is unachanged, removing it is merely an optimization.
- The I4/I6 field must match the actual IP address of the user, and that needs to be verifiable, and should not change. Currently the best verification is to check where the user connected from. If a user connected from an IPv4 address one cannot usually determine a valid IPv6 address (unless it's a IPv4 in IPv6 mapping), and if the user's client still reports that it does have an IPv6 address (I6), then the hub must remove that flag as it is unverified.
- The U4/U6 port numbers should be verified to be within 0 <= port < 65536. Not really security, but let's just call it best practise.
- There could be multiple flags, such as I4, NI, I6 etc... Make sure only *ONE* of each of these exist (example: BINF (...) NIfoo NIbar --- now, what's the nick, again?)
- The hub *MAY* support updating or changing the nickname after a user has logged in. Lots of considerations need to be taken here, I will not cover those. It's easier to not allow it if you don't want to do the considerations.
Since the hub is required to notify all users about new users joining the hub by sending an INF-message (a 'BINF') message, variants of it must not be allowed.
A client must not be allowed to send a 'DINF', 'EINF' or 'FINF' message, unless the hub can guarantee that it does not change the state for any user who did not receive such a message. The easy solution - drop these messages.
If a client really wants to change information about itself, then all parties would want that information, and as such it should be broadcasted to all as a BINF message, which should be processed and verified by the hub.
A client should not be allowed to 'fake' it's own or some other client's leave message by sending a 'QUI' message.
For messages a client MUST not be allowed to set the PM argument. That is only for the hub to do. Otherwise one can send messages which originate in a particular "window" for the receiving client.
...are probably forgotten