Web14: HTTP プロトコルのセキュリティ問題

この記事では、RFC 7230 と RFC 7231 の 2 つの文書で提起さ​​れているHTTP プロトコルのセキュリティ問題をいくつか紹介します。記事内の特定のエラーに関する例は OWASP から参照されています。

1. 中間要因によるリスク

HTTP を使用すると、仲介者を使用して、一連の接続を通じてリクエストに応答できます。一般的な中間要素として、プロキシ、ゲートウェイ、トンネルの 3 つがあります。

リクエストまたはレスポンスはポイント A、B、C を通過する必要があります。ユーザーや組織の個人情報など、送信されている機密情報にアクセスする可能性があります。仲介者がセキュリティとプライバシーに注意を払わないと、さまざまな潜在的な攻撃につながる可��性があります。

システム開発者および開発者は、システムの設計、コーディング、展開のプロセス中にプライバシーとセキュリティ要素を考慮する必要があります。

ユーザーは、信頼できないプロキシまたはゲートウェイを使用する危険性を認識する必要があります。

2. 応答の分割

応答分割 (別名 CRLF インジェクション) は、Web エクスプロイト手法としてよく使われています。攻撃者は、一部のリクエスト パラメータでエンコードされたデータを送信します。その後、そのデータがデコードされ、応答ヘッダーの特定のフィールドで繰り返されます。

このデータが応答の終了を表す記号であり、次の応答が開始されると、元の応答が 2 つに分割され、2 番目の応答の内容が攻撃者によって制御されてしまいます。次に、攻撃者は同じ永続接続内で別のリクエストを作成し、受信者 (仲介者を含む) を騙して、この 2 番目の応答が 2 番目のリクエストに対する応答であると信じ込ませることができます。

3. 密輸の要請

リクエストの密輸は、さまざまな種類のサーバーによるリクエストの処理の違いを利用して、元のリクエストに追加された一見無害なリクエストを隠す手法です。

次の例を考えてみましょう。

POST リクエストのヘッダーに 2 つの異なる値を持つ 2 つの「Content-length」フィールドが含まれているとします。一部のサーバー (IIS および Apache) はこの要求を拒否しますが、その他のサーバーは拒否しません。たとえば、SunONE W/S 6.1 は最初に Content-length フィールドを使用し、sunONE Proxy 3.6 は 2 番目に Content-length フィールドを使用します。

SITE が SunONE プロキシの背後にある SunONE W/S の DNS であると仮定すると、SunONE W/S 上に Poison.html ファイルが存在します。 2 つのサーバー間の処理の不一致に基づいて HTTP リクエスト サグリングを悪用する方法は次のとおりです。

[10 行目を除き、各行は CRLF ("") で終わることに注意してください]

Proxy サーバー経由で W/S にリクエストが送信された場合に何が起こるかを考えてみましょう。まず、プロキシは 1 行目から 7 行目 (青) までのリクエストを分析し、2 つの Content-Length フィールドを検出します。前述したように、最初のフィールドは無視され、リクエスト本文の長さが 44 バイトであることが認識されます。したがって、8 行目から 10 行目のデータが最初のリクエストボディとして扱われます (8 行目から 10 行目のデータの長さはちょうど 44 バイトです)。次に、プロキシはクライアントの 2 番目のリクエストとして 11 行目から 14 行目 (赤色) を分析します。

次に、プロキシから転送された上記のデータを W/S がどのように解釈するかを見てみましょう。プロキシとは異なり、W/S は最初の Content-Length フィールドを使用し、次のように解釈します。最初のリクエストには本文がなく、2 番目のリクエストは 8 行目から始まります (W/S は 11 行目以降を値として解析することに注意してください) Blaフィールドの）。

次に、応答がどのようにクライアントに返されるかを見てみましょう。 W/S が理解するリクエストは「POST /foobar.html」（1 行目から）と「GET /poison.html」（8 行目から）なので、foobar ページのコンテンツを含む応答をクライアント 2 に送信します。 htmlとpoison.html。プロキシは、これら 2 つの応答が 2 つのリクエスト、「POST /foobar.html」(1 行目) と「GET /page_to_poison.html」(11 行目) に対応していることを理解します。プロキシは、URL「page_to_poison.html」に対応するpoison.htmlページのコンテンツをキャッシュします（キャッシュポイズニング）。そこから、クライアントが「page_to_poison.html」をリクエストすると、poison.html ページのコンテンツを受け取ります。

4. ファイルパスに基づく攻撃

Web サーバーは、ローカル ファイル システムを頻繁に使用して、URI 内のファイル名のサーバー上の実際のリソースへのマッピングを管理します。ほとんどのファイル システムは、悪意のあるファイル パスから保護するように設計されていません。したがって、サーバーは重要なシステム ファイルへのアクセスを回避する必要があります。

たとえば、UNIX、Microsoft Windows、およびその他のいくつかのオペレーティング システムでは、現在のファイル/ディレクトリの 1 つ上のレベルのディレクトリを表すパス要素として「..」を使用します。適切な入力制御と認証がなければ、システムの機密ファイル/フォルダーを指すパスを入力することによって、これらのファイル/フォルダーにアクセスできます。

5. 攻撃の種類: コマンドインジェクション、コードインジェクション、クエリインジェクション

[Web サーバーは、システム コマンドやデータベース クエリを実行するための入力として URI のパラメーターを使用することがよくあります。ただし、リクエストで受信したデータが常に信頼できるとは限りません。攻撃者は、リクエスト内のコンポーネント (メソッド、ヘッダーのフィールド、本文など) を作成および変更し、システム コマンドを実行したり、データベースにクエリを実行したりすることができます。

たとえば、SQL インジェクションは、Web サーバーが SQL クエリの一部である URI 内のパラメータを受け取る一般的な攻撃です。したがって、攻撃者は、データベースを盗んだり破壊したりするために、Web サーバーをだまして違法な SQL クエリを実行させる可能性があります。
一般に、ユーザーが送信したデータは、サーバー上で操作を実行するために直接使用されるべきではありません。これらのデータは、何が有効で何が無効かを定義するフィルターを通過する必要があり、それによって不要なデータが排除されます。

6.個人情報の開示

クライアントには、サーバーと対話するためにユーザーが提供した情報 (ユーザー名、パスワード、場所、電子メール アドレスなど) やユーザーの Web 閲覧アクティビティに関する情報 (履歴、ブックマーク、等。）。導入する際には、この個人情報が漏洩する可能性のある点を防ぐことに注意する必要があります。

7. URI 内の機密情報の公開

URI は設計上、すべてのユーザーと共有されることを目的としており、安全性は保証されていません。 URI は Web サイトのソース コードに表示されることが多く、保護メカニズムなしでブックマークに保存されます。したがって、URI に機密情報や個人情報などが含まれている場合は安全ではありません。

個人情報は URI に表示されるため、GET メソッドを使用してサーバーに個人情報を送信することは避けてください。代わりに POST メソッドを使用してください。

8. 使用されているソフトウェア情報の公開

通常、ヘッダーの User-Agent、Via、Server フィールドは、送信者が使用するソフトウェアに関する情報を提供します。理論的には、これにより攻撃者はこれらのソフトウェアの既知の脆弱性をより簡単に悪用できるようになります。