5. 安全性考量 (Security Considerations)

5. 安全性考量 (Security Considerations)

PATCH 的安全性考量几乎与 PUT 的安全性考量相同 ([RFC2616], 第 9.6 节). 这些包括授权请求 (可能通过访问控制和/或身份验证) 以及确保数据不会通过传输错误或意外覆盖而损坏. 用于 PUT 的任何机制都可以用于 PATCH. 以下考量特别适用于 PATCH.

被打补丁的文档可能比完全覆盖的文档更容易损坏, 但这种担忧可以通过使用条件请求 (conditional requests) 等机制来解决, 例如使用 ETag 和第 2 节中描述的 If-Match 请求头. 如果 PATCH 请求失败, 客户端可以向资源发出 GET 请求以查看其处于什么状态. 在大多数情况下, 客户端可以检查资源的内容以查看 PATCH 是否导致了预期的状态.

有时 HTTP 中间件 (intermediary) 可能会尝试通过检查 PUT/POST 请求或 GET 响应的主体来检测通过 HTTP 发送的病毒. PATCH 方法使这种监视变得复杂, 因为源文档和补丁文档都可能不是病毒, 但结果可能是. 这种安全性考量与字节范围下载 (byte-range downloads), 下载补丁文档, 上传压缩文件等已经引入的安全性考量没有实质性差异.

各个补丁文档格式将有其自己的特定安全性考量, 这些考量将与这些格式一起记录. 使用 PATCH 的应用程序应考虑与它们支持的特定格式相关的所有安全性考量. 不过, 一些一般性考量适用于所有补丁文档格式, 包括:

• 补丁文档可能包含修改客户端无权修改的资源部分的指令. 此类 PATCH 应该被服务器拒绝.
• 某些补丁文档格式可能有条件请求的规定. 服务器必须 (MUST) 确保此类条件是根据操作时资源的状态而不是请求时的状态来评估的.
• 服务器必须 (MUST) 谨慎验证包含不可信内容 (例如, 用户提供的数据) 的资源. 许多验证操作需要解析资源, 而解析不可信内容会带来拒绝服务攻击 (denial-of-service attacks) 和其他恶意行为的机会.
• 补丁文档可能在补丁文档格式中没有定义最大大小. 服务器可能希望为补丁文档建立自己的最大大小以保护自己免受使用非常大的补丁文档的攻击, 并使用状态码 413 (Request Entity Too Large) 拒绝过大的补丁文档.
• 应用程序设计者应考虑补丁操作对可能分布在多个位置的资源的影响. 例如, 补丁可能在资源的一个副本上成功但在另一个副本上失败, 导致资源状态分歧 (resource state divergence).