RTSP协议（18）——安全注意事项（RFC2326）

RTSP协议（18）——安全注意事项

原文第十六章

由于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：尽管rtspurl是不透明的句柄，不一定具有文件系统语义，但是可以预期许多实现会将请求url的一部分直接转换为文件系统调用。在这种情况下，文件系统应该遵循[H15.5]中概述的预防措施，例如检查路径组件中的“.”。
• Personal Information：RTSP客户机通常与HTTP客户机拥有相同的信息（用户名、位置等），因此应该是平等的。更多建议见[H15.6]。
• Privacy Issues Connected to Accept Headers：由于RTSP中可能存在与HTTP中相同的“Accept”头，因此应遵循[H15.7]中概述的关于其使用的相同警告。
• DNS Spoofing：大概，考虑到与RTSP会话相关联的连接时间通常比HTTP会话长，RTSP客户端DNS优化应该不那么普遍。尽管如此，[H15.8]中提供的建议仍然适用于任何试图依赖DNS-to-IP映射的实现，而不仅仅是一次使用映射。
• Location Headers and Spoofing：如果一台服务器支持多个彼此不信任的组织，那么它必须检查在所述组织的控制下生成的响应中的位置和内容位置头的值，以确保它们不会试图使它们没有权限的资源无效([H15.9]）

除了当前HTTP规范中的建议（rfc2068[2]，截至本文撰写之时），未来的HTTP规范可能会提供关于安全问题的额外指导。

以下是RTSP实现的附加注意事项。

• Concentrated denial-of-service attack：该协议为远程控制的拒绝服务攻击提供了机会。攻击者可以通过在安装请求中将一个或多个IP地址指定为目标来发起到这些地址的通信流。虽然在这种情况下攻击者的IP地址可能是已知的，但这在防止更多攻击或确定攻击者身份方面并不总是有用的。因此，如果RTSP服务器已经使用RTSP身份验证机制（最好是摘要身份验证或更强的身份验证）或其他安全手段，对照已知用户的数据库验证了客户机的身份，则RTSP服务器应该只允许客户机指定的RTSP发起的通信流目的地。
• Session hijacking：由于传输层连接和RTSP会话之间没有关系，因此恶意客户机可能会发出带有随机会话标识符的请求，这将影响不知情的客户机。服务器应该使用一个大的、随机的、非连续的会话标识符来最小化这种攻击的可能性。
• Authentication：服务器应该实现基本和摘要[8]身份验证。在对控制消息的安全性要求更高的环境中，可以对RTSP控制流进行加密。
• Stream issues：RTSP只提供流控制。本节和本备忘录的其余部分均未涉及流式交付问题。RTSP实现很可能依赖于其他协议，如RTP、IP多播、RSVP和IGMP，并且应该解决这些和其他适用规范中提出的安全考虑。
• Persistently suspicious behavior：RTSP服务器在接收到被视为存在安全风险的单个行为实例时，应返回错误代码403（禁止）。RTSP服务器还应该知道有人试图探测服务器的弱点和入口点，并且可以任意断开和忽略被视为违反本地安全策略的客户端的进一步请求。