RESTfulアプリケーションで、GETおよびPOST以外のすべてのメソッドをブロックする必要があるのはなぜですか？
TL; DR：
WebアプリケーションでHTTP PUTおよびDELETEメソッドの使用を停止し、GETおよびPOSTのみを使用するようにソフトウェアベンダーに要求する正当な理由はありますか？アプリケーションはフレームワークを使用してwhitelist許可されたリクエストパスとメソッドを許可します。
言い換えると、コードとセキュリティチェックを変更せずにDELETEまたはPOSTメソッドを使用してレコードを削除できるという点で、セキュリティの観点から何か違いがありますか？
完全な質問
私たちの顧客は、企業標準に従って、Tomcatインスタンスを次のように構成しました。
<security-constraint>
<web-resource-collection>
<web-resource-name>restricted methods</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>CONNECT</http-method>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
<auth-constraint />
</security-constraint>
これは、Http Header Security Filter設定により、アプリケーションが壊れました。
このアプリケーションは、Spring Securityで同じ HTTPヘッダーセキュリティ 機能を提供します。また、アプリケーションはRESTfulであるため、ファイルのアップロードにPUTおよびDELETEメソッドを広く使用しています。今後のリリースでは、websocketの使用も計画しています（ただし、検索からは、プロキシ用のCONNECTは使用されません）。
私たちの顧客は、Tomcat構成から問題のある行を削除してアプリケーションを機能させるために、本番環境でポリシー例外を発生させる必要があると述べました。
セキュリティ例外ポリシーは、ベンダーアプリケーションが1）スケジュール内で問題を修正できない、2）明らかな脆弱性が見つからないという方法でセキュリティ要件に準拠していない場合にトリガーされます。例外ポリシーには、上級管理者の承認が必要です。
ただし、セキュリティポリシーの例外により、お客様は6か月以内にベンダーに「セキュリティ問題の修正」に関与する必要があります。 6か月以内に、ベンダーはセキュリティポリシーを満たすためのコストと期限を提供する必要があります。
これは、有効なHTTPメソッドフィルタリングとHTTPヘッダーセキュリティフィルターを使用してアプリケーションを機能させるための見積もりを要求するところに戻ることを意味します。
私はそれらをやりたくありません、すべてのAjax呼び出しをRESTfulパターンからGET/POSTのみに変更します。可能であればお金もかかりません。代わりに、アプリケーション内のセキュリティ実装に関して、それらのセキュリティ実装が互換性がないだけでなく冗長であることを証明したいと思います。
この顧客にPUTおよびDELETE要求を支持する先例を作った場合、大規模な顧客ベース（すべての銀行および金融機関）からの「私のフレームワーク/ポリシー/環境と互換性がある」などの要求に直面する必要があります。将来的には、それが当社のコスト管理に反するかもしれません。
問題は、TLDRと同様に、アプリケーションのセキュリティ機能に関係なく、PUTメソッドとDELETEメソッドだけを使用すると、セキュリティリスクが発生する可能性があるかどうかです。
唯一のHTTP動詞がセキュリティリスクをもたらさないことが証明された場合、私は永続的な例外ポリシーを提起し、確固たる議論をもってITスタッフに対抗することができます。
編集する
私は、同じ製品インスタンスを多数の顧客と私たちのクラウドに展開するソフトウェアファクトリで働いています。 RESTパターンを含む、搭載されているすべてのツールを完全に使用しています。HATEOAS、WebSocket、再開可能なファイルのダウンロード、およびWebテクノロジーが提供するすべての機能を使用して、より良い配信を提供することを計画しています。経験です。はい、マーケティングラインのように聞こえます。
これは、誰かが理解していない「ベストプラクティス」を熱心に適用しているケースだと思います。
HTTP動詞改ざん攻撃
このベストプラクティスが存在する理由は、HTTP動詞改ざん攻撃が原因です。 この記事 から：
多くのWebサーバー認証メカニズムは、動詞ベースの認証とアクセス制御を使用します。たとえば、管理者は、HTTP GETリクエストを使用してWebページへの無制限のアクセスを許可し、POSTを管理者のみに制限するようにWebサーバーを構成できます。ただし、動詞ベースのセキュリティメカニズムの多くの実装では、セキュリティで保護されていない方法でセキュリティルールが適用され、代替のHTTPメソッド（HEADなど）または任意の文字列を使用して制限されたリソースにアクセスできます。
つまり、一部のアプリは不適切に記述されているため、すべてのアプリはGETまたはPOST以外のHTTP動詞の受け入れを禁止する必要があると誰かが判断しました。
私の意見（おそらく不完全/不正確、コメントを投稿してください）：
- 純粋なHTML/CSS/jsコンテンツはGETとPOSTであるため、これらは HTML仕様で許可される唯一の動詞 であるため）に制限する必要があります。
- API（AJAX、REST）の使用を許可する必要があります HTTP仕様の動詞 、と述べています：
- アプリケーションレイヤーが動詞ベースのアクセス制御を正しく実施している場合でも、ウェブサーバーのフロントエンドは実施していない可能性があるため、セキュリティテストを実施し、アプリで適切な認証とアクセス制御を実施する必要があることに注意してくださいallサポートする動詞。以下をお勧めします OWASPテストガイド 。
アプリは問題なく、顧客は過度のセキュリティポリシーを持っているようです。
余談ですが、HEADは興味深い例です。一部のセキュリティスキャナーは、アプリがHEADリクエストに応答すると応答しません。適切な認証チェックを呼び出します。ただし、適切に設計されたほとんどのアプリは完全なGETを処理し、正しいcontent-length:を含むヘッダーのみを返します。したがって、最新のフレームワークを使用するアプリの場合、認証ロジックをバイパスする方法はおそらくありませんGETコントローラーです。簡単なテストをいくつか行ってください！（コメントで指摘してくれた@usr-local-ΕΨΗΕΛΩΝに感謝します。方法の詳細は このスタックオーバーフローの投稿 を参照してくださいSpring MVCがこれを処理します。）
間違いなく、DELETEおよびPUTは、CSRF攻撃で使用できないため、GET/POSTよりも安全です。また、間違いなく、DELETEとPUTは、とにかくCSRFから保護する必要があります。これは、アプリケーションのセキュリティを、そこにあるすべてのブラウザーの実装が標準に従っているという前提に基づくのは悪いことです。しかし、アプリケーションがそのような保護機能を備えていないことは珍しくありません。そのため、私は少しここに到達していますが、それが禁止の背後にある考えです。
または、必要のないすべてのメソッドを無効にして（これは良い方法です）、時間の経過とともにデフォルトから違反のないルールに変わったのかもしれません。
リモートAPIはこのように設計されている場合があるため、GETまたはPOST以外のhttpメソッドは使用されません。たとえば、次のようになります。
DELETE /item/123
多分：
GET /delete/item/123
とにかく、API仕様を読んで、アイテムを追加または削除する方法を理解する必要があるため、50/50の引数が1つが他よりも優れています。私はGETとPOSTだけが好きです。
[〜＃〜] owasp [〜＃〜] 質問で説明されている方法で未使用のルートをロックすることをお勧めします。
HTTPメソッドを制限する
- 許可されたHTTPメソッドのホワイトリストを適用します。 GET、POST、PUT。
- ホワイトリストとHTTP応答コード405が一致しないすべての要求を拒否します。
- 呼び出し元が、リソースのコレクション、アクション、およびレコードで着信HTTPメソッドを使用する権限を持っていることを確認してください
来たるべき議論のビジネス面に焦点を当てる人がいるように、すぐに会社の法務チームに連絡することをお勧めします。
セキュリティ例外ポリシーの一環として、お客様のスタッフは6か月以内にベンダーに「セキュリティ問題の修正」に従事する義務があります。
つまり、有効なHTTPメソッドフィルタリングとHTTPヘッダーセキュリティフィルターを使用してアプリケーションを動作させるように依頼することになります。
私は彼らに賛成して、すべてのAjax呼び出しをRESTfulパターンからGET/POSTのみに変更したくありません。
あなたのクライアントは明らかに独自の官僚機構を運営しており、柔軟性のないポリシーを実施しています。あなたはあなたが3つの可能な道を持っていると信じています：
- ポリシーを変更するように説得します。
- 望ましくない変更を加えます。
- 顧客としてそれらを失うリスクがあります。
あなたには論理的で技術的な決定であるように見えますが、ポリシーを変更するにはかなりの政治的争議が必要です。ディスカッションの反対側であなたが対応している人は、そのような要求を成功させるために必要な彼の会社での地位を持っている場合と持っていない場合があります。彼は変化のために彼自身の官僚と戦う彼の時間を無駄にしたくないかもしれません。ベンダーを変更し、すでにポリシーに準拠している他の誰かの製品を使用すれば、彼の人生はかなり楽になるかもしれません。さらに悪いことに、ベンダーを変更するだけで上司の生活はほぼ確実に楽になります。
他の結果について真剣な計画を立てることなく、彼らに方針を変更させることに成功できると考えるのは無責任でしょう。
良い顧客は来るのが難しいほどです。あなたはあなたの会社にこれを失うことのリスクを慎重に比較検討する義務があります。