PHP プログラムの一般的な脆弱性を攻撃する方法 (パート 1)_PHP チュートリアル-PHPチュートリアル-php.cn

原著者: Shaun Clowes 翻訳: Analysist この記事を翻訳した理由は、現在の CGI のセキュリティに関する記事はすべて Perl を例として使用しており、ASP、PHP、または JSP のセキュリティを具体的に紹介する記事が非常に少ないためです。 Shaun Clowes によるこの記事では、PHP のセキュリティ問題について包括的に紹介しています。元の記事は http://www.securereality.com.au/studyinscarlet.txt にあります。原文は比較的長く、記事の背景やPHPの基礎知識の紹介がかなりの部分を占めており、PHPのセキュリティについては触れていないため、翻訳は省略しました。これについて詳しく知りたい場合は、元の記事を参照してください。この記事では主に、グローバル変数、リモートファイル、ファイルアップロード、ライブラリファイル、セッションファイル、データ型、エラーが発生しやすい関数の側面から PHP のセキュリティを分析し、PHP のセキュリティを強化する方法についていくつかの有用な提案を提示しています。。さて、ナンセンスな話はこれくらいにして、本題に取り掛かりましょう! [グローバル変数] PHP の変数は、事前に宣言する必要はなく、初めて使用するときに自動的に作成され、コンテキストに基づいて自動的に決定されます。プログラマの観点から見ると、これは間違いなく非常に便利なアプローチです。明らかに、これは高速開発言語の非常に便利な機能でもあります。変数を作成したら、プログラム内のどこでも使用できます。この機能の結果、最初に作成された変数は空であるため、プログラマが変数を初期化することはほとんどありません。明らかに、PHP ベースのアプリケーションの main 関数は通常、ユーザー入力 (主にフォーム変数、アップロードされたファイル、Cookie など) を受け入れ、入力データを処理して、結果をクライアントブラウザーに返します。 PHP コードがユーザー入力にできるだけ簡単にアクセスできるようにするために、PHP は実際にこの入力データをグローバル変数として扱います。例: 明らかに、これによりテキストボックスと送信ボタンが表示されます。ユーザーが送信ボタンをクリックすると、「test.php」がユーザーの入力を処理します。「test.php」が実行されると、ユーザーがテキストボックスに入力したデータが「$hello」に含まれます。ここから、攻撃者が自分の希望に応じて任意のグローバル変数を作成できることがわかります。攻撃者がフォーム入力を通じて「test.php」を呼び出すのではなく、ブラウザのアドレスバーに http://server/test.php?hello=hi&setup=no を直接入力すると、「$hello」だけでなく、「$setup」も作成されます。翻訳者注: これら 2 つのメソッドは、通常「POST」メソッドと「GET」メソッドと呼ばれるものです。次のユーザー認証コードは、PHP のグローバル変数によって引き起こされるセキュリティ問題を明らかにします。上記のコードは、まずユーザーのパスワードが「hello」かどうかを確認し、一致する場合は「$auth」を「1」に設定します。つまり、認証は合格した。その後、「$suth」が「1」の場合、いくつかの重要な情報が表示されます。表面的には正しいように見えますし、多くの人がそうしていますが、このコードは、攻撃者のことを考慮せずに、値が設定されていない場合に "$auth" が空であると仮定するという間違いを犯しています。「http://server/test.php?auth=1」のようなメソッドを使用すると、このコードを完全に騙して認証済みであると信じ込ませることができます。したがって、PHP プログラムのセキュリティを向上させるために、明確に定義されていない変数は信頼できません。プログラム内に多くの変数がある場合、これは非常に困難な作業になる可能性があります。保護する一般的な方法は、送信方法 (GET または POST) に応じて、配列 HTTP_GET[] または POST_VARS[] 内の変数をチェックすることです。 PHP が「track_vars」オプション (デフォルト) をオンにするように構成されている場合、ユーザーが送信した変数はグローバル変数と上記の配列で使用できます。ただし、PHP にはユーザー入力を処理するための 4 つの異なる配列変数があることは言及する価値があります。 HTTP_GET_VARS 配列は GET モードで送信された変数の処理に使用され、HTTP_POST_VARS 配列は POST モードで送信された変数の処理に使用され、HTTP_COOKIE_VARS 配列は Cookie ヘッダーとして送信された変数の処理に使用され、HTTP_POST_FILES 配列 (比較的新しい PHP によって提供される) に使用されます。 )、これはユーザーが変数を送信するための完全にオプションの方法です。ユーザーリクエストは変数をこれら 4 つの配列に簡単に保存できるため、安全な PHP プログラムはこれら 4 つの配列をチェックする必要があります。【リモートファイル】 PHPは機能が豊富な言語であり、プログラマが特定の機能を簡単に実装できるように多数の関数が提供されています。しかし、セキュリティの観点から見ると、機能が増えれば増えるほど、その機能を安全に保つことが難しくなり、リモートファイルはこの問題の好例です:

"); ?> 上記のスクリプトは、ファイル "$filename" を開こうとしますが、失敗するとエラーメッセージが表示されます。明らかに、"$filename" を指定できれば、このスクリプトを使用してシステム内の任意のファイルを参照できます。ただし、このスクリプトのあまり目立たない特徴は、他の WEB サイトまたは FTP サイトからファイルを読み取ることができることです。実際、PHP のファイル処理関数のほとんどはリモートファイルに対して透過的です。たとえば、次のように指定します。 "http://target/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir" の場合、上記のコードは実際にホストターゲットの Unicode 脆弱性を悪用します。dir コマンドは次のとおりです。これにより、リモートファイルに対する include()、require()、include_once() および require_once() のサポートがより興味深いものになります。これらの関数の主な機能は、指定されたファイルの内容をインクルードし、それらに従うことです。コード解釈は主にライブラリファイルに使用されます。例: 上記の例では、通常、「$libdir」はコードを実行する前に設定されているパスです。攻撃者が「$libdir」を設定しないようにすることができます。このパスを変更することは可能ですが、攻撃者は指定したパス内のファイル language.php にのみアクセスできるため、何もできません (リモートのサポートがある場合、Perl の「Poison null byte」攻撃は PHP には影響しません)。たとえば、攻撃者は次の内容を含むファイル language.php をサーバーに配置し、「$libdir」を「http:///」に設定します。上記の攻撃コードがターゲットホスト上で実行されると、その結果、「/etc」ディレクトリの内容がクライアントのブラウザに返されます。攻撃サーバー (つまり、evilhost) は PHP を実行できないことに注意してください。そうしないと、攻撃コードはターゲットサーバーではなく攻撃サーバー上で実行されます。具体的な技術的な詳細については、http://www.securereality.com.au/sradv00006.txt を参照してください。 [アップロード] RFC 1867 ファイルアップロードに基づく PHP 自動サポート。次の例を見てみましょう。上記のコードでは、ユーザーがローカルマシンからファイルを選択できるようにします。送信をクリックすると、ファイルがサーバーにアップロードされます。明らかに非常に便利な関数ですが、PHP の応答方法により、この機能は安全ではなくなります。PHP は、呼び出された PHP コードの解析を開始する前であっても、最初にリモートユーザーからファイルを受け入れてチェックします。ファイルの長さが「$MAX_FILE_SIZE 変数」で定義された値を超えているかどうか、これらのテストに合格すると、ファイルはローカルの一時ディレクトリに保存されます。したがって、攻撃者は PHP を実行しているホストに任意のファイルを送信することができ、PHP プログラムがファイルのアップロードを受け入れるかどうかを決定する前に、ファイルはすでにサーバーに保存されています。ここでは、ファイルのアップロードを使用してサーバーに DOS 攻撃を実行する可能性については説明しません。ファイルのアップロードを処理する PHP プログラムを考えてみましょう。ファイルは受信され、サーバーに保存されます (場所は構成ファイルで指定されます (通常は /tmp))。拡張子は通常、「phpxXuoXG」のようなランダムです。 "形状。 PHP プログラムはファイルを処理するためにファイルの情報をアップロードする必要があります。これには 2 つの方法があります。1 つは PHP 3 ですでに使用されており、もう 1 つは以前の方法に関するセキュリティアドバイザリを作成した後に導入されました。ただし、問題は依然として存在しており、ほとんどの PHP プログラムはアップロードされたファイルを処理するために依然として古い方法を使用していると断言できます。 PHP は、上記の例のように、アップロードされたファイルを記述する 4 つのグローバル変数を設定します。 $hello = ローカルマシン上のファイル名 (例: "/tmp/phpxXuoXG") $hello_size = ファイルのバイト単位のサイズ (例: 1024) $hello_name = 元の名前リモートシステム上のファイルのタイプ (例: "c:temphello.txt") $hello_type = アップロードされたファイルの MIME タイプ (例: "text/plain") その後、PHP プログラムは "$hello" に従って指定されたファイルの処理を開始します。問題問題は、「$hello」が必ずしも PHP によって設定される変数ではなく、リモートユーザーなら誰でも指定できることです。次のメソッドを使用すると: http://vulnhost/vuln.php?hello=/etc/passwd&hello_size=10240&hello_type=text/plain&hello_name=hello.txt、結果は次の PHP グローバル変数になります (もちろん POST メソッドは(Cookie も)): $hello = "/etc/passwd" $hello_size = 10240 $hello_type = "text/plain" $hello_name = "hello.txt" 上記のフォームデータは、PHP プログラムが期待する変数をちょうど満たしています。 , しかし、この時点では、PHP プログラムはアップロードされたファイルを処理しなくなり、代わりに「/etc/passwd」を処理します (通常、コンテンツが公開されることになります)。この攻撃を使用すると、機密ファイルの内容が暴露される可能性があります。前に述べたように、新しいバージョンの PHP は HTTP_POST_FILES[] を使用してアップロードされたファイルを判断し、この問題を解決するための多くの関数も提供します。たとえば、ファイルが実際にアップロードされたかどうかを判断する関数もあります。これらの関数はこの問題をうまく解決しますが、実際には、依然として古い方法を使用しており、この攻撃に対して脆弱な PHP プログラムが数多くあるはずです。ファイルアップロード攻撃手法の変形として、次のコードを見てみましょう。攻撃者が "$theme" を制御できる場合、攻撃者が "$theme" を使用してリモートシステム上の任意のファイルを読み取ることができることは明らかです。攻撃者の最終的な目標は、リモートサーバー上で任意の命令を実行することですが、リモートファイルを使用できないため、リモートサーバー上に PHP ファイルを作成する必要があります。これは最初は不可能に思えるかもしれませんが、攻撃者が最初にローカルマシン上に PHP コードを含むファイルを作成し、次に "theme" という名前のファイルフィールドを含むフォームを作成し、最後にこのフォームを使用すると、これが行われます。作成した PHP コードを含むファイルをファイルアップロードを通じて上記のコードに送信すると、PHP は攻撃者が送信したファイルを保存し、file_exists() 関数を攻撃者が送信したファイルに設定します。チェックに合格し、攻撃者のコードが実行されます。任意の命令を実行できるようになった攻撃者は、権限を昇格したり、結果を拡張したりすることを意図しているのは明らかですが、そのためにはサーバー上で利用できないツールセットが必要になるため、ファイルのアップロードが再び役に立ちます。攻撃者は、ファイルアップロード機能を使用してツールをアップロードし、サーバーに保存してからコマンドを実行し、chmod() を使用してファイルのアクセス許可を変更し、それを実行する可能性があります。たとえば、攻撃者はファイアウォールまたは IDS をバイパスして、ローカルの root 攻撃プログラムをアップロードして実行し、root 権限を取得する可能性があります。