本シリーズのコラムでは、脆弱性診断ツールAppScan Standard(以下「AppScan」という)の機能について紹介します。今回は「検出ロジック」について解説いたします。

一般的に脆弱性診断では想定外のデータをアプリケーションに渡し、どのような応答を返すかによって脆弱性の有無を判断します。サーバーやネットワーク機器にある既知の脆弱性を検出する場合、決まったテストパケットを送信し、脆弱性があるかどうかを特定の応答の有無で判断します。一方、Webアプリケーションはその仕様に依存して、様々なレスポンスを返します。このため、決まったテストリクエストとレスポンスだけでWebアプリケーションの脆弱性の有無を判断することは困難です。そこで、AppScanでは、脆弱性の種類に応じて、4つの検出ロジックのいずれかで脆弱性を発見します。

＜目次＞

探査時のレスポンス中に含まれる文字列を検索

探査時のレスポンスに機密情報が含まれていないか、リスクを低減させるヘッダーの確認といったレスポンス中にリスクの原因や低減につながるとなるものが含まれていないかなど文字列検索を行い、脆弱性の有無を判断します。
このテスト手法は、クレジットカード番号やパスワードの漏洩、不適切なヘッダーなどの問題を検出するために使用されています。

テストリクエストのレスポンス中に含まれる文字列を検索

リクエストで送信されるパラメーター・Cookieなどをテストパターンに書き換え、テストリクエストを送信し、レスポンス中に脆弱性があることを示す文字列が含まれているかどうかを検索して、脆弱性の有無を確認します。この方法は主にクロスサイト・スクリプティングやパス・トラバーサル、SQLインジェクションなど多くの脆弱性を検出するために使用されています。

複数のテストリクエストを送信し、レスポンスの比較

リクエストで送信されるパラメーター・Cookieなどをテストパターンに置き換え、テストリクエストを送信します。その際、複数のテストパターンに置き換えたテストリクエストを送信し、各テストパターンで置き換えたテストリクエストに対するレスポンスに想定される違いがあるかどうかで、脆弱性の有無を判断します。
例えば、以下のようなSQL文をアプリケーションで実行しているとします。
 
SELECT * FROM ITEM_TABLE WHERE ITEM_ID = '<入力値>';
 
このアプリケーションは上記SQL文の結果をレスポンスに出力するものとします。
この処理にSQLインジェクションの脆弱性がある場合、入力に「<探査時のデータ>' and 'a'='a」を入力すると、上記SQL文は以下のようになります。
 
SELECT * FROM ITEM_TABLE WHERE ITEM_ID = '<探査時のデータ>' and 'a'='a';
 
これは探査時に実行されるSQL文と同じ結果となり、レスポンスも探査時と同じものとなります。また、入力に「<探査時のデータ>' and 'a'='b」を入力すると、実行されるSQL文は以下になります。
 
SELECT * FROM ITEM_TABLE WHERE ITEM_ID = '<探査時のデータ>' and 'a'='b';
 
このSQL文の条件は必ず偽となり、探査時に実行されるSQL文と異なる結果をもたらします。この結果、レスポンスは探査時と異なります。
しかし、SQLインジェクションの脆弱性がない場合、それぞれ、SQL文は以下のようになります。
 
SELECT * FROM ITEM_TABLE WHERE ITEM_ID = '<探査時のデータ>'' and ''a''=''a';
SELECT * FROM ITEM_TABLE WHERE ITEM_ID = '<探査時のデータ>'' and ''a''=''b';
 
ともに探査時と異なる結果となります。
このように脆弱性がある場合とない場合で、同じデータを送信しても、レスポンスが異なるため、これを利用して脆弱性の有無を判断します。
複数のテストリクエストのレスポンスが想定通りに返ってきた時に、脆弱性があると判断します。AppScanではレスポンスの差異の判定を完全一致ではなく、95％以上一致している場合、同じものと判断しています。このため、レスポンスサイズが小さい場合、同じようなレスポンスでも、95％以下の一致率であれば、異なると誤って判断することがあります。この結果、想定通りのレスポンスであると、脆弱性がなくても脆弱性を検出することがあるため、レスポンスの内容を必ず確認する必要があります。
この方法はブラインドSQLインジェクション、ブラインドLDAPインジェクションなどの脆弱性を検出するために使用されています。

サーバーが通信を行うかどうかの確認

このテストを実施すると、脆弱性がある場合、アプリケーションが外部に通信パケットを送信します。このテスト手法では大きく分けるとポートリスナーテストとDNSを利用したテストという2つの手法があります。
ポートリスナーテストでは診断対象から、診断元（AppScanをインストールしたPC）への通信パケットを送信し、送信されたパケットを診断元が受信するかどうかで脆弱性の有無を判断します。このテストでは、アプリケーションから診断元へ直接通信ができる必要があります。
DNSを利用したテストでは診断対象から、名前解決要求を送信させ、DNSサーバーがそれを受け取ったかどうかで脆弱性の有無を判断します。このテストでは診断対象と診断元が直接通信できなくても、脆弱性を検出できます。しかし、DNS名前解決要求が発生すれば、脆弱性があると判断するため、脆弱性がない場合でも、IPSやWAFなどが名前解決を行うと脆弱性として検出することがあります。
この方法はSSRF、OSコマンドインジェクションなどの脆弱性を検出するために使用されています。
 
以上のようなそれぞれの脆弱性に応じた手法を用いることで、AppScanは脆弱性を検出しています。しかし、検出された脆弱性がすべて存在しているわけではないため、検出ロジックに応じて、精査を行う必要があります。例えば、「複数のテストリクエストを送信し、レスポンスの比較」のテストによるものであれば、たまたま想定通りのレスポンスであったかを確認するため、複数回再テストを実施し、検出し続けるかどうかで、脆弱性の有無を判断するといったことが必要となります。
AppScanの結果をそのまま鵜呑みにしてすべての脆弱性の対応を行おうとするのではなく、結果を精査し、必要なものだけを対応するようにすることを推奨します。

今回のコラムではAppScanの検出ロジックについて説明しました。

他にどのような機能があるのか知りたい、実際に操作して使用感を確かめたいなど、ご興味・ご関心をお持ちになられた方は、AppScan評価版のご提供やハンズオンセミナーも開催しておりますので、こちら【お問い合わせ】よりお気軽にお問合せください。

脆弱性コラム「サイト脆弱性をチェックしよう！」についてはこちらからご確認ください。