我正在尝试为注册成员区域的安全WebSocket服务器（wss）验证客户端。
一旦成员连接到Web服务器，我就会在数据库中记录一个唯一的令牌（与该成员相关联），该令牌显示在启动与Web Socket服务器连接的页面上的隐藏字段中。
然后将令牌发送到WebSocket服务器，该服务器使用令牌对帐户进行身份验证。
我真的不是安全专家，我希望您对我的身份验证的安全性有所了解。
是否存在任何风险（除了cookie劫持）？考虑到WebSocket没有规定服务器在WebSocket握手期间可以对客户端进行身份验证的任何特定方式，还有更好的方法可以继续。
我使用Ratchet WebSocket。
答案 0 :(得分：6)
是的，一种选择是使用cookie（以及TLS以避免cookie劫持）：
在基于＆＃34;普通旧HTML表单＆＃34;之后设置cookie。登录，将cookie传输到WebSocket服务器，并使用cookie来验证WebSocket。
以下是使用WebSocket进行基于 Mozilla Persona 身份验证的complete example。
你询问了Ratchet。这个例子不是Ratchet，但它可能会给你一些线索 - 这就是我认为可以指出的原因。答案 1 :(得分：-6)
有任何风险......
是的，很多。 PKI / PKIX和SSL / TLS存在许多架构缺陷。有关完整治疗，请参阅Peter Gutmann的Engineering Security。
此外，WebSockets不允许您查询基础连接的属性。所以，据我所知，你甚至无法判断你是否真正使用SSL / TLS。你唯一知道的就是你要求它。
有没有更好的方法继续考虑WebSocket
我最后一次检查时，WebSockets非常蹩脚。您要做的就是open，read和write。它们旨在易于使用，但缺乏与安全性相关的任何有用的东西。
为了完整起见，我上次检查的时间是2013年3月，同时对使用它们的应用进行安全评估。事情可能已经改变了。
我还尝试与WebSockect RFC作者和RFC编辑器讨论一些安全问题的问题。所有的电子邮件都没有得到答复。
更新（2015） ：它变得更好......浏览器和其他用户代理现在有Host Public Key Pinning。
但是，如果您查看详细信息，应称为“使用替换的主机公钥固定”。内置的覆盖允许攻击者破坏良好的pinset。更糟糕的是，浏览器在掩盖中是同谋，因为必须抑制失败的引脚报告。
您可以在Comments on draft-ietf-websec-key-pinning阅读更多关于它（以及反驳）的投诉。
它是一个永远不应该标准化的垃圾标准。它更不安全的浏览器垃圾。