验证 WebSocket 连接

Question

This may seem like a pretty noobish question, but I just recently got into Node.js and am needed to make sure that the same kind of Authentication that occurs in my Laravel App happens in Node.js.

Clearly, I need to use an API, but I am confused about how to do it in a manner that is secure. I have looked into this article:

https://www.ida.liu.se/~TDP024/labs/hmacarticle.pdf

And have looked through their algorithm into building an API. But I do not understand how it would be secure.

According to the post, you store a public and private key in a Database. The public key can be seen by everyone but the private key is, well, private. However, when sending it to the server, you send a hashed version along with other data, of the private to the server.

This sounds all well and fine. However, does that not mean that the public key and the hash is public, thus the private key is exposed as well?

For example lets say I try to establish the following connection

ws://example.com/pull?public=A89-3NJ2-KAN-NKSN1&hash=QmFzZTY0IHRoZSBoZWxsIG91dCBvZiBtZSBiYWJ5Li4uLi4u

What stops another user from just sharing this link giving an unrelated user access to it?

Answer 1

The article you linked to describes how to authenticate one single request , not an entire session. That is, the user sends the public api_key along with some request data that describes the specific request for the API (like, { "action":"latest_price", "symbol":"GOOG"} for a stock market API).

To authenticate, the user also uses a shared API-access secret key as an HMAC key to compute HMAC(secret, api_key+request) . No one else can compute this if they don't know the secret . Only the user and the server should know secret , because it's basically the user's password to use the API.

The situation you describe is very different: you're using a WebSocket, so I assume you'll be sending requests interactively. If you want to authenticate the entire socket session, this approach doesn't make sense, since it's designed to authenticate a single request. You can apply this approach to individual requests inside the WebSocket connection.

For authenticating a new connection (ie, "what logged-in user is opening this connection?") using auth cookies is appropriate, just as you would for a traditional HTTP connection.

---

Below, I'll assume that the purpose of the Web Socket is to send only one request (which really makes me wonder why it's a WebSocket), so that the request-level authentication makes sense.

What stops another user from just sharing this link giving an unrelated user access to it?

Nothing. Do you want someone else to submit a specifc request, while impersonating you? Then by all means, give them that link and tell them to use it.

The credentials in the link include an HMAC of the API request (plus your identity) that only you can generate, as the sole owner on your API secret key. If you give that HMAC to someone else, they can submit it and impersonate you for that specific request. However, they cannot create more requests, because they don't have your API secret to make more HMAC values for different requests.

In fact, if you didn't want that request to be submitted, you should not have used your secret to create the authenticating HMAC in the first place! Why did your authenticate a request that you didn't intend to be submitted?

Answer 2

Have a look at this

Essentially

1. make a "websocket preauth" request to the backend from the browser using the site's normal auth
2. backend returns a CSRF token in the response body and sets a "websocket auth" cookie with SameSite=Strict in the response headers
3. attempt to establish a websocket connection with the backend, with the addition of the CSRF token in a query parameter
4. the backend checks
   • that the websocket auth cookie and CSRF token are valid
   • that the value of the Origin header matches an approved domain
5. the backend sends a response and upgrades the connection to use websockets