Finalize web socket requirements about asvs

[tghosth]

Some references I used:
https://ably.com/topic/websocket-security
https://devcenter.heroku.com/articles/websocket-security
https://payatu.com/blog/websocketsecurity/

[elarlang]

Just quick feedback:

13.5.1 - in a way covered by 9.1.1

Verify that TLS is used for all connectivity between a client and external facing, HTTP-based services, and does not fall back to insecure or unencrypted communications.

I don't know the answer, but can you use not secure web socket, when you have HSTS set?

13.5.2 - in a way covered by 4.1.1

Verify that the application enforces access control rules at a trusted service layer and doesn't rely on controls which an untrusted user could manipulate such as client-side JavaScript.

What means "list of authorized origins"?

13.5.3 - remove as duplicate of 11.2.2?

13.5.4 - what is the message or goal for the requirement? Require session? For everyone? How it is aligned wit 13.5.5?

13.5.6 - what is/was the point for this?

[tghosth]

---

13.5.1 - in a way covered by 9.1.1

Verify that TLS is used for all connectivity between a client and external facing, HTTP-based services, and does not fall back to insecure or unencrypted communications.

I don't know the answer, but can you use not secure web socket, when you have HSTS set?

Looks like HSTS also applies to WebSocket:

Sources to support

• https://bugzilla.mozilla.org/show_bug.cgi?id=664284
• https://issues.chromium.org/issues/40081328
• glowing-bear/glowing-bear#1117

I agree it is theoretically a duplicate but it is also quite a specific case that would need to be specific configured, especially if for whatever reason HSTS is not in use. Hence suggesting leaving it in.

---

13.5.2 - in a way covered by 4.1.1

Verify that the application enforces access control rules at a trusted service layer and doesn't rely on controls which an untrusted user could manipulate such as client-side JavaScript.

Again, this is a very specific case which is why I think it is worth including it

What means "list of authorized origins"?

Yeah I agree, I think it should be worded slightly better:

#	Description	L1	L2	L3	CWE
13.5.2	[ADDED] Verify that, during the initial HTTP WebSocket handshake, the Origin header is checked against a list of origins allowed for the application.	✓	✓	✓	346

---

13.5.3 - remove as duplicate of 11.2.2?

Basically yes, I didn't tag it because it is ADDED

---

13.5.4 - what is the message or goal for the requirement? Require session? For everyone? How it is aligned wit 13.5.5?

Basic problem is that websockets support cookie based sessions but not tokens in headers so if that is the required Auth mechanism you have to do something specific.

At that point, how you get the token is important hence the need for 13.5.5 as well.

---

13.5.6 - what is/was the point for this?

Not sure but it doesn't seem like it adds something specific on V2 and 13.5.4/13.5.5

---

[ryarmst]

Regarding 13.5.4/13.5.5, having seen a number of implementations, it seems the most common practice is to associate connections with standard sessions supplied during the handshake.

Basic problem is that websockets support cookie based sessions but not tokens in headers so if that is the required Auth mechanism you have to do something specific.

Unless I am misunderstanding, I think this is not correct. Cookies, headers, and query parameters equally (though the latter obviously not preferred) can be utilized from a handshake to authenticate a connection. From a complexity point of view, I think it's probably preferred to use the standard session management regardless.

[tghosth]

Hi @ryarmst :)

Basic problem is that websockets support cookie based sessions but not tokens in headers so if that is the required Auth mechanism you have to do something specific.

Unless I am misunderstanding, I think this is not correct. Cookies, headers, and query parameters equally (though the latter obviously not preferred) can be utilized from a handshake to authenticate a connection. From a complexity point of view, I think it's probably preferred to use the standard session management regardless.

So I think I wasn't clear enough. What I should have said was:

Basic problem is that the websocket "upgrade" handshake supports cookie based sessions but not tokens in headers so if that is the required Auth mechanism you have to do something specific.

So if I have an app where all my authentication involves using a header token, for the handshake request which will result in a 101 upgrade response, it will be necessary to somehow transmit that header separately.

Does that match how you understand it? If so, I may try and reword/clarify 13.5.4/13.5.5.

[ryarmst]

Hi @tghosth!

Sorry, I was mistaken. I checked the protocol spec, but ignored the API spec that does not support custom headers. I had seen an implementation repurpose Sec-WebSocket-Protocol to send session/auth data, but I think this should not be recommended. That said, 13.5.5 feels overly specific but without detailing the complete flow that is expected. Am I correct that the approach would involve obtaining a transient token for session transfer and subsequently sending in an initial WS message to "authenticate" the WS connection (tracked server-side)?

[tghosth]

Hi @tghosth!

Sorry, I was mistaken. I checked the protocol spec, but ignored the API spec that does not support custom headers. I had seen an implementation repurpose Sec-WebSocket-Protocol to send session/auth data, but I think this should not be recommended. That said, 13.5.5 feels overly specific but without detailing the complete flow that is expected. Am I correct that the approach would involve obtaining a transient token for session transfer and subsequently sending in an initial WS message to "authenticate" the WS connection (tracked server-side)?

So from an access control/session management perspective, my understanding is that securing the websocket handshake is the crucial part so if a non-cookie session mechanism is in use then a session token of some sort would need to be obtained from the server and then sent in the handshake request. The server would then only perform the handshake "upgrade" if the session token was valid. It may be better if the regular session token is not used for this as sending it in the handshake request might expose it more than usual (e.g. if it goes in the request header).