我正在做一个项目,后端是用无服务器框架构建的。最近,我添加了一个使用API Gateway的Websockets的功能。然而,我对我的特定实现的安全性有怀疑,想问一下它们的有效性如何。
我努力在我的websocket路由中建立认证。有一个授权功能,但不幸的是,原生的Javascript API不提供编辑Websocket消息中的头信息的方法--这意味着我必须在url params中提交授权令牌,我宁愿不这样做。
我想出了一个变通办法。我在API Gateway上设置了现有的HTTP微服务,采用无服务器方式,通过AWS Cognito Identity Federation进行认证。我的解决方案是将我的websocket认证 "搭载 "到我的HTTP服务上,如下所示。
我在Heroku找到了这个关于websocket安全的资源,它推荐了一个类似但不完全相同的过程。https:/devcenter.heroku.comarticleswebsocket -security(网络插座安全)
它建议如下。
"所以,我们所看到的一种模式 似乎很好地解决了WebSocket的认证问题 是一种基于 "票据 "的认证系统。广义上讲,它的工作原理是这样的。
当客户端代码决定打开一个WebSocket时 它会联系HTTP服务器以获得一个授权 "票"。
服务器会生成这个票据。它通常包含某种用户账户 ID、请求该票据的客户端的 IP、时间戳以及您可能需要的任何其他内部记录。
服务器存储此票据(即在数据库或缓存中),并将其返回给客户端。
客户端打开 WebSocket 连接,并将此 "票据 "作为初始握手的一部分发送。
然后,服务器可以比较该票据,检查源 IP,验证该票据是否被重复使用,是否过期,并进行任何其他类型的权限检查。如果一切顺利,现在就验证了WebSocket连接。"
据我所知,我的方法和heroku的方法很相似,都是使用HTTP方法来验证,但不同的是,因为
1)Heroku的方法在打开时检查认证,而我的方法在打开后检查2)Heroku的方法需要生成和存储安全的代币
我不想通过websocket发送授权,因为我必须把它存储在url params中,而且我也不想生成和存储令牌,所以我采用了我的方法。
但是,我对我的方法也有几个疑问。
1)因为我没有在websocket打开时检查授权,所以理论上这种方法很容易受到dDos攻击,攻击者只要打开尽可能多的socket就可以了。我这里的假设是,责任落在API Gateway上,用它的Leaky Bucket算法来防止。
2)我的策略取决于连接ID是否安全。如果攻击者能够欺骗这个连接Id,那么我的策略将不再有效。我假设这个connectionId是在API Gateway内部发出的,用来标记特定的连接,应该不会因此而受到攻击。然而,我想仔细检查一下是否是这样。
我建议看看JWT的。它是一种为这个目的创建的,你需要有一些方法来验证客户端的请求,而不暴露凭证。它是完全自带的,允许你不在每次提出请求时向数据库提出请求,以验证提出请求的用户。https:/jwt.io。
JWT在Serverless中很容易实现,并附加到web套接字连接请求中。然后你可以做一些事情,比如将用户IP地址添加到JWT的有效载荷中,并在请求时进行验证,以确保用户100%被验证。