web-dev-qa-db-ja.com

HTTPメソッドの活用方法

nikto 、 nessus 、 nmap 、および w3af などの多くのセキュリティスキャナーでは、HEAD、GETなどの特定のHTTPメソッドが表示されることがあります、POST、PUT、DELETE、TRACE、OPTIONS、CONNECTなどが攻撃に対して脆弱です。

これらのヘッダーは何をするもので、どのように悪用されるのですか？

POSTまたはGETインジェクション（例：変更されたフィールド）などの一般的なエクスプロイトよりもクリエイティブなものを探しています。これにより、通常の使用法の簡単な例が返されたかどうかがわかります。ヘッダーの悪用手法と比較したヘッダー。

web-applicationappsecattackshttp
58
Digital fire

これらの方法には、通常、公開するのが危険なものもあれば、本番環境では無関係であり、追加の攻撃対象と見なされるものもあります。それでも、おそらくそれらを必要としないので、それらも遮断する価値があります。

  • HEAD、GET、POST、CONNECT-これらは、少なくともHTTPメソッド自体に関しては、完全に安全です。もちろん、リクエスト自体に悪意のあるパラメータが含まれている可能性がありますが、それはメソッドとは別のものです...これらは通常（以下の例外に注意）有効にする必要がある唯一のものです。

  • PUT、DELETE-@Justinが述べたように、これらのメソッドは元々ファイル管理操作として意図されていました。
    一部のWebサーバーは、これらを元の形式でサポートしています。つまり、サーバーのファイルシステムから任意にファイルを変更または削除できます。明らかに、これらが有効になっている場合は、いくつかの危険な攻撃が発生します。
    これらのメソッドを絶対に有効にする必要がある場合は、ファイルアクセス許可をvery厳しく制限する必要があります。しかし、とにかく、この機能を必要に応じてサポートするために、この機能をサポートするために使用できる単純なスクリプトがあります（これが静的Webサイトの場合-実際のアプリケーションの場合は、自分でコーディングしてください）。
    注：これらのメソッド（PUTおよびDELETE）を有効にする1つの有効なシナリオは、厳密に RESTful APIまたはサービスを開発している場合です。ただし、この場合、メソッドはWebサーバーではなくアプリケーションコードによって処理されます。

  • オプション-これは診断メソッドであり、主にデバッグなどに役立つメッセージを返します。このメッセージは基本的に、驚くべきことに、どのHTTPメソッドがWebサーバー上でアクティブであるかを報告します。実際には、これが現在正当な目的で使用されることはほとんどありませんが、潜在的な攻撃者に少しの少しの助けを与えます：別の穴を見つけるためのショートカットと考えることができます。
    現在、これ自体は実際には脆弱性ではありません。ただし、実際には使用されないため、攻撃対象領域に影響するだけであり、理想的には無効にする必要があります。
    注：上記にもかかわらず、OPTIONSメソッドISいくつかの正当な目的で最近使用されています。たとえば、一部のREST APIにはOPTIONSリクエストが必要です。CORSしたがって、プリフライトリクエストなどが必要になります。そのため、OPTIONSを有効にする必要があるシナリオがありますが、デフォルトは「必要な場合を除いて」無効にする必要があります。

  • TRACE-これ​​は驚くべきものです...繰り返しになりますが、診断メソッド（@Jeffが言及したもの）は、HTTPリクエスト全体を応答本文で返します。これには、リクエストの本文だけでなく、リクエストヘッダーも含まれます。 Cookie、認証ヘッダーなど。
    それほど驚くべきことではありません。これは、古典的な Cross-Site Tracing（XST） 攻撃など、実質的に誤用される可能性があり、XSSベクトルを使用してHttpOnly Cookie、認証ヘッダー、など。これは必ず無効にする必要があります。

  • もう1つのメソッドセットは、その他すべてについて言及しています。一部のウェブサーバーでは、特定のHTTPメソッドを有効化/無効化/制限するために、構成ファイルでそれらを何らかの方法で明示的に設定します。ただし、デフォルトが設定されていない場合、追加のメソッドを「挿入」して、Webサーバーが実装した可能性のある特定のアクセス制御をバイパスすることが可能です（不十分）。たとえば OWASPの詳細 を参照してください。

46
AviD

PUTメソッドを使用すると、サーバーに任意のファイルをアップロードできます。これは、クロスサイトスクリプティング（XSS）の実行に使用できます。今日、私はこの攻撃を実行したので、ここで私の経験を返信します。これを行う方法を以下に説明します。

PUT /XSS.html HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.myblog.com
Accept-Language: en-us
Connection: Keep-Alive
Content-type: text/html
Content-Length: 182
(Input your XSS script here)

サーバーは、「ファイルが正常に作成されました」という201ステータスコードで応答します。

HTTP/1.1 201 Created
Date: Mon, 05 May 2014 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

これで、このアップロードされたXSS.htmlファイルにブラウザーでアクセスできるようになりました。このページにアクセスするとすぐに、XSSポップアップが表示されます。

同様に、これはコマンドインジェクションを実行するためにさらに悪用される可能性がありますが、まだ試していません。アプリケーションがXMLを使用している場合、XML外部エンティティ攻撃も実行できます。これもまだやっていません。ディレクトリトラバーサル攻撃も可能性があります。

4
Dan Rad

TRACEに関する主な警告は、tracerouteがパケットのルーティングを分離する方法と同様に、HTTPリクエストのルーティングを分離するように設計されていることです。主な違いは、TRACEコマンドにはバックエンドでの操作と受信したものの開示が含まれることです。フロントエンドがAPIキーまたはバックエンドと同様のものを提供する場合、これは問題になる可能性があります。

TRACEの詳細や他のヘッダーの説明については、 RFC 2616 を確認してください。

3
Jeff Ferland