5. 安全考虑事项 (Security Considerations)

5. 安全考虑事项 (Security Considerations)

PATCH 的安全考虑事项几乎与 PUT 的安全考虑事项相同 ([RFC2616] 第 9.6 节). 这些事项包括对请求进行授权 (可能通过访问控制和/或认证), 并确保数据不会因传输错误或意外覆盖而损坏. 用于 PUT 的任何机制也可以用于 PATCH. 以下考虑事项尤其适用于 PATCH.

被打补丁的文档可能比被整体覆盖的文档更容易损坏, 但可以通过第 2 节所述机制来处理这一顾虑, 例如使用 ETags 和 If-Match request header 的条件请求. 如果 PATCH 请求失败, 客户端可以对该资源发出 GET 请求, 以查看它处于什么状态. 在多数情况下, 客户端可以检查资源内容, 判断 PATCH 是否产生了预期状态.

有时, HTTP 中介可能会通过检查 PUT/POST 请求或 GET 响应的正文, 尝试检测经由 HTTP 发送的病毒. PATCH 方法会使这种监测变得复杂, 因为源文档和补丁文档本身都可能不是病毒, 但结果却可能是病毒. 这一安全考虑事项与字节范围下载, 下载补丁文档, 上传 zipped (compressed) files 等已经引入的考虑事项并无实质区别.

各个补丁文档格式都会有自身特定的安全考虑事项, 并会随这些格式一起记录. 使用 PATCH 的应用程序应考虑与其所支持具体格式相关的所有安全考虑事项. 不过, 有些通用考虑事项适用于所有补丁文档格式, 包括:

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