AppScan: アプリケーション・セキュリティ・テストの要素

2020/7/14 - 読み終える時間: 2 分

AppScan の動的解析では、テストされた要素に関連してユーザーから質問が出てくることがよくあります。その疑問に答えるブログ記事 The Elements of Application Security Testing (With Apologies to Strunk and White) が英語版ブログにポストされました。その翻訳版を掲載します。

アプリケーション・セキュリティ・テストの要素（Strunk & White への謝罪を込めて)

2020年7月8日

著者: Shahar Sperling / Chief Architect at HCL AppScan

翻訳者注: "Strunk & White" は、適切な記述方法を記した書物 (The Elements of Style) の著者名。

動的解析では、テストされた要素に関連してユーザーから質問が出てくることがよくあります。 質問の内容は様々ですが、ユーザーは一般的に以下のことを知りたいと考えています。

• テストされた要素とは何か。
• それらは本当に進捗を表しているのか。
• いつ生成されるのか。
• テストフェーズを開始すると、数字が突然ジャンプすることがあるのはなぜか。

最後のは、エラーか何かを示しているのではないかと、とても奇妙なことのように思うことでしょう。 しかし、最初の3つの質問に答えれば、それは明らかになります。論理的にも。それについては、このブログで可能な限り説明します。

ルールについて

HCL AppScan の動的テストは、ルールによって定義されています。厳密に言えば、AppScan のルールは作業を定義する変種で構成されています。しかし、この記事では、より一般的な用語を使用します。

• ルールとは、問題を検出するための具体的なテスト命令です。
• 各ルールは、特定の課題タイプを識別するために使用されます。複数のルールが同じ課題タイプを識別することができます。
• ルールは特定の HTTP コンポーネントをテストします。たとえば、アクティブ・テストは HTTP クエリ・パラメータを変更したり、パッシブ・テストはレスポンス・ヘッダーを検査したりします。
• スキャナは各 HTTP コンポーネントタイプのルールのリストを保持します。ここで使用する用語は、エンティティタイプです。
• 各ルールのリストは、ルール範囲と呼ばれる 1 つまたは 2 つのサブリストで構成されています。最初の範囲は、互いに並行して実行できるルールのリストです。2 番目の範囲は、連続して実行する必要があるルールのリストです。リストの中には、並列実行可能なルールだけで構成されているものもあるので、1 つの範囲を含んでいます。他のリストは、並列範囲とシリアル範囲の両方を持っています。

スキャナは 1 つのテスト段階で 2 つのパスを実行します。最初に、複数のスレッド (構成で定義されている) で並列実行可能なすべてのルールを実行し、次にシリアルに実行する必要があるすべてのルールを実行するために、シングルスレッドモードに切り替えます。

HTTP コンポーネントのエンティティの危機

エンティティタイプがあるならば、型付け(タイプ)するエンティティがあるはずだと、あなたは推測して - そしてそれは正しい - いるかもしれません。では、エンティティとは何でしょうか。HTTP コンポーネント、またはエンティティタイプは、テストできる HTTP セッションの個々の部分 (リクエストとレスポンスのペア) のいずれかになります。ホスト、パス、ディレクトリー、パラメータ、クッキー、リクエスト、レスポンスなどはすべてエンティティタイプです。

スキャナがリクエストとレスポンスのセッションを収集すると、関連するエンティティを抽出します。したがって、エンティティとは特定のセッションにおけるエンティティタイプの特定のインスタンスです。また、脆弱性をテストするコンポーネントであるため、セキュリティエンティティとも呼ばれています。HTTP トラフィックを収集して分析する際に、探索フェーズでエンティティを生成します。

「エンティティがたくさんあるじゃないか！」と思うかもしれません。そして、実行するテストの数も多く、それぞれが独自のルールのリストを持っています。その通りです。最適化がなければ、何千万ものテストを実行することになり、その多くは何度も同じ問題を見つけることになります。なぜでしょうか。 それは、AppScan が識別するリクエスト・レスポンス・セッションは多数ありますが、同じサーバー側のコードに起因する大きなグループが存在するからです。

では、最適化にはどのようなものがあるのでしょうか。いくつかのタイプがあり、その多くは何らかの方法で設定や影響を与えることができます。私たちは DOM の類似性と DOM の冗長性を利用して、リクエストとレスポンスのセッションのセット、あるいはページ全体が同じサーバーサイドのコードに由来するかどうかを判断します。そして、代表的なものを選んでテストし、残りのものは無視します。冗長性のチューニング設定は、エンティティの数にも影響を与えます。テストで使用する HTTP コンポーネントの最適なセットを選ぶために行うヒューリスティックや比較は他にもあります。それは、セキュリティエンティティを作成することです。

これは理解しておくべき最初の重要なことです: アプリケーションデータで見ることができるすべての HTTP コンポーネントが、実際のセキュリティエンティティになるわけではありません。繰り返しになりますが、これは最適化のためです。

もう 1 つ理解しておくべき重要なことは、最適化は、設定されたものとは別に、AppScan が十分なデータを収集した場合にのみ実行されるということです。どのくらいの量が十分なのでしょうか。最小限のセッション数で済むこともあれば、最後まで待って可能な限りのセッション数を確保することもあります。「いくつかの最適化は、探索の最後の最後に行われる」ということを覚えていてください。これは、上記の質問のいくつかに答えてくれるので重要なことです。

エレメント単位の視点 (Elementwise)

これで、セキュリティエンティティ、ルールの範囲、テストフェーズの 2 回のパスができました。最初のパスではエンティティを選択し、1 つの範囲にあるすべてのルールを実行し、その後、必要に応じて再度選択し、2 つ目の範囲にあるすべてのルールを実行します。このエンティティとルールの範囲のペアリングをテスト済み要素 (a tested element) と呼びます。エンティティは、ルール範囲が 1 つしかない場合は 1 つのテスト済み要素を、そうでない場合は 2 つのテスト済み要素を提供することができます。最適化、エンティティの種類、そしてアプリケーション内においてそれらが分散しているため、AppScan が探索データ（HTTP コンポーネント）から取得するテスト済み要素の数を事前に計算することはほぼ不可能です。

これで、テストされた要素が DAST スキャンで何を表し、何を意味するのかを理解したので、進捗状況の問題に入ることができます。スキャナは、完了したルール範囲をカウントオフします。これが進捗の表現です。

AppScan がテスト済み要素を生成する方法（探索中）について少し説明しましたが、他にもオプションがあります。エンティティは、手動での探索をインポートする際にも生成されます。スキャナがシーケンスを処理すると、エンティティが 2 ステップで生成されます。AppScan は一部のエンティティを最適化せずにインポート時に生成します。AppScan は残りの部分を最適化しようとしてインポートの最後に生成されます。

詳細はこちら

AppScan の技術力の詳細をお知りになりたい場合は、是非デモの要望など、お問い合わせ下さい。