Broadcast-box项目中Bearer Token空格处理问题的技术解析

在Glimesh的Broadcast-box项目中，开发者发现了一个关于Bearer Token处理的潜在安全问题。当用户在网页浏览器中输入包含空格的Token时，浏览器会自动将空格转换为"%20"编码，而OBS(Open Broadcaster Software)返回的Token则保持原始空格形式。这种不一致性导致了流媒体加载流程的中断，因为现代浏览器不允许在HTTP请求中直接发送未经编码的空格字符。

问题本质分析

HTTP协议规范(RFC 3986)明确规定了URI中需要编码的特殊字符。空格字符作为保留字符之一，必须被编码为"%20"才能在URI中安全传输。当Token包含空格时，未经处理的原始Token会导致HTTP请求构造失败，进而影响整个流媒体传输流程。

技术解决方案

针对这一问题，开发者提出了两种解决思路：

1. 黑名单过滤方案：使用正则表达式匹配所有需要编码的特殊字符，包括但不限于空格。建议的黑名单模式为[:/#@!$&',;=% \*\+\(\)\?\[\]]，涵盖了RFC 3986中定义的所有保留字符和需要编码的特殊字符。

2. 白名单过滤方案：采用更严格的安全策略，只允许特定的安全字符通过。建议的白名单模式为[A-Za-z0-9_~\-\.]，仅包含字母数字和下划线、波浪线、连字符及点号等安全字符。

实现建议

在Go语言实现中，应在处理WHEP/WHIP请求的代码位置添加字符过滤逻辑。具体来说，可以在解析Token的环节加入字符验证和转换处理：

• 对于输入Token，先进行规范化处理，将所有需要编码的字符统一转换为百分号编码形式
• 或者更严格地，直接拒绝包含非法字符的Token请求
• 在处理流程早期进行验证，避免非法字符进入后续处理环节

安全考量

除了空格问题外，开发者还应考虑其他可能的安全风险：

1. 注入攻击防护：未过滤的特殊字符可能被用于HTTP头注入或其他形式的注入攻击
2. 一致性保证：确保所有客户端(浏览器、OBS等)和服务器端对Token的处理方式一致
3. 错误处理：对非法Token应提供清晰的错误反馈，帮助用户快速定位问题

总结

Bearer Token中的空格处理问题看似简单，实则涉及HTTP协议规范、浏览器行为一致性以及应用安全等多个方面。通过实施严格的字符过滤和编码处理，不仅可以解决当前的空格问题，还能提升整个系统的安全性和健壮性。对于类似Broadcast-box这样的流媒体服务项目，正确处理各种边缘情况对保证服务稳定性至关重要。