16 Security Considerations (安全考虑)
16 Security Considerations (安全考虑)
由于 RTSP 服务器与 HTTP 服务器在语法与用法上的相似性, [H15] 概述的安全考虑适用。尤其请注意:
Authentication Mechanisms (认证机制): RTSP 与 HTTP 共享常见认证方案, 因此在认证方面应遵循相同规定。客户端认证问题见 [H15.1], 支持多种认证机制的问题见 [H15.2]。
Abuse of Server Log Information (滥用服务器日志信息): RTSP 与 HTTP 服务器可能采用类似的日志机制, 因此应同样谨慎保护日志内容, 从而保护服务器用户的隐私。关于服务器日志的 HTTP 服务器建议见 [H15.3]。
Transfer of Sensitive Information (敏感信息传输): 没有理由认为经 RTSP 传输的信息比通常经 HTTP 传输的信息敏感性更低。因此, 关于数据隐私与用户隐私保护的所有预防措施均适用于 RTSP 客户端, 服务器与代理的实现者。进一步细节见 [H15.4]。
Attacks Based On File and Path Names (基于文件与路径名的攻击): 尽管 RTSP URL 为不透明句柄, 未必具有文件系统语义, 但预期许多实现会将请求 URL 的部分直接映射为文件系统调用。此类情况下, 文件系统 SHOULD 遵循 [H15.5] 中的预防措施, 例如检查路径分量中的 ".."。
Personal Information (个人信息): RTSP 客户端常能接触与 HTTP 客户端相同的信息 (用户名, 位置等), 因此应同等对待。进一步建议见 [H15.6]。
Privacy Issues Connected to Accept Headers (与 Accept 头部相关的隐私问题): 由于 RTSP 中存在许多与 HTTP 相同的 "Accept" 头部, 应遵循 [H15.7] 关于其使用的相同警示。
DNS Spoofing (DNS 欺骗): 鉴于 RTSP 会话相对 HTTP 会话通常连接时间更长, RTSP 客户端的 DNS 优化可能较少。尽管如此, [H15.8] 的建议对任何试图依赖单次映射使用之后仍成立的 DNS 到 IP 映射的实现仍然相关。
Location Headers and Spoofing (Location 头部与欺骗): 若单台服务器支持多个互不信任的组织, 则必须检查在这些组织控制下生成的响应中的 Location 与 Content-Location 头部值, 确保其不试图使它们无权处置的资源失效。 ([H15.9])
除当前 HTTP 规范 (本文撰写时为 RFC 2068 [2]) 中的建议外, 未来 HTTP 规范可能对安全问题提供额外指导。
以下为针对 RTSP 实现的补充考虑。
Concentrated denial-of-service attack (集中的拒绝服务攻击): 本协议为远程控制的拒绝服务攻击提供机会。攻击者可在 SETUP 请求中将一个或多个 IP 地址指定为目的地址从而发起流量。此情形下可能知道攻击者 IP 地址, 但这并不总能阻止更多攻击或确定攻击者身份。因此, RTSP 服务器 SHOULD 仅在已验证客户端身份 (通过 RTSP 认证机制 (优选 digest authentication 或更强) 对照已知用户数据库, 或其他安全手段) 后, 才允许客户端为 RTSP 发起的流量指定目的地址。
Session hijacking (会话劫持): 由于传输层连接与 RTSP 会话无绑定关系, 恶意客户端可能使用随机会话标识符发出请求从而影响无辜客户端。服务器 SHOULD 使用大随机且非顺序的会话标识符以降低此类攻击可能。
Authentication: 服务器 SHOULD 同时实现 basic 与 digest [8] 认证。在需要对控制消息有更高安全性的环境中, 可对 RTSP 控制流加密。
Stream issues: RTSP 仅提供流控制。流投递问题不在本节及本备忘录其余部分讨论。RTSP 实现很可能依赖 RTP, IP multicast, RSVP, IGMP 等其他协议, 并应处理那些及适用规范中提出的安全考虑。
Persistently suspicious behavior: RTSP 服务器 SHOULD 在收到单次被视为安全风险的行为时返回错误码 403 (Forbidden)。RTSP 服务器 SHOULD 亦注意探测服务器弱点与入口的企图, 并 MAY 任意断开并忽略进一步违反本地安全策略的客户端请求。