PHP 自動コード監査テクノロジーに関する簡単な説明

??

0x00

ブログで更新することが本当に何もないので、これまでに行ったことをまとめてブログとして扱い、主にプロジェクトで使用されているいくつかのテクノロジーについて話します。現在、RIPS や Pixy などのオープンソース ツールや Fortify などの商用バージョンなど、多くの PHP 自動監査ツールが市場に出回っています。 RIPS は現在最初のバージョンしかありません。PHP のオブジェクト指向解析をサポートしていないため、その効果は現時点ではあまり満足のいくものではありません。 Pixy はデータ フロー分析に基づくツールですが、PHP4 のみをサポートします。 Fortify は商用バージョンであるため、この制限により調査することはできません。 PHP の自動監査に関する国内の研究は一般的に企業によって行われており、現在、ほとんどのツールは単純なトークン フロー分析を使用するか、照合に正規表現を使用するより直接的かつ粗雑なものであり、その効果は非常に平均的です。

0x01

今日話したいテクノロジーは、静的分析に基づく PHP 自動監査の実装アイデアであり、私のプロジェクトのアイデアでもあります。より効果的な変数分析やテイント分析を実行し、PHP スクリプトのさまざまな柔軟な構文表現に対応するには、正規表現の効果は決して理想的ではありません。今回紹介したアイデアは、コードの静的分析技術とデータ監査に基づいています。ストリーミング分析テクノロジー。

まず第一に、効果的な監査ツールには少なくとも次のモジュールが含まれていると思います:

1. フロントエンド モジュールのコンパイル

フロントエンド モジュールのコンパイルは、主に抽象構文ツリー構築と制御フロー グラフ構築メソッドを使用します。ソースコードファイルをコンパイル技術で変換し、バックエンドの静的解析に適した形式に変換します。

2. グローバル情報収集モジュール

このモジュールは、主に、監査プロジェクトに存在するクラスの数の定義の収集、メソッド名の収集など、分析されたソース コード ファイルに関する統合情報を収集するために使用されます。パラメータ、およびメソッド定義コード ブロックの開始行番号と終了行番号が収集され、後続の静的解析が高速化されます。

3. データフロー解析モジュール

このモジュールは、コンパイル技術におけるデータフロー解析アルゴリズムとは異なり、PHP 言語自体の特性の処理に重点を置いています。システムのプロセス間およびプロセス内分析中に機密関数の呼び出しが検出されると、関数内の機密パラメーターに対してデータ フロー分析が実行されます。つまり、変数の特定の変更が追跡され、準備が整います。その後の汚染分析。

4. 脆弱性コード分析モジュール

このモジュールは、データ フロー分析モジュールによって収集されたグローバル変数、代入ステートメント、およびその他の情報に基づいて汚染データ分析を実行します。 mysql_query 関数の最初のパラメータなど、主に機密シンクの危険なパラメータをターゲットとしており、バックトラッキング プロセス中にパラメータにユーザー制御の兆候があることが判明した場合、対応するデータ フロー情報が記録されます。危険なパラメータに対応するコードがある場合は、浄化操作も記録する必要があります。危険なパラメーターに関するデータを追跡および分析することで、汚染分析を完了します。

0x02

自動監査を実装するための効果的なプロセスを実行するにはどうすればよいですか? 私は次のプロセスを使用しました:

システムを分析する一般的なプロセスは次のとおりです:

1. フレームワークの初期化

最初の分析 フレームワークの初期化作業は主に、クラス名、クラス属性、クラス メソッド名、クラスが配置されているファイル パスなど、分析対象のソース コード プロジェクト内のすべてのユーザー定義クラスに関する情報を収集することです。

これらのレコードは、グローバル コンテキスト クラス Context に保存されます。Context は、シングルトン パターンを使用して設計され、その後の分析と使用を容易にするためにメモリに常駐します。

2. メイン ファイルを決定します

次に、各 PHP ファイルがメイン ファイルであるかどうかを決定します。 PHP 言語には、いわゆる main 関数はありません。Web 上のほとんどの PHP ファイルは、呼び出しと定義の 2 つのタイプに分けられます。定義タイプの PHP ファイルは、一部のビジネス クラス、ツール クラス、ツール関数などを定義するために使用されます。ユーザーは、呼び出しタイプに提供された PHP ファイルにアクセスして呼び出しを行います。ユーザーリクエストを実際に処理するのは、グローバルのindex.phpファイルなど、PHPファイルの呼び出しタイプです。静的解析は主に、ユーザーが要求した呼び出しタイプを処理する PHP ファイル、つまりメイン ファイルを対象としています。判断基準は、

AST解析の完了に基づいて、PHPファイル内のクラス定義およびメソッド定義のコード行数がファイル内の全コード行数の範囲を超えているかどうかを判断します。 PHP ファイルはタイプを定義しているとみなされ、それ以外の場合は Main File が分析対象のファイル名のリストに追加されます。

3. AST 抽象構文ツリーの構築

このプロジェクトは、PHP 言語自体に基づいて開発されており、現在の優れた PHP AST 構築実装???PHP パーサーを参照します。

このオープンソース プロジェクトは、PHP 言語自体に基づいて開発されており、if、while、switch、配列宣言、メソッド呼び出し、グローバル変数、その他の文法構造など、PHP のほとんどの構造を解析できます。このプロジェクトのコンパイル フロントエンド処理の一部を非常にうまく完了できます。

4. CFG フロー グラフの構築

CFGGenerator クラスの CFGBuilder メソッドを使用します。メソッドは次のように定義されます:

具体的なアイデアは、再帰を使用して CFG を構築することです。まず、AST を走査して得られたノードのコレクションを入力し、そのコレクション内の要素 (ノード) の種類 (分岐、ジャンプ、終了など) を判定し、CFG を生成します。ノードタイプに応じて構築されます。

ここで、データフロー解析を容易にするために、分岐文やループ文のジャンプ条件(条件)をCFGのエッジ(Edge)に格納する必要があります。

5. データ フロー情報の収集

コード ブロックの場合、最も効果的で価値のある情報は、代入ステートメント、関数呼び出し、定数 (const 定義)、および登録された変数 (parse_str の抽出) です。

代入ステートメントの機能は、後続の変数追跡のためのもので、実装では、代入された値と位置を表す構造体を使用しました。その他のデータ情報はASTに基づいて識別および取得されます。たとえば、関数呼び出しでは、変数がエスケープされているか、エンコードされているかなど、または呼び出された関数がシンク (mysql_query など) であるかどうかを判断します。

6. 変数の精製、エンコード情報の処理

$clearsql =addslashes($sql) ;

代入文、右辺がフィルタ関数（ユーザ定義のフィルタ関数または組み込みフィルタ関数の場合） )、その後呼び出します。関数の戻り値はサニタイズされます。つまり、$clearsql のサニタイズ タグにスラッシュが追加されます。

関数呼び出しを検出し、関数名が構成ファイルで構成された安全な関数であるかどうかを判断します。

「はい」の場合、場所のシンボルにサニタイズタグを追加します。

7. プロセス間分析

監査中にユーザー関数の呼び出しが見つかった場合は、この時点でプロセス間分析を実行する必要があり、特定のメソッドのコード ブロックは分析されたプロジェクト内にあります。そして変数が分析のために取り込まれます。

難しいのは、変数のバックトラッキングを実行する方法、異なるファイル内の同じ名前のメソッドを処理する方法、クラスメソッド呼び出しの分析をサポートする方法、およびユーザー定義のシンクを保存する方法 (myexec での exec 関数の呼び出しなど) です。 、効果的な浄化がない場合、myexec も危険な関数とみなされます)、ユーザー定義のシンク (SQLI XSS XPATH など) を分類する方法。

処理フローは次のとおりです:

8. 汚染分析

上記のプロセスで最後に行うことは、主にシステムに組み込まれているいくつかのリスク機能 (原因となる可能性のあるエコーなど) を対象とする汚染分析です。 ｘｓｓ。そして、危険な関数内の危険なパラメータの効果的な分析を行う必要があります。これらの分析には、効果的な浄化 (エスケープ、定期的なマッチングなど) が実行されたかどうかの判断や、以前の割り当てなどをリトレースするためのアルゴリズムの策定が含まれます。変数の変換。これは間違いなくセキュリティ研究者のエンジニアリング能力をテストするものであり、自動監査の最も重要な段階でもあります。

0x03

上記の紹介を通して、独自の自動監査ツールを実装するには多くの落とし穴があることがわかります。また、その試みには多くの困難があり、例えば、動的解析では容易に得られる文字列変換処理を静的解析では実現することが技術的に不可能であるなど、静的解析には一定の限界がありました。したがって、純粋な静的分析で偽陽性と偽陰性を低く抑えたい場合は、結局のところ、eval や文字列変換関数や通常のコードをシミュレートするなど、いくつかの動的なアイデアを導入する必要があります。加工用の表現など。また、CI フレームワークなどの一部の MVC ベースのフレームワークでは、コードが非常に分散しています。たとえば、このような PHP アプリケーションの場合は、データ精製コードが入力クラスの拡張子に配置されるため、これを実現するのは難しいと思います。普遍的な監査フレームワークは個別に扱う必要があります。

上記は、私が共有しようとしている現在の試み (現時点では完全には実装されていません) の大まかな概要にすぎません。結局のところ、大学の犬は専門家ではありません。これが、より多くのセキュリティ研究者にこの分野に注目してもらうきっかけになれば幸いです。