インジェクション攻撃 - ログインジェクション

ログ インジェクション (ログ ファイル インジェクションとも呼ばれます)

多くのアプリケーションは、許可されたユーザー向けに HTML インターフェイスを介して表示される一連のログを維持するため、他の攻撃を偽装しようとする攻撃者の主なターゲットになったり、ログ リーダーを誤解させたり、さらにはログ監視アプリケーションを読み取って分析するユーザーに後続の攻撃プログラムをインストールします。

ログの脆弱性は、ログ書き込みプロセスの制御と、ログ エントリの監視または分析においてログ データが信頼できないデータ ソースとして扱われるようにするかどうかに依存します。

単純なログ システムでは、ファイル putcontents() 関数を使用してテキスト行をファイルに書き込むことがあります。たとえば、プログラマはログインの失敗を記録するために次の形式の文字列を使用することがあります:

sprintf("Failed login attempt by %s", $username);  

それでは、攻撃者が「AdminnSuccessful login by Adminn」の形式のユーザー名を使用した場合はどうなるでしょうか?

信頼できない入力からのこの文字列がログに挿入されると、攻撃者は失敗したログインを管理者ユーザーの無害な失敗したログインとして偽装することができます。成功した再試行をさらに追加すると、データの信頼性がさらに高まります。

もちろん、重要なのは、攻撃者がさまざまなログ エントリを追加したり、XSS ベクトルを挿入したり、さらには文字を挿入して、コンソール上のログ エントリの表示を妨害したりできるということです。

ログインジェクションの目的

インジェクションのターゲットは、ログ形式インタープリターである場合もあります。パーサー ツールが正規表現を使用してログ エントリをデータ フィールドに解析する場合、正規表現が正しいフィールドではなく、挿入された冗長フィールドと一致することを確認するために、挿入された文字列を慎重に構築できます。たとえば、次のエントリは問題を引き起こす可能性があります:

$username = "iamnothacker! at Mon Jan 01 00:00:00 +1000 2009"; sprintf("Failed login attempt by $s at $s", $username, )

ログ インジェクションを使用するさらに悪質な攻撃者は、ブラウザにログを表示させるディレクトリ トラバーサル攻撃をセットアップしようとする可能性があります。通常の状況では、PHP コードをログ メッセージに挿入し、ブラウザでログ ファイルを開くことで、コード インジェクションを正常に実行できます。攻撃者は、そのようなコード インジェクションを慎重に設計し、自由に実行できます。これについてはこれ以上詳しく説明する必要はありません。攻撃者がサーバー上で PHP を実行できる場合、それは大きな問題になります。現時点では、被害を最小限に抑えるためにシステムに十分な多層防御が必要です。

ログ インジェクションの防御

ログ インジェクションを防御する最も簡単な方法は、承認された文字のホワイトリストを使用して、すべての送信ログ メッセージをサニタイズすることです。たとえば、すべてのログを英数字とスペースに制限できます。この文字リストに当てはまらないメッセージは有害であると見なされ、潜在的なローカル インクルージョン脆弱性 (LFI) に関するログ メッセージが、攻撃者による試みの可能性を通知するように表示される場合があります。このアプローチはシンプルであり、信頼できない入力が避けられない単純なテキスト ログに適しています。

2 番目の防御策は、信頼できない入力部分を Base64 のようなエンコードにエンコードすることです。これにより、限られた数の認識された文字の説明が保存され、テキスト内に大量の情報も保存できます。

パス トラバーサル (ディレクトリ トラバーサルとも呼ばれます)

パス トラバーサル (ディレクトリ トラバーサルとも呼ばれます) 攻撃は、バックエンド操作を制御できるファイルを挿入することにより、Web アプリケーション内のファイルの読み取りまたは書き込みによってバックエンド操作に影響を与えようとします。 。したがって、情報開示とローカル/リモート ファイル インジェクションを促進することで、この種の攻撃は成功する可能性があります。

これらの後続の攻撃については個別に説明しますが、パス トラバーサルは、これらの攻撃を可能にする基本的な脆弱性の 1 つです。次の関数はファイル パスの操作の概念に特有のものですが、多くの PHP 関数は単なるファイル パス以上のものを受け入れることに注意してください。たとえば、PHP の include() や file() などの関数は URI を受け入れることができます。これは直感に反するように思えるかもしれませんが、絶対ファイル パスを使用して関数を呼び出す次の 2 つの方法 (つまり、相対ファイル パスに依存しない自動ロード) が同じ効果を持つようになります。

うわー

重要な点は、関連するパス処理 (php.ini と利用可能なオートローダーの include_path 設定) である一方で、同様の PHP 関数は、ファイル URI スキームの置換を含むさまざまな形式のパラメータ操作に対して特に脆弱であるということです。ファイル パスの先頭に挿入されると、攻撃者は HTTP または FTP URI を挿入できます。この点については、後ほどリモート ファイル インクルージョン攻撃でさらに詳しく説明し、ファイル システム パス トラバーサルの問題について引き続き調査します。

パス トラバーサルの欠陥のさまざまなケースには、ファイル パスが別のファイルを指すように操作されるという 1 つの共通の特徴があります。これは通常、一連の ../ (ドット-ドット-スラッシュ) シーケンスをパラメーターに挿入することによって実現されます。これらのシーケンスは、 include()、require()、file_get_contents() などの関数に完全に追加または挿入され、さらにはDOMDocument::load() など、人間にとってそれほど疑わしくない関数内。

ドット、ドット、スラッシュのシーケンスにより、攻撃者はシステムを親ディレクトリに移動またはバックトラックさせることができます。したがって、/var/www/public/../vendor のようなパスは、実際には /var/www/public/vendor を指します。 /public の後のドット、ドット、スラッシュのシーケンスは、ディレクトリの親ディレクトリ (/var/www) まで遡ります。この簡単な例からわかるように、この方法では、攻撃者が Web サイト サーバー経由でアクセスできる /public ディレクトリの外にあるファイルを読み取ることができます。

もちろん、パストラバーサルは後戻りのためだけではありません。攻撃者は、サブディレクトリまたはその親ディレクトリの 1 つ内の .htaccess 内のすべてのディレクティブが拒否されたことが原因で、ブラウザからアクセスできないサブディレクトリにアクセスするために新しいパス要素を挿入することもできます。 PHP のファイル システム操作では、Apache またはその他の Web サーバーが非公開のファイルやディレクトリへのアクセスを構成および制御する方法は考慮されません。

パストラバーサルの例

防御パストラバーサルの推定

元のアドレス: [Injection Attacks](http://phpsecurity.readthedocs.org/en/latest/Injection- Attacks.html#log-injection-only-log-file) -injection )

この記事は OneAPM エンジニアによって編集および編集されました。 OneAPM は、アプリケーション パフォーマンス管理の新興リーダーであり、企業ユーザーや開発者が遅いプログラム コードや SQL ステートメントをリアルタイムでキャプチャできるように支援します。さらに技術的な記事を読むには、OneAPM 公式ブログにアクセスしてください。