HTTP運用のリスクは高まっているものの、管理可能

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

好むと好まざるとにかかわらず、HTTPは現代における事実上のアプリケーション転送プロトコルです。あらゆる場所で利用されており、IPやTCPと同じくらい広く普及し、ほぼ同じ役割を果たしています。その唯一の目的は、今日のビジネスにおけるデジタルの金ともいえる「データ」を転送することです。

そのデータがJSON、XML、URLエンコード形式のいずれであるかは問題ではありません。アプリやデバイスはHTTPを使用して、クラウド上のサーバーやサービス、およびデータセンター内のオンプレミス環境と通信します。

ただし、IPやTCPとは異なり、HTTPはテキストベースのプロトコルです。柔軟性が非常に高く、バイナリからテキストまで、さまざまなデータを転送できます。HTTPは、データのストリーミング、取得、収集に使用されます。

前述のとおり、HTTPはテキストベースのプロトコルであり、ヘッダーの拡張に関する規則が比較的緩いため、攻撃者に広く悪用されています。ヘッダーには、クライアントがサーバーに求める処理（HTTPの「メソッド」）、要求するリソース（URI）、受け入れ可能なコンテンツの種類（「Accept」ヘッダー）など、さまざまな情報が指定されます。こうした規則が緩いのは、拡張性を確保するためです。

たとえば、X-Forwarded-Forヘッダーは、開発者が元のクライアントIPアドレスを確実に「確認」できるようにするために導入されました。特定のアーキテクチャ、特に中間システムがフルプロキシとして機能する場合、この情報が失われることがあります。一部のアプリケーションではこのデータが必要なため、開発者（およびネットワークベンダー）はカスタムヘッダーを導入してHTTPプロトコルを拡張しました。これはHTTP仕様の一部であり、プロトコルを変更することなく、イノベーションや新たな動作、機能の導入を可能にします。これは有益な仕組みです。

ただし、そうでない場合もあります。

HTTPをサポートするサーバーの開発者や、HTTPに依存するアプリケーションのセキュリティを担当する人が、この柔軟性を考慮しない場合、問題が生じます。

HTTPヘッダーの脆弱性を悪用する、HTTP関連のCVEの一例を以下に示します。

率直に言うと、既知のCVEからHTTPの脆弱性を検索すると、さまざまなベンダーやソフトウェアにまたがる非常に長い一覧が返されるため、ここでは転載しません。そのうちのかなりの割合は、一般にHTTPヘッダーの悪用によって引き起こされます。

Optionsbleedに関する注意事項

Optionsbleedは、比較的新しい脆弱性の1つです。ここで取り上げるのは、Apache HTTP自体に存在する脆弱性だからです。Netcraftは現在、「さまざまなバージョンや派生版のApache httpdが、インターネットに公開されている280万台以上のコンピューターで稼働しており、その42.8%を占めている」と推定しています。そのため、Apache httpdの脆弱性は重大なリスクとなります。幸い、この脆弱性はHTTPヘッダーを介して引き起こされますが、Limitsディレクティブが.htaccessファイル内で誤って設定されていることも条件となります。詳細な技術情報に関心がある場合は、Sophosのこちらの記事で概要をご確認いただけます。要するに、この設定ミスが存在すると、攻撃者はHTTPメソッドヘッダーを介してApacheの脆弱性を悪用し、サーバーから第三者のデータを「流出」させることができるようです。

さて、ここまでの話は、次のことをお伝えするためです。アプリケーションセキュリティは、複数の層で構成されます。その層には、アプリケーションが依存するプラットフォーム（したがってプロトコルも）が含まれます。HTTPもその1つです。

セキュリティ侵害を目的としたHTTPの悪用を、これまで以上に防ぐ必要があります。データ漏えい、DoS、リモートアクセスのいずれであるかは問題ではありません。どれも深刻な影響をもたらします。HTTPが攻撃対象としてますます狙われていることを、より明確に認識する必要があります。HTTPはテキストベースであるため、クライアントとHTTPサービス間のやり取り全体を「ユーザー入力」として分類する必要があります。

その認識は、入力のサニタイズを含むセキュリティ戦略の採用につながるはずです。つまり、潜在的に脆弱なHTTPサーバーに到達する前の上流で、プロトコルを適用し、不正なデータを除去するということです。

つまり、一般公開されているHTTPサービスの前段に、Webアプリケーションファイアウォールまたはプログラム可能なプロキシを配置し、受信するHTTPリクエストを能動的に無害化する必要があります。

その理由は、WebプラットフォームがHTTPヘッダーを処理する仕組みにあります。つまり、リクエストが開発者の目に触れる前に処理されるためです。したがって、プラットフォームレベルの脆弱性について、必ずしも開発者の安全でないコーディング手法に原因があるとは言えません。

もちろん、パッチの適用が最終的な解決策です。ただし、（1）脆弱性が発見された当日にその情報を入手し、（2）同日中にパッチが提供され、（3）十分にテストされていない可能性のあるパッチを本番システムに適用することに抵抗がない場合に限ります。

誤解のないように言えば、パッチの適用は必要です。しかし、脆弱性の開示、発見、パッチの提供、適用までには時間差があります。その間には、極めて容易に悪用できる脆弱性を攻撃に利用されるリスクが存在します。

次善の策は、スクリプトやシグネチャベースのスキャンなど、即時に適用できる修復策を展開して脆弱性の悪用を防止できるシステム（プラットフォーム）を用意しておくことです。これにより、パッチ適用の準備中も対策できます。

受信データのスクラビングとプロトコルの正当性の適用は、あらゆる企業のセキュリティポリシーに不可欠です。

HTTPのリスクは高まっていますが、アプリケーションセキュリティが複数のレイヤーで構成されていることを念頭に置き、各レイヤーに保護対策を講じれば、リスクを管理できます。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事