Webアプリケーションセキュリティスキャナーのテスト：アプローチと基準

情報セキュリティスキャナー（脆弱性スキャナー）は、コンピューターネットワーク、個々のコンピューター、およびそれらにインストールされているアプリケーションのセキュリティ問題をチェックするために使用できる監視および制御ツールです。 ほとんどのスキャナーでは、 WASC Threat Classifcationで説明されている脆弱性を検出できます。 今日のhabratopikaでは、ソフトウェア製品としてのWebアプリケーション用の情報セキュリティスキャナーのテストに関連するいくつかの問題を検討します。



最新のWebアプリケーションスキャナーは、多機能で高度に洗練された製品です。 したがって、そのテストと同様のソリューションとの比較には多くの機能があります。

試験手順

記事「 Webアプリケーションスキャナー用のテストスイートの構築 」では、スキャナーをテストする一般的な原則の概要を説明します。 これらの原則の1つは、さまざまなWebアプリケーションスキャナーのパフォーマンスを比較するためのテスト手順です。 わずかに変更された形式では、この手順は次のとおりです。

1. すべての技術要件の機能検証に必要なテストコンテンツを準備し、テストスタンドを展開します。
2. テストを初期化し、テストに必要なすべての設定を取得します。
3. スキャンされたWebアプリケーションを設定し、脆弱性のタイプとその保護レベルを選択します。
4. テスト対象のWebアプリケーションで選択した設定でスキャナーを実行し、一連の機能テストに合格します。
5. スキャナーによって検出されたWebオブジェクト（一意のリンク、脆弱性、攻撃ベクトルなど）をカウントおよび分類します。
6. 脆弱性の種類と保護レベルごとに手順2〜5を繰り返します。

各反復後の変更は、オブジェクトの検出結果のサマリーテーブルに入力する必要があります。 次のようになります。







明らかに、すべてのWebアプリケーションスキャナーが同じスキャンモジュールのセットを持っているわけではありませんが、このテーブルは引き続き使用でき、特定のモジュールまたは1つまたは別の機能がない場合のスキャナーの評価を下げます。



事前にわかっている特定の種類の脆弱性の正確な数でテストアプリケーションを準備することはできません。 そのため、このようなテーブルをコンパイルする場合、検索する実際のオブジェクトの数を決定する際に必然的に困難に直面します。 この問題は次のように解決できます。

1. 1つの脆弱性として、テストWebアプリケーションに見られる同等の脆弱性のクラスを考慮してください。 たとえば、SQLインジェクションの場合、同等の脆弱性のクラスは、アプリケーションへのGET要求の同じパラメーターで見つかったすべての脆弱性と見なすことができます。 言い換えると、Webサーバーまたはデータベースの障害を引き起こす脆弱なidパラメーターがある場合、このパラメーターを使用するすべての攻撃ベクトルは、パラメーターの並べ替えまで同等と見なすことができます： example.com/page.php? id= blabla 〜example.com / page.php ? a=1&id=bla&b=2
2. いくつかの脆弱性を実装またはシミュレートする単純なテストアプリケーションを開発しますが、さまざまなフレームワークを使用して、さまざまなオペレーティングシステムオプション、さまざまなWebサーバー、さまざまなデータベース、さまざまな種類のネットワークプロトコルおよびさまざまなプロキシチェーンを介して展開します。
3. 多くの異なるCMS、脆弱なアプリケーション（DVWA、Gruyere、OWASP Site Generatorなど）をテストスタンドに展開し、さまざまなセキュリティスキャナーでスキャンします。 すべてのスキャナーで発見された脆弱性の総数を標準とみなし、さらなるテストで使用する必要があります。

たとえば、 OWASP Site Generatorツールを使用して必要な保護レベルを設定することにより、テストアプリケーションを構成および管理できます。OWASPSite Generatorツールの構成は、通常のXMLファイルに保存および編集できます。 残念ながら、現時点ではこのツールは廃止されていると見なされているため、独自の開発用アプリケーションを作成して、現代の脆弱性をエミュレートすることをお勧めします。



スキャナーをスキャンするためにテストコンテンツに実装される脆弱性のタイプは、 WASC Threat Classificationから取得できます。



インストールされたアプリケーションのすべての可能な組み合わせに対するテスト手順の予想される開始回数は、非常に大きくなりますが、これは驚くことではありません。 この数は、 ペアワイズ分析テスト手法を使用して減らすことができます。



スキャン結果に基づいて、次の形式の数値ベクトルを取得します



（保護レベル、検出されたオブジェクトの数、False Positive、False Negative、合計オブジェクト、スキャン時間）



次に、スキャンの品質に関するメトリックを入力する必要があります。これは、インジケーターとスキャナーを互いに比較するために使用できます。 最も単純なユークリッドメトリックを同様のメトリックとして使用するだけで十分です。

テストの種類

Webアプリケーションスキャナーをテストするときに信頼できる別の記事は、Webアプリケーションセキュリティスキャナーの精度と時間コストの分析と呼ばれます。 この資料では、さまざまなスキャナー（BurpSuitePro、Qualys、WebInspect、NTOSpider、Appscan、Hailstorm、Acunetix）のテストについて説明し、特定のツールごとに4種類のテストを実施することを提案しています。

1. ポイントアンドシュート（PaS）モードでWebアプリケーションをスキャンし、検出および確認された脆弱性の数を判断します。
2. 予備的な「トレーニング」後に再スキャンし、このタイプのアプリケーションで動作するようにスキャナーを構成し、この場合に発見および確認された脆弱性の数を判断します。
3. 見つかった脆弱性の説明の正確性と完全性を評価します。
4. テスト、分析の準備と実行、およびスキャン結果の品質の確保に専門家が費やした合計時間を評価します。

PaSモードは、標準のスキャナー設定でスキャンを開始することです。 「目標の設定-スキャン-結果の取得」スキームに従って行われます。



トレーニング -構成設定、スクリプトの変更、スキャナーのサプライヤーとの通信などが含まれます。



専門家が質の高い結果を得るために費やす必要がある時間を決定するために、この記事では簡単な式を使用することを提案しています。



合計時間=トレーニング時間+ #False Positive * 15分 + #False Negative * 15分



各テスト中に、上記で説明したテスト手順を適用する必要があります。

Web Application Scannerの評価基準

別の有用な記事「 Top 10：The Web Application Vulnerability Scanners Benchmark 」で、著者はスキャナーの特性を比較する一般的なアプローチと、そのような特性のセットを例を挙げて提案しています。 この記事では、以下の基準を使用して、Webアプリケーションスキャナーの機能を表形式で評価することを提案します。

1. 基準推定に関連する製品価格の比較 。 （価格比較-残りのベンチマーク結果との関係で）。 比較の例は、 ピボットテーブルにあります 。
2. スキャナーの汎用性-プロトコルおよび入力配信ベクターのスキャナーのサポートの尺度は、サポートされているプロトコルと配信ベクターの数であり、サーバーにデータを配信する方法です。 配信ベクトルには、クエリ文字列のHTTPパラメーター、HTTPボディパラメーター、JSON、XML、AMF、Javaシリアル化オブジェクト、WCFなどの特定のテクノロジのバイナリメソッドなど、サーバーにデータを配信するためのメソッドが含まれます。 比較の例は、 ピボットテーブルにあります 。
3. サポートされる攻撃ベクトルの数：アクティブなスキャナープラグインの数とタイプ（攻撃ベクトルのサポート-アクティブなスキャンプラグインの量とタイプ（脆弱性検出））。 比較の例は、 ピボットテーブルにあります 。
4. CSS検出精度 （クロスサイトスクリプティング検出精度を反映）。 比較の例は、 ピボットテーブルにあります 。
5. SQLインジェクション検出の精度 比較の例は、 ピボットテーブルにあります 。
6. Webアプリケーション構造をバイパスし、ローカルファイルを検索する精度 。 （パストラバーサル/ローカルファイルインクルージョン検出精度）。 比較の例は、 ピボットテーブルにあります 。
7. リモートファイル使用、XSS、RFI経由のフィッシング 。 （リモートファイルインクルージョン検出精度（XSS / RFI経由のフィッシング））。 比較の例は、 ピボットテーブルにあります 。 RFIテストケースの例は図に示されます 。
8. WIVETの比較 ：自動クロールおよび攻撃用入力ベクトルの取得（WIVET（Web入力ベクトル抽出ティーザー）スコア比較-自動クロール/入力ベクトル抽出）。 比較の例は、 ピボットテーブルにあります 。
9. スキャナーの適応性 ：保護バリアを克服するためのスキャナーの追加機能の数（スキャナーの適応性-補完的なカバレッジ機能とスキャンバリアサポート）。 比較の例は、 ピボットテーブルにあります 。
10. 認証機能の比較 ：サポートされている認証方法と認証の数と種類（認証機能の比較）。 比較の例は、 ピボットテーブルにあります 。
11. 追加のスキャン機能と組み込みメカニズムの数。 （補完的なスキャン機能と組み込み製品）。 比較の例は、ピボットテーブルにあります 。
12. メインスキャン機能の動作の一般的な印象 （一般的なスキャン機能と全体的な印象）。 比較の例は、 ピボットテーブルにあります 。
13. ライセンスとテクノロジーの比較（ライセンス比較と一般情報）。 比較の例は、 ピボットテーブルにあります 。

リストされている項目の一部は、オブジェクト検出の概要表に含まれています。 さらに、ほとんどの基準では専門家による評価が必要であり、これによりスキャナーの自動テストと比較が困難になることに気付くかもしれません。 結果として、提案された評価基準は、たとえば、スキャナーの特性に関するより一般的なレポートのセクションとして使用できます。このセクションには、特定のスキャナーを競合他社とテストおよび比較したすべての結果が含まれます。

Webアプリケーションスキャナーのテストの種類

上記の記事の資料に基づいて、テスト手順で使用できるテストタイプの分類を開発しました。

• 基本的な機能（煙）テストでは、メインの低レベルスキャナーノードの動作を確認する必要があります。トランスポートサブシステム、構成サブシステム、ロギングサブシステムなどの動作です。さまざまなトランスポート、リダイレクト、プロキシサーバーなどを使用する場合
• 機能テストでは、基本的なシナリオの検証を実装して、技術要件を検証する必要があります。 モジュールとテスト環境の異なる設定を使用して、各スキャンモジュールの操作性を確認する必要があります。 正および負のテストスクリプトとさまざまなストレステストは、Webアプリケーションへの応答としてスキャナーに送信される正しいデータと誤ったデータの大規模な配列を使用して実行されます。
• 機能を比較（比較）するためのテスト。選択したスキャナーモジュールによるオブジェクトの検索の品質と平均速度を、競合製品の同様の機能を備えたモジュールと比較します。 特定のスキャンモジュールごとに、オブジェクトの意味と検索の品質を定義する必要があります。
• 評価基準（基準）の指標を比較するテスト。テスト中のスキャナーの各新しいバージョンの各スキャンモジュールでオブジェクトを検索する速度と品質が、以前のバージョンと比較して低下していないことを確認します。 速度と品質の定義は、機能を比較するためのテストと同じ方法で設定する必要があります。ただし、このタイプのテストでは、以前のバージョンはテストスキャナーの競合として機能します。

Webアプリケーション用のセキュリティスキャナーについては、トピックで説明されているテスト手順を使用できます。また、スキャン品質メトリックを使用して、スキャナーのメトリックを比較することにより、スキャナーを定性的に比較するツールを取得できます。 このアイデアを発展させるために、ファジーインジケーター、スケール、およびメトリックを使用して、スキャナーと比較して作業を簡素化できます。



ご静聴ありがとうございました。コメント欄で質問にお答えします。



Posted by Timur Gilmullin、Positive Technologies自動テストグループ