ファジングとは？ 10分でわかりやすく解説

ファジングとは、ソフトウェアに不正な入力、予期しない入力、極端な値、壊れたデータなどを大量に与え、クラッシュ、ハング、メモリ異常、例外処理の不備などを検出するテスト手法です。通常の機能テストでは想定入力を中心に確認しますが、ファジングは想定外入力への耐性を機械的に調べる点に特徴があります。脆弱性の早期発見、入力検証の改善、リリース前後の品質確認に使われます。

ファジングとは何か

ファジングは、テスト対象のプログラムやサービスに対して、ランダムまたは半ランダムな入力を継続的に投入し、その応答を監視するテスト手法です。入力データは、完全に無作為に生成される場合もあれば、既存の正常データを少しずつ変化させる場合、ファイル形式やプロトコル仕様に沿って生成される場合もあります。

検出対象は、クラッシュ、ハング、メモリ破壊、例外処理の漏れ、入力検証の不備、サービス停止につながる異常動作などです。攻撃者が狙うのは、開発者が想定していない入力や境界条件であることが多いため、ファジングはセキュリティテストと品質テストの両方で使われます。

ファジングの定義

ファジングは、不正、予期しない、または無作為な入力をテスト対象に与え、その挙動を確認するソフトウェアテストです。NISTの用語集では、ファズテストを、無効・予期しない・意味をなさない入力に対してプログラムやモジュールが許容できる応答を返すか確認するテストとして説明しています。

実務では、ファザーと呼ばれるツールを使い、入力生成、実行、異常検出、クラッシュ入力の保存を自動化します。人が個別に思いつくテストケースではなく、機械的に大量の入力を試すことで、人手のテストでは見落としやすい条件を探索します。

ファジングで発見しやすい問題

• 不正な入力でプログラムがクラッシュする問題
• 入力長や境界値の処理ミス
• バッファオーバーフローなどのメモリ破壊
• 例外処理やエラーハンドリングの不足
• ファイル形式やプロトコル処理の実装ミス
• APIやパーサの想定外入力への弱さ

ファジングは、特に入力を解釈する処理に適しています。ファイルパーサ、画像・音声・動画処理、圧縮・展開処理、ネットワークプロトコル、API、ブラウザ、暗号ライブラリ、コマンドラインツールなどは、ファジングの対象になりやすい領域です。

ファジングの目的と位置づけ

脆弱性を早期に見つける

ファジングの主な目的は、攻撃者に悪用される前に脆弱性や重大な不具合を見つけることです。特にC/C++などメモリ安全性の問題が起きやすい言語では、バッファオーバーフロー、use-after-free、整数オーバーフローなどを検出する目的で使われます。

リリース後に発見された脆弱性は、修正、告知、パッチ配布、顧客対応まで含めて大きな負担になります。開発中にファジングを実行しておけば、修正コストを抑えながら、ソフトウェアの耐性を確認できます。

通常テストでは届きにくい入力を試す

通常の単体テストや結合テストでは、仕様に沿った入力、代表的な異常入力、境界値を中心に確認します。しかし、実際の攻撃や障害では、仕様外の入力、壊れたファイル、不正なパラメータ、極端に長い文字列、想定外の順序のリクエストが使われます。

ファジングは、こうした入力を大量に生成し、ソフトウェアが落ちずに処理できるか、適切にエラーを返せるかを確認します。正常系の品質確認ではなく、異常系への耐性を確認する手法として位置づけると理解しやすくなります。

セキュア開発に組み込む

ファジングは、単発の検査よりも継続実行で効果を出しやすい手法です。新しいコードが追加されるたびにファジングを実行すれば、入力処理の変更で混入した不具合を早期に検出できます。

CI/CDパイプラインへ組み込む場合は、短時間で実行するスモーク的なファジングと、夜間や週末に長時間実行するファジングを分ける方法があります。CI/CDに組み込むことで、コード変更と検出結果を結びつけやすくなります。

ファジングの主な種類

ブラックボックスファジング

ブラックボックスファジングは、テスト対象の内部構造やソースコードを前提にせず、外部から入力を与えて挙動を確認する方式です。既存のバイナリや外部公開APIなど、内部を詳しく把握できない対象にも適用しやすい点が利点です。

一方で、内部でどのコードが実行されたかを把握しにくいため、探索効率が下がる場合があります。結果として、クラッシュは検出できても、なぜその箇所へ到達したのか、どの範囲を十分に試せているのかを判断しにくくなります。

ホワイトボックスファジング

ホワイトボックスファジングは、ソースコードや内部構造を前提にして入力を生成する方式です。特定の関数、分岐、コードパスに到達する入力を狙いやすく、解析精度を高めやすい特徴があります。

ただし、ソースコードやビルド環境へのアクセスが必要になり、準備に時間がかかる場合があります。解析コストも高くなるため、重要なコンポーネントや高リスクな入力処理に対象を絞る設計が適しています。

グレーボックスファジング

グレーボックスファジングは、内部構造を完全には理解しないものの、コードカバレッジなどの実行時フィードバックを利用する方式です。現在の実務では、効率と導入しやすさのバランスから広く使われています。

代表的には、入力によって新しいコードパスに到達した場合、その入力を有望なシードとして残し、さらに変異させます。単純なランダム入力よりも効率よく探索範囲を広げられます。

入力生成の方式

突然変異ベースのファジング

突然変異ベースのファジングは、正常なファイル、実際のリクエスト、既存テストデータなどをシードとして使い、それらに変化を加えて新しい入力を作る方式です。たとえば、数値を極端な値に変える、文字列を長くする、特定バイトを反転する、フィールドを削除する、といった操作を行います。

実装が比較的簡単で、既存データを活用しやすい点が利点です。ただし、入力フォーマットが複雑な場合、変異後のデータが早い段階で不正として弾かれ、深い処理まで到達しにくいことがあります。

生成ベースのファジング

生成ベースのファジングは、入力データの構造をモデル化し、その構造に沿ってデータを作る方式です。ファイルフォーマット、ネットワークプロトコル、JSONスキーマ、API仕様などが整理されている場合に使いやすい方法です。

形式として成立する入力を作れるため、表層の構文チェックを通過し、深い処理まで到達しやすくなります。一方で、入力モデルの作成に手間がかかります。仕様変更がある場合は、モデルの更新も必要です。

カバレッジ指向型ファジング

カバレッジ指向型ファジングは、テスト中にどのコードが実行されたかを計測し、未実行の分岐やコードパスへ到達する入力を優先して探索する方式です。AFL、libFuzzer、Honggfuzzなどのファザーで知られる考え方です。

この方式では、新しい経路を通る入力を保存し、それをさらに変異させます。単にクラッシュを待つのではなく、探索範囲を広げながら異常動作を探すため、効率的に問題を見つけやすくなります。

ファジングの実践手順

対象を選ぶ

まず、ファジングに適した対象を選びます。候補は、外部入力を受け取る処理、複雑なファイルやメッセージを解析する処理、過去に不具合が多かったモジュール、インターネットに公開される機能です。

対象を広げすぎると、環境構築や結果分析の負担が増えます。最初は、クラッシュ時の影響が大きいコンポーネント、攻撃対象になりやすい入力処理、修正担当者が明確な範囲から始める方が運用しやすくなります。

テスト環境を用意する

ファジングは、大量の入力を実行し、意図的に異常動作を起こします。本番環境では実施せず、隔離されたテスト環境で実行します。仮想マシン、コンテナ、専用テストサーバーなどを使い、ファイル出力、ネットワーク通信、外部API呼び出しによる影響を制御します。

クラッシュ時に、入力データ、ログ、スタックトレース、実行環境、バージョンを保存できるようにします。再現できないクラッシュは修正につながりにくいため、記録の設計がファジング結果の価値を左右します。

シードと入力モデルを準備する

突然変異ベースの場合は、正常な入力データをシードとして用意します。シードは数が多ければよいわけではありません。形式や機能を代表する多様なデータを選ぶことが重要です。

生成ベースの場合は、ファイル形式、通信手順、APIパラメータ、値の範囲などをモデル化します。仕様の理解が浅いまま入力を生成すると、表層のエラーだけで終わり、深い処理まで到達できません。

実行し、異常を記録する

ファザーを実行し、クラッシュ、ハング、メモリ異常、例外、タイムアウトを記録します。実行中は、カバレッジ、実行回数、クラッシュ件数、重複クラッシュ、リソース使用量を確認します。

短時間で結果が出ない場合でも、すぐに失敗と判断しません。対象によっては長時間の実行が必要です。ただし、カバレッジが伸びない、同じクラッシュだけが増える、入力が初期段階で弾かれている場合は、シードや設定を見直します。

結果を分類し、修正する

検出されたクラッシュは、重複を除外し、原因別に分類します。影響度、再現性、悪用可能性、修正難易度を確認し、対応順を決めます。特に、任意コード実行、情報漏えい、サービス停止につながる可能性がある問題は優先して扱います。

修正後は、同じ入力で再現しないことを確認し、回帰テストとして残します。ファジングで見つかった問題は、単発修正で終わらせず、入力検証、例外処理、メモリ管理、コーディング規約の見直しにも反映します。

ファジングを開発プロセスへ組み込む方法

CI/CDで短時間実行する

CI/CDでは、すべてのファジングを長時間実行するのではなく、変更の影響を受けやすい範囲を短時間で確認する構成にします。ビルド後に数分から数十分のファジングを実行し、クラッシュが出た場合はビルドを失敗させる方法があります。

長時間の探索は、夜間バッチや専用環境で実行します。短時間のチェックと長時間の探索を分けることで、開発速度を落としすぎずに継続的な検査を行えます。

バグ管理と連携する

ファジングで検出した問題は、バグ管理システムへ登録します。登録時には、再現入力、実行コマンド、バージョン、環境、スタックトレース、影響範囲、重複判定を添えます。

報告の粒度が粗いと、開発者は再現確認に時間を取られます。ファジングの運用では、検出よりも、再現、分類、修正、再テストまでを一連の流れとして設計する必要があります。

他のテストと組み合わせる

ファジングは万能ではありません。仕様違反、認可不備、業務ロジックの欠陥、暗号設計の問題、権限管理の不備などは、ファジングだけでは見つけにくい場合があります。

そのため、静的解析、単体テスト、結合テスト、動的解析、ペネトレーションテストと組み合わせます。静的解析で危険な箇所を把握し、ファジングで入力耐性を確認し、ペネトレーションテストで実際の攻撃経路として成立するかを見る、といった使い分けが有効です。

ファジングのメリットと限界

ファジングは、発見確率を高める手法です。実行すれば必ず脆弱性を見つけられるわけではありません。また、クラッシュが出ないことは、安全性の完全な証明ではありません。どの範囲をどの程度探索したのか、どの種類の問題を検出対象にしたのかを明確にして評価する必要があります。

ファジング導入時の注意点

本番環境で実行しない

ファジングは、異常入力を大量に送るテストです。本番環境や外部サービスに対して無計画に実行すると、サービス停止、データ破損、第三者への影響が発生するおそれがあります。必ず許可された環境で、影響範囲を制御して実施します。

クラッシュの重複を整理する

ファジングでは、大量のクラッシュが検出される場合があります。しかし、その多くが同じ原因に由来することがあります。重複を整理しないまま開発者へ渡すと、解析負荷が増えます。スタックトレース、シグナル、クラッシュ箇所、入力の特徴で分類します。

シードの品質を見直す

良いシードは、探索の効率を大きく左右します。正常入力だけでなく、実際に使われるファイル、代表的なAPIリクエスト、境界値に近い入力を含めます。シードが偏ると、特定機能だけを繰り返し探索し、未検査の領域が残ります。

修正後の再テストを自動化する

ファジングで見つかった入力は、回帰テストとして残します。修正後に同じ入力で再現しないことを確認し、将来の変更で同じ問題が戻らないようにします。クラッシュ入力を資産化しないと、ファジングの効果が一時的になります。

参考資料

• NIST CSRC Glossary：Fuzz Testing
• OWASP：Fuzzing
• Google OSS-Fuzz：Documentation for OSS-Fuzz

まとめ

ファジングは、ソフトウェアに不正・予期しない・ランダムな入力を大量に与え、クラッシュや異常動作からバグや脆弱性を見つけるテスト手法です。通常テストでは届きにくい入力処理の弱点を探索できるため、ファイルパーサ、API、プロトコル実装、ライブラリなどの検査に適しています。

実務では、対象選定、シード準備、隔離環境、クラッシュ記録、重複分類、修正後の再テストまでを一連の流れとして設計します。ファジングだけで安全性を証明することはできませんが、静的解析、単体テスト、ペネトレーションテスト、CI/CDと組み合わせることで、脆弱性の早期発見と継続的な品質改善に役立ちます。