Flash Media Server：如何全面保护流？
我正在FMS上开发一个轻量级的保护机制。目前，我可以使用主服务器提供的 SSO 令牌对用户进行身份验证。然而，验证SSO Token需要另一台服务器的WebService/RemoteObject，这对于大量并发用户来说是昂贵且不现实的。因此，我为每个成功验证的用户创建了一个会话，将会话 ID 返回给用户，用户可以使用它进行进一步的连接。
在这个解决方案中我要担心的是会话劫持攻击。如果冒名顶替者成功嗅探到我客户的请求，他就可以使用该会话 ID 来获取我的流。为了防止这种情况，我有两个解决方案：第一，每个客户端将创建两个到服务器的连接，一个用于控制消息（例如NetConnection.call函数）的SSL连接，一个用于流数据。另一个是创建一个安全的 RTMPE 通道来获取流。两者都需要更多的处理能力来实现（后者多15%，不知道前者是多少）。
对于我的问题有更好的解决方案吗？
I am developing a lightweight protection mechanism on FMS. Currently, I can authenticate user using SSO Token provided by main server. However, authenticating SSO Token requires WebService/RemoteObject of another server, which is expensive and unrealistic for large number of concurrent users. Hence, I created a session for each successfully validated user, returned session ID back to user and user can use this for further connections.
What I have to concern in this solution is session hijacking attack. An imposter can use that session ID to get my stream, if he successfully sniffed my customer's request. To prevent this, I have two solutions: First, every client will create two connections to server, one SSL for control message (e.g. NetConnection.call function), one for streaming data. The other is creating a secured RTMPE channel to get the stream. Both require more processing power to implement (15% more for the latter, don't know how much is the former).
Is there any better solution for my problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果 FMS 和 SSO 服务器之间没有通信，就无法防止会话令牌被劫持。
您至少可以做的是，当您的客户端通过 SSO 端时创建一个单次使用令牌，存储它，并且当玩家连接到 FMS 时，您使该令牌失效。您可以使用 redis+nginx 设置来处理这些令牌，让您的 SSO 将它们存储在那里，并在 FMS 上编写一个插件以使它们过期，而不是使用 WebServices 或 RemoteObjects。
快乐编码！ 8）
There's no way you can prevent your session token from being hijacked without some communication between your FMS and your SSO server.
The least you could do is create a single use token when your client goes through the SSO side, store it, and when the player connects to FMS you invalidate that token. You could use a redis+nginx setup to handle those tokens, make your SSO store them there and write a plugin on FMS to expire them instead of using WebServices or RemoteObjects.
Happy coding! 8)