【问题标题】:SignalR group security considerationsSignalR 组安全注意事项
【发布时间】:2020-06-22 13:54:56
【问题描述】:

希望您能帮助解决这个问题。我们有一个基于浏览器的支持应用程序,它使用 SignalR 进行客户聊天。该解决方案包含两个 Web 应用程序:admin.[domain].comsupport.[domain].com。两者都是 C# ASP.NET CORE 3.1 MVC 应用程序。

支持工程师使用管理应用程序来服务聊天。 SignalR 集线器托管在管理应用程序中。管理应用使用 ASP.NET CORE 身份进行身份验证和授权。

但是,支持应用程序没有身份机制 - 我们需要一个“低摩擦”解决方案,用户只需连接到 support.domain.com/{GUID},不需要密码。 GUID 是由支持工程师预先生成的 SignalR 组名称。到达这条路线后,支持应用会调用AddToGroup(GUID)

SignalR 文档指出组不是一种有效的安全机制。但是,如果组名是 GUID,并且我们从不发送给所有客户端,那么这是一种相当安全的方法吗?

消息只能在组内发送或接收。 GUID 使组名非常安全,我原以为会这样。

如果群组名称是未知的 GUID,聊天是否容易被窃听?是否有比这种方法更好/更安全的替代方法,无需客户端输入密码?

【问题讨论】:

    标签: signalr asp.net-core-signalr


    【解决方案1】:

    正如你所说的那样,groups are not a security mechanism。但在你的情况下,你想做的很好,因为只要用户连接到集线器,并且组管理是由管理员进行的,在聊天会话之后管理员可以删除组,这样用户就不能稍后加入。

    您需要明确说明这是一个公共会话,就像您可以在白板等应用中看到的那样,如果用户有邀请链接,他们可以加入其中。

    我还建议实施一些ttl 机制,让组在一段时间后过期,以便用户稍后不要加入会话。

    最后,只需做一些防御性编码,例如,一次只允许每个组中的 1 个管理员和 1 个用户,等等...

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2017-01-14
      • 2014-08-19
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多