5. セキュリティ上の考慮事項 (Security Considerations)
5. セキュリティ上の考慮事項 (Security Considerations)
PATCH のセキュリティ上の考慮事項は、PUT のセキュリティ上の考慮事項 ([RFC2616], セクション 9.6) とほぼ同じです. これには、リクエストの承認 (アクセス制御や認証を通じて可能) と、転送エラーや偶発的な上書きによってデータが破損しないことの確保が含まれます. PUT に使用されるメカニズムはどれでも PATCH にも使用できます. 次の考慮事項は特に PATCH に適用されます.
パッチが適用されたドキュメントは、完全に上書きされたドキュメントよりも破損する可能性が高い場合がありますが、この懸念は、セクション 2 で説明されているように、ETag と If-Match リクエストヘッダーを使用する条件付きリクエスト (conditional requests) などのメカニズムを使用することで対処できます. 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) で大きすぎるパッチドキュメントを拒否することをお勧めします.
- アプリケーション設計者は、複数の場所に分散している可能性のあるリソースに対するパッチ操作の影響を考慮する必要があります. たとえば、パッチはリソースの 1 つのコピーでは成功するが別のコピーでは失敗し、リソース状態の相違 (resource state divergence) を引き起こす可能性があります.