amazon-web-services - 我可以依靠 ConnectionId 来确保 API 网关 Websocket 的安全性吗？

Question

我正在开发一个使用无服务器框架构建后端的项目。最近，我使用 API Gateway 的 websockets 添加了一个功能。但是，我对我的特定实现的安全性存有疑问，并想询问它们的有效性。

我努力将身份验证构建到我的 websocket 路由中。有一个授权器功能，但不幸的是，原生 Javascript API 无法提供编辑 Websocket 消息中的 header 的方法——这意味着我必须在 url 参数中提交授权 token ，我不想这样做。

我想出了一个解决方法。我在 API 网关上设置了现有的无服务器 HTTP 微服务，并通过 AWS Cognito Identity Federation 进行了身份验证。我的解决方案是将我的 websocket 身份验证“搭载”到我的 HTTP 服务上，如下所示。

1. 我的客户端打开一个 websocket 连接，并接收回 API 网关分配给它的 connectionId。
2. 我的客户端使用已通过 Cognito 身份验证的 connectionId 调用 HTTP 路由。这用于让我的后端知道此特定的 connectionId 已通过身份验证。我将 connectionId 和 Cognito 身份以及其他信息推送到数据库。这样，稍后我可以找到与特定 Cognito 身份关联的 connectionId。
3. 当客户端想要调用“安全”websocket 方法时，websocket 方法会检查查找表以查看该 connectionId 是否与正确的 Cognito 身份相关联。如果是，则该方法通过。否则，连接将关闭。

我在 Heroku 上找到了这个关于 websocket safety 的资源，它推荐了一个类似但不完全相同的过程:https://devcenter.heroku.com/articles/websocket-security

建议如下:

"So, one pattern we’ve seen that seems to solve the WebSocket authentication problem well is a “ticket”-based authentication system. Broadly speaking, it works like this:

When the client-side code decides to open a WebSocket, it contacts the HTTP server to obtain an authorization “ticket”.

The server generates this ticket. It typically contains some sort of user/account ID, the IP of the client requesting the ticket, a timestamp, and any other sort of internal record
keeping you might need.

The server stores this ticket (i.e. in a database or cache), and also returns it to the client.

The client opens the WebSocket connection, and sends along this “ticket” as part of an initial handshake.

The server can then compare this ticket, check source IPs, verify that the ticket hasn’t been re-used and hasn’t expired, and do any other sort of permission checking. If all goes well, the WebSocket connection is now verified."

据我所知，我的方法是 heroku 的相似之处在于它们都使用 HTTP 方法进行身份验证，但不同之处在于

1) Heroku 的方法在打开时检查身份验证，而我的方法随后检查2) Heroku的方法需要生成和存储安全 token

我不想通过 websocket 发送授权，因为我必须将它存储在 url 参数中，而且我也不想生成和存储 token ，所以我采用了我的方法。

但是，我对我的方法也有一些疑问。

1) 因为我不检查打开 websocket 的授权，理论上这种方法容易受到 dDos 攻击，攻击者只需打开尽可能多的套接字。我在这里的假设是责任落在 API Gateway 身上，用它的漏桶算法来防止。

2) 我的策略取决于 connectionId 的安全性。如果攻击者能够欺骗此 connectionId，那么我的策略将不再有效。我假设此 connectionId 是在 API 网关内部发布的，用于标记特定连接，因此不应受到攻击。但是，我想仔细检查一下是否是这种情况。

Answer 1

我建议研究一下 JWT。它是为此目的而创建的，您需要有一些方法来验证客户端请求而不暴露凭据。它是完全独立的，允许您在每次发出请求以验证发出请求的用户时不向数据库发出请求:https://jwt.io/

JWT 很容易在无服务器中实现并附加到网络套接字连接请求。然后，您可以执行一些操作，例如将用户 IP 地址添加到 JWT 的负载中，并在请求时对其进行验证，以确保用户 100% 得到验证。