動的セキュリティテスト ( 機能 4)

最後に、TDD側のテストコードをパースし、テストケースで用いられるアクセス 制御ポリシーの抽出と、テストケースとSINKとの対応を求める(Parser 2)。Sink test coverageはセキュリティコマンドベースのテストカバレッジであり、SCと RCで別々に集計される。Asset test coverageはアクセス制御テストカバレッジ である。

メトリックスは全体の把握には適しているが、個別の問題の修正には情報とし て不十分である。そこで、トレース機能を用いて、特定の警告に関して、ツール 実行時の詳細情報を提示する機能を追加した。

図4.4: ツールの実行フロー とテストカバレッジの計測

4.1.5.2 セキュリティテストケースの自動生成

セキュリティテストケースを自動生成するためには、対象となるWebアプリ ケーションのアタックサーフェースでの振る舞いがわかっている必要がある。

Rail-roadMapが生成する制御フローモデルはWebアプリケーションの振る舞いをモ

デル化しており、UATの自動生成に適している。

次に、セキュリティテストケースの選択であるが、アプリケーションが利用し ているセキュリティ機能(コマンド)が同じであれば、テストする箇所は最低一箇 所で十分である。したがって、個別のセキュリティ機能について、その必要十分 なテストパターンを定義し、アプリケーション上の適切な場所をサンプリングし てテストケースを生成すれば、最低限のテストケースで済む。コマンド配置の網 羅性については静的に検証できるので、セキュリティ機能の実際の動作が、期待 したものであることを動的なテストで確認する。

また、静的検証で問題、もしくは疑わしさが指摘された場合には、その確認の ために動的テストを実施する。例えば、フレームワークの提供するセキュリティ 機能をバイパスし、独自の実装を行った場合などである。

図4.5にRails Webアプリケーションのセキュリティ検証モデルを用いた動的 セキュリティテストフローを示す。Step 1 からStep 2 までは前述の静的検証の フローである。

セキュリティ検証モデルには、テストケース生成に必要なサンプルデータが含 まれないため、“Test plan”として、ツールにテストケース生成で必要となる情報 を補足する。テスト結果が陽性だった場合は、コードを修正して指摘された脆弱 性を排除する。このセキュリティテストケースはUATの一つとして提供されるた め、脆弱性の修正は容易である。陽性であっても、実用上は問題ないと判断した 場合は、アプリケーションに動作の前提条件（環境）を整理し、セキュリティ要件 を更新する。

初期のバーションでは、テストケース生成に、形式手法の反例を用いる方法を 検討した。具体的には、制御フローモデルを B Method の状態遷移図で出力し、

入出力条件から、反例として、特定の遷移経路を得て、それをUATに変換する。

しかしながら、実際には制御フローモデルを直接検索し遷移経路を抽出する手法 で実用上は十分なこと、またUATの記述スタイルに自由度が多く、個別のアプリ ケーションに適したテストケースの生成が難しいことから、最新のバージョンで は形式手法の反例は利用していない。代わりに、Testplanの形で、個別のアプリ ケーション開発のテストスタイルを取り込むようにしている。

Testplanの実例については4.3.2節で示す。現在、Testplanによるテスト生成 には表4.5で示す3種類の設定方法をサポートしている。

表4.5: Testplanの設定 生成方法 説明

automatic 自動生成、開発者は自動生成に必要なパラメータを設定

Modification of 攻撃箇所に対する通常の成功シナリオを与える、

existing testcase 攻撃シナリオは与えられたシナリオを元に自動生成。

Use existing Testplanでシナリオを記述 testcase

図4.5: Rails Webアプリケーションのセキュリティ検証モデルを用いた動的 セキュリティテストフロー(version 0.2.3)