Avoid ambiguous encoding for HMAC input

[yawkat]

When computing a HMAC of multiple inputs, it is important that the input encoding is unambiguous in order to avoid potential vulnerabilities when an attacker controls some of the input fields.

The old encoding was sessionID + "!" + random. An attacker that has limited control over the sessionID (e.g. when the sessionID is actually a username) may forge a hmac for another user with sessionID = "alice" by setting their own sessionID = "alice!eve". The server would then generate message = "alice!eve!random" and token = hmac("alice!eve!random") + "." + random. From this token, the attacker can create a token hmac("alice!eve!random") + ".eve!" + random which is a valid CSRF token for sessionID = "alice".

In practice, this is unlikely to be a problem. The session ID usually has a fixed format and is not attacker-controlled. Additionally, the attacker must know the original session ID, and bypass the CSRF token equality check. Nonetheless, as a defense in depth measure, the hmac in the example should use an unambiguous encoding. This PR adds the length of the sessionID and randomValue before their respective value to ensure this.