web-dev-qa-db-ja.com

HTTP PUTおよびDELETEメソッドが本当に安全である場合、どのように安全でないのですか？

これらの方法を本当に使用する必要がある場合、それらが安全であることをどのように確認しますか？

編集：「PUT」および「DELETE」メソッドがリソースを削除または更新できないことを確認する方法を確認できるリンクまたはソースがありますが、サービスおよびサーブレットは引き続きPUTおよびDELETEを使用できます。

次のサービスはPUTおよびDELETE HTTPメソッドを使用しています

https://developers.google.com/drive/v2/reference/files/delete

http://developers.facebook.com/docs/reference/api/Comment/

http://docs.aws.Amazon.com/AmazonS3/latest/API/RESTObjectDELETE.html

http://www.salesforce.com/us/developer/docs/api_rest/index.htm

http://developer.tradeshift.com/rest-api/#tsapi.conventions

http://developer.linkedin.com/documents/groups-api#create

https://developer.Paypal.com/webapps/developer/docs/api/#delete-a-stored-credit-card

したがって、HTML、CSS、JS、画像などのリソースファイルを害することなく、PUTとDELETEを確実に使用できる方法が必要です。

httpserver
9
gurvinder372

PUTとDELETEは本質的に安全ではなく、たとえば RESTサービス で問題なく使用されます。

私の実践では、これらのHTTP動詞に関連する主な問題（一般的な認証と承認の問題は別として）は、サーバーオペレーターがそれらの存在に気付かず、 HTTP動詞の改ざん の可能性をもたらしていました。要約すると、これはアクセス制御がHTTP動詞のブラックリストに基づいて実装されていたが、あまり知られていない動詞がこのリストから欠落していて、アクセス制御のバイパスを可能にしたことを意味します。

多くのWebサーバーが独自のカスタム（ドキュメント化されていない場合もある）HTTP動詞を実装しているため、このような「動詞ベースのアクセス制御」は、あまり良い考えではないようです。

11
buherator

HTTPメソッドは、それ自体のセキュリティとはほとんど関係がありません。 DELETE /users/1のようなメソッドは、POST /users/1/deleteまたはGET /users/1/deleteとしても簡単に実装できます（GETには副作用があってはなりませんが、一部の開発者がそうすることを妨げるものではありません）。

したがって、他のHTTPメソッドと同様に扱う必要があります。 GETはサーバーの状態を変更すべきではないため、通常は、クライアントが要求されたリソースへの読み取りアクセス権を持っていることを確認するだけで済みます。 PUTは、リソースを完全にインプレースで更新するために使用する必要があります（多くの場合、PATCH動詞と同様に使用されます）。そのため、クライアントにこれを実行する特権があることを確認する必要があります。同様に、リソースの削除を要求するには、DELETEを送信する必要があります。したがって、ユーザーにそうする権限があることを確認する必要があります。

つまり、動詞を、ユーザーが実行したいアクションのタイプの記述子として扱います。特定のアプリケーションのセキュリティパラメータで必要とされるように、これらのアクションを実行することを認証および承認します。

10
Stephen Touset

OWASPテストガイドから：

これらの方法の中には、攻撃者がWebサーバーに保存されているファイルを変更したり、場合によっては正当なユーザーの資格情報を盗んだりする可能性があるため、Webアプリケーションにセキュリティリスクをもたらす可能性があります。具体的には、無効にする必要があるメソッドは次のとおりです。

  • PUT：この方法では、クライアントがWebサーバーに新しいファイルをアップロードできます。攻撃者は悪意のあるファイルをアップロードすることでそれを悪用できます
    （例：cmd.exeを呼び出してコマンドを実行するaspファイル）、または被害者のサーバーをファイルリポジトリとして使用する

とはいえ、実際に注意する必要があることが2つあります。

  • これらのユーザーに新しいコンテンツの作成を許可する場合は、信頼できる認証済みユーザーにのみ許可するようにしてください。これらのユーザーは、FTPアカウントを持つことを許可する範囲で信頼されている必要があります。
  • 既存のコンテンツの変更を許可する場合は、実際に特定の既存のリソースのみを上書きできるを上書きできるように制限してください。

また、SSL/TLSを使用していることも確認してください。

7
Lucas Kauffman

レコードの場合： RFC 2616 Hypertext Transfer Protocol HTTP/1.1/Method-Section

rEQUESTはクライアントからサーバーへの要求であり、サーバーがその要求で何をするかについてはあまり言わないでください。可能なメソッドはサーバーレベルで実装する必要はありません。

そのため、myserver.comにアクセスして「DELETE/blah」を要求すると、myserver.comは「thanx、sir、and a nice day」と簡単に言うことができます。

9.6置く

PUTメソッドは、囲まれたエンティティが指定されたRequest-URIの下に格納されることを要求します。

9.7削除

DELETEメソッドは、OriginサーバーがRequest-URIで識別されるリソースを削除することを要求します。このメソッドは、Originサーバーでの人間の介入（または他の手段）によってオーバーライドされる場合があります。オリジンサーバーから返されたステータスコードがアクションが正常に完了したことを示している場合でも、クライアントは操作が実行されたことを保証できません

2
that guy from over there