Signal R URL传递连接令牌的原因及ASP.NET MVC项目安全问询

1. 相关URL为何以GET请求呈现？ #

SignalR的初始握手流程采用GET请求是其内置设计：

• 该请求核心目的是协商实时传输协议（客户端与服务器确认可用通信方式，如WebSockets、Server-Sent Events、Long Polling），本质是获取连接所需元数据，符合HTTP GET语义（仅获取资源，不修改服务器状态）。
• GET请求便于客户端传递基础协商参数（如自身支持的传输方式列表），同时服务器返回connectionId、支持的传输方案等关键信息，为后续持久连接铺路。

2. 是否存在应用威胁？ #

默认场景下，SignalR的GET握手请求本身不存在直接威胁，但需关注以下风险点：

• 明文传输风险：未启用HTTPS时，握手请求中的connectionId等参数会明文传输，可能被中间人劫持用于伪造连接。
• 未授权访问：若SignalR端点未配置身份验证，未授权用户可通过握手建立连接，获取敏感实时数据或发起恶意请求。
• 自定义参数泄露：如果项目代码在握手请求的查询字符串中额外传入敏感数据（如数据库连接字符串、用户密钥），则会存在信息泄露风险——这属于代码实现问题，而非SignalR内置机制的漏洞。

若仅使用SignalR默认握手流程（无自定义敏感参数+HTTPS+身份验证），威胁程度极低。

3. 如何移除URL查询字符串中的连接字符串？ #

首先明确两种场景的处理方式：

• 自定义传入的敏感连接字符串：直接定位代码中添加该参数的位置，删除相关逻辑即可——绝对禁止在GET请求的查询参数中传递敏感信息。
• SignalR内置的连接相关参数（如connectionId、transport）：这些是握手流程必需的，无法直接移除，但可通过以下方式降低风险：
  • 强制启用HTTPS：加密所有请求传输内容，避免参数被明文截取。
  • 自定义扩展改为POST握手：SignalR 2.x默认用GET，但可通过重写握手中间件，将握手请求改为POST，参数放入请求体而非查询字符串（需手动实现此逻辑）。

4. 该内置握手流程的具体用途 #

SignalR的内置GET握手流程是实时通信的前置核心步骤，用途包括：

• 传输协议协商：客户端告知服务器自身支持的实时传输方式，服务器返回最优方案（优先WebSocket， fallback到其他方案），确保跨环境兼容性。
• 连接身份标识：服务器生成唯一connectionId并返回给客户端，用于后续通信中标识特定客户端连接。
• 元数据传递：返回连接超时时间、是否支持心跳等配置信息，确保客户端与服务器的连接参数一致。
• 权限预校验：若配置了身份验证，握手阶段会提前验证用户权限，拒绝未授权客户端的连接请求。

内容的提问来源于stack exchange，提问作者cachet.net