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

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

元のソース: エクスプロイト元の内容を Bole Toutiao に共有することを歓迎します

0×00

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

0×01

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

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

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

2. グローバル情報収集モジュール
このモジュールは、主に、監査プロジェクト内にクラスがいくつあるかの定義の収集、メソッド名、パラメーター、メソッドの収集など、分析されたソースコードファイルから統合された情報を収集するために使用されます。クラス内の定義コードを収集し、その後の静的解析を高速化します。

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

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

0×02

このモジュールを使用して、自動監査を実装するための効果的なプロセスを実行するにはどうすればよいですか?

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

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

まず、分析フレームワークを初期化します。主に、分析対象のソースコードプロジェクト内のすべてのユーザー定義クラスに関する情報 (クラス名、クラス属性、クラスメソッド名、クラスが配置されているファイルパスなど) を収集します。
これらのレコードは、グローバルコンテキストクラス Context に保存されます。Context は、シングルトンパターンを使用して設計され、その後の分析と使用を容易にするためにメモリに常駐します。

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

次に、各 PHP ファイルがメインファイルであるかどうかを判断します。 PHP 言語には、いわゆる main 関数はありません。Web 上のほとんどの PHP ファイルは、呼び出しと定義の 2 つのタイプに分けられます。定義タイプの PHP ファイルは、一部のビジネスクラス、ツールクラス、ツール関数などを定義するために使用されます。ユーザーは、呼び出しタイプに提供された PHP ファイルにアクセスして呼び出しを行います。ユーザーリクエストを実際に処理するのは、グローバルのindex.phpファイルなど、PHPファイルの呼び出しタイプです。静的分析は主に、ユーザーが要求した呼び出しタイプを処理する PHP ファイル、つまりメインファイルを対象としています。判定基準は、
AST解析の完了に基づいて、PHPファイル内のクラス定義およびメソッド定義のコード行数が、ファイル内の総コード行数の範囲を超えているかどうかを判断します。そのため、これは PHP ファイルの定義されたタイプとみなされ、それ以外の場合はメインファイルが分析対象のファイル名のリストに追加されます。

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

このプロジェクトは、PHP 言語自体に基づいて開発されており、AST の構築には、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 = addedlashes($sql) ;
代入ステートメントの右側がフィルター関数 (ユーザー定義フィルター関数または組み込みフィルター関数) の場合、呼び出し元関数の戻り値は精製されます。 $clearsql の精製ラベルとaddslashes。
関数呼び出しを検出し、関数名が構成ファイルで構成された安全な関数であるかどうかを判断します。
「はい」の場合、場所のシンボルにサニタイズタグを追加します。

7. プロセス間分析

監査中にユーザー関数への呼び出しが発見された場合は、この時点でプロセス間分析を実行する必要があり、特定のメソッドのコードブロックが分析されたプロジェクト内に配置され、変数が分析のために取り込まれる必要があります。
難しいのは、変数のバックトラッキングを実行する方法、異なるファイル内の同じ名前のメソッドを処理する方法、クラスメソッド呼び出し分析をサポートする方法、およびユーザー定義のシンクを保存する方法 (myexec での exec 関数の呼び出しなど) にあります。効果的に浄化されていない場合、myexec も危険な関数とみなされるべきです)、ユーザー定義のシンク (SQLI XSS XPATH など) を分類する方法。

処理プロセスは次のとおりです:

8. 汚染分析

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

0×03

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

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