インジェクション攻撃 - ログインジェクション-PHPチュートリアル-php.cn

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

WBOY

リリース： 2016-06-23 13:14:33

オリジナル

939 人が閲覧しました

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

多くのアプリケーションは、許可されたユーザー向けに 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 公式ブログにアクセスしてください。