HTTP を実行するリスクは増大しているが、管理可能

好むと好まざるとにかかわらず、HTTP は現代の事実上のapplication転送プロトコルです。 どこでも使います。 これは IP や TCP と同じくらい普及しており、ほぼ同じ目的を果たします。 その唯一の目的は、今日のビジネスのデジタルゴールドであるデータを輸送することです。

そのデータが JSON であるか、XML であるか、URL エンコードされているかは関係ありません。 アプリやデバイスがクラウドやデータセンターのオンプレミスのサーバーやサービスと通信するために使用するのはこの HTTP です。

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

攻撃者がこれを自由に使用するのは、前述のように、HTTP はテキストベースのプロトコルであり、クライアントがサーバーに期待するアクション (HTTP メソッド) から要求されるリソース (URI)、受け入れ可能なコンテンツの種類 (Accept ヘッダー) まですべてを指定するヘッダーの拡張に関するルールがかなり緩いためです。 これらのルールは拡張性を可能にするために緩くなっています。

たとえば、 X-Forwarded-For ヘッダーは、開発者が元のクライアント IP アドレスを「確認」できるようにするための手段として導入されました。 特定のアーキテクチャ、特に仲介者が完全なプロキシとして機能するアーキテクチャでは、この情報が失われる可能性があります。 一部のapplicationsではそのデータが必要なため、開発者 (およびネットワーク ベンダー) はカスタム ヘッダーを導入して HTTP プロトコルを拡張しました。 これは HTTP 仕様の一部であり、プロトコルを変更することなく革新と新しい動作および機能の導入を可能にします。 それは良いことだ。

そうでない時は除きます。

HTTP をサポートするサーバーの開発者や、HTTP に依存するapplicationsのセキュリティ保護の責任者がこの柔軟性を考慮していないのは、良いことではありません。

以下は、HTTP ヘッダーの脆弱性を悪用する HTTP 関連の CVE の一部です。

正直なところ、HTTP の脆弱性に関する既知の CVE を検索すると、非常に長いリスト (さまざまなベンダーとソフトウェアが含まれます) が返されますが、ここではそれを再現するつもりはありません。 これらの大部分は、通常、HTTP ヘッダーの悪用によってトリガーされます。

オプションブリードに関する注意事項 

Optionsbleed は最も最近の脆弱性の 1 つです。 Apache HTTP 自体に存在するため、これを呼び出します。 Netcraft の現在の推定によると、Apache は「現在 280 万台以上の Web 対応コンピュータでApache httpdのさまざまなバージョンや派生版が実行されており、Web 対応コンピュータ全体の 42.8% を占めている」ため、Apache の脆弱性は重大なリスクとなります。 幸いなことに、この特定の脆弱性は HTTP ヘッダーを介してトリガーされますが、.htaccessファイル内に誤って構成されたLimitsディレクティブが存在する必要もあります。 ご興味があれば、 Sophos のこの投稿で、詳細な技術的詳細の概要をご覧いただけます。 要約すると、誤った設定が存在する場合、攻撃者は HTTP メソッド ヘッダーを介して Apache の脆弱性を悪用し、(どうやら) サーバーから他の誰かに属するデータを「流出」させる可能性があります。

さて、ここまで述べてきたことから、私はこう言えます。アプリのセキュリティはスタックです。 そのスタックには、applicationsが依存するプラットフォーム (およびプロトコル) が含まれます。 HTTPのように。

HTTP が悪用されてセキュリティが侵害されるのを防ぐために、より一層の対策を講じる必要があります。 それがデータ漏洩なのか、DoS なのか、リモート アクセスのかは重要ではありません。 それらはすべて悪い影響です。 HTTP がますます一般的な攻撃対象になっていることをもっとよく認識する必要があります。 テキストベースであるということは、クライアントと HTTP サービス間のやり取り全体をユーザー入力として分類する必要があることを意味します。

それは、サニタイズを含むセキュリティ戦略を促進することになるだろう。 その入力の。 はい、それはプロトコルの強制と上流のスクラブ（潜在的に脆弱な HTTP サーバーに到達する前）を意味します。

つまり、 Webapplicationファイアウォールまたはプログラム可能なプロキシは、公開されている HTTP サービスの前に配置して、受信 HTTP 要求のスクラブを積極的に行う必要があります。

その理由は、Web プラットフォームが HTTP ヘッダーを処理する方法、つまり、開発者がリクエストを確認する前に処理される方法に基づいています。 したがって、プラットフォーム レベルの脆弱性について、必ずしも開発者を指摘し、安全でないコーディング手法を非難することはできません。

もちろん、パッチ適用が究極の解決策です。 (1) 脆弱性についてゼロの日に知り、(2) パッチがゼロの日に利用可能になり、(3) 潜在的にテストされていないパッチを本番システムに展開することに抵抗がないことを前提とします。

誤解しないでください。パッチを適用する必要がありますが、開示、検出、可用性、およびapplicationの間にはギャップがあります。 そのギャップにリスクが潜んでいます。非常に簡単に悪用できる脆弱性が悪用されるリスクです。

最後から 2 番目の解決策は、パッチの適用を準備する間に、スクリプトやシグネチャ ベースのスキャンなどの即時修復ソリューションを展開して悪用を防止できるシステム (プラットフォーム) を確実に導入することです。

受信データのスクラビングとプロトコルの正確性の強制は、あらゆる企業のセキュリティ ポリシーの不可欠な部分である必要があります。

HTTP はますますリスクが高まっていますが、アプリのセキュリティはスタックであることを覚えておき、そのスタックの各レイヤーに保護を導入すれば、管理も可能です。