Suppose TLS is used and a session ID was negotiated using standard HTTP mechanisms. With the websocket opening handshake, this session ID is also transferred in the HTTP header.
Suppose the websocket opening handshake is not performed if the session ID is not valid.
Is the security for all following websocket messages with that connection guaranteed even if no further authentication is performed for these messages?
Are there any attack scenarios here?
WebSockets work by first having an initial HTTP handshake and then establish a message-based communication. Everything is done within a single TCP connection and in case of wss:// within a single TLS connection. Authenticating this connection at the beginning (for example with sending the session cookie inside the initial HTTP handshake) is similar to only authenticating a SSH session at the beginning or only authenticating a normal HTTP/HTTPS request at the beginning and not authenticating every transmitted byte of the request again.
Of course, this single authentication at the beginning is only sufficient if the following data can not be manipulated somehow. In your example wss:// is used which uses TLS and this way protects the data against manipulation by an active man in the middle.
But if for example the attacker manages to compromise the endpoint of the connection (for example using XSS) he might be able to send his own messages over the already authenticated WebSocket. It is likely though that if an attacker can send messages within an established WebSocket he will also be able to establish new WebSockets. And if these are authenticated with a session cookie only the browser will automatically include the cookie when establishing the new WebSocket which means that it will be implicitly authenticated. So the mitigation against this would not be to authenticate every WebSocket message but instead to make sure that an attacker cannot compromise the client side of the web application using XSS or similar in the first place.
