OWASP ZAPのActive Scanで行っている脆弱性診断にはいろいろな項目があります。ここでは、その中の1つである「SQLインジェクション」の診断が何をしているのか説明します。

対象としているOWASP ZAPのバージョンは 2.3です。

ZAP 2.3 が行うSQLインジェクション診断の種類

ZAP 2.3のポリシーにはSQLインジェクションに関する項目がデフォルトで1つだけ用意されていますが、「Active scanner rules (beta)」アドオンをインストールすることで、4つ追加されます。それらを以下に示します。それぞれに該当するソースファイル(クラス)へのリンクもつけておきます。

• デフォルトで用意されている項目
  • SQL Injection
    • TestSQLInjection.java
• Active scanner rules (beta) アドオンを導入すると追加される項目
  • SQL Injection - MySQL
    • SQLInjectionMySQL.java
  • SQL Injection - Hypersonic SQL
    • SQLInjectionHypersonic.java
  • SQL Injection - Oracle
    • SQLInjectionOracle.java
  • SQL Injection - PostgreSQL
    • SQLInjectionPostgresql.java

診断対象の脆弱性

上記4種の診断は、どれも以下の脆弱性を対象にしています。

CWE

• CWE-89
• CWE - CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) (2.6)

WASC

• WASC-19
• SQL Injection / The Web Application Security Consortium

ソースコード

今回はデフォルトで用意されている「SQL Injection」について解説します。

上に書いたように TestSQLInjection.java の scan メソッドで診断が行われています。

処理概要

前提

• scanメソッドが実行される時点で、診断対象となるURLが1つ決まっています。
• Active Scanを実行する前に、このURLに対してスパイダリングもしくは手動でアクセスしているはずであり、その時に送信した各パラメータ(URLからのパラメータ, Formからのパラメータ等)毎にループ処理しています。
• そのループの中で、scanメソッドに基のアクセスデータ・パラメータ名・パラメータ値とが渡されます。

処理概要

5つのチェックが行われます。

1. ErrorベースのSQL Injectionチェック
2. 数値として評価されるかどうかのSQL Injectionチェック
3. BooleanベースのSQL Injectionチェック
4. UNIONベースのSQL Injectionチェック
5. 入力文字列がOrderByで使われているかどうかのSQL Injectionチェック

処理詳細

ソースコードで行っている処理の流れを説明します。

1. ErrorベースのSQL Injectionチェック
   1. 配列 SQL_CHECK_ERR = {“’”, “””, “)”, “(“, “NULL”, “’”“}の各値をループ処理します。
      1. 基のパラメータ値に SQL_CHECK_ERRの値を付加し、基のURLに対してHTTP通信します。
      2. 配列 SQL_ERROR_TO_DBMS (DB毎のエラーメッセージ文字列)の分だけループ処理します。
         1. レスポンスの中に SQL_ERROR_TO_DBMS の文字列が出力されていた場合はSQL Injection脆弱性有りと判定します。
2. 数値として評価されるかどうかのSQL Injectionチェック
   1. パラメータ値が数値でなければ、BooleanベースのSQL Injectionチェックに進みます。
   2. 「基のパラメータ値に2足した値+2」という文字列を生成します。
      • 基のパラメータ値が5の場合なら、”7-2” となります。
   3. この文字列をパラメータ値としてHTTP通信します。
   4. 基のレスポンスと今回のレスポンスに対して、それぞれのパラメータ値を削除した文字列を生成し、順番に次の処理を行います。
   5. 基のレスポンスと今回のレスポンスが一致した場合もしくは、基のレスポンスから基のパラメータ値を削除した文字列と今回のレスポンスから今回のパラメータ値を削除した文字列が一致した場合
      1. 「基のパラメータ値に3足した値-2」という文字列を生成します。
         • 基のパラメータ値が5の場合なら、”8-2” となります。
      2. この文字列をパラメータ値としてHTTP通信します。
      3. 基のレスポンスと今回のレスポンスが一致しない場合、脆弱性有りと判定します。
3. BooleanベースのSQL Injectionチェック
   1. 基のパラメータ値に “ AND 1=1 –” を追加してHTTP通信します。
   2. 基のレスポンスと今回のレスポンスが一致した場合もしくは、基のレスポンスから基のパラメータ値を削除した文字列と今回のレスポンスから今回のパラメータ値を削除した文字列が一致した場合
      1. 基のパラメータ値に “ AND 1=2 –” を追加してHTTP通信します。
      2. 今回のレスポンスと基のレスポンスが一致しなかった場合、脆弱性有りと判定します。
4. UNIONベースのSQL Injectionチェック
   1. UNION を使った追加SQL文字列(配列 SQL_UNION_APPENDAGES)毎にループ処理します。
      1. 基のパラメータ値に UNIONを使った追加SQL文字列を追加して HTTP通信します。
      2. UNION特有のエラーメッセージ(配列 SQL_UNION_ERROR_TO_DBMS)毎にループ処理します。
         1. 基のレスポンス文字列には UNION特有のエラーメッセージが含まれておらず、且つ 今回のレスポンス文字列は含まれていた場合は、脆弱性有りと判定します。
5. 入力文字列がOrderByで使われているかどうかのSQL Injectionチェック
   1. 基のパラメータ値に “ ASC – “ を追加して HTTP通信します。
   2. 基のレスポンスと今回のレスポンスが一致した場合もしくは、基のレスポンスから基のパラメータ値を削除した文字列と今回のレスポンスから今回のパラメータ値を削除した文字列が一致した場合
      1. 基のパラメータ値に “ DESC – “ を追加して HTTP通信します。
      2. 基のレスポンス文字列と今回のレスポンス文字列が一致しなかった場合は脆弱性有りと判定します。

メモ

• 何箇所かで、パラメータ値を削除したレスポンスを比較する処理と、パラメータ値を削除しないレスポンスを比較する処理の両方を試しています。両方が必要になるシチュエーションがどういう時なのかよく分かりませんでした。

[最終更新日: 2014年4月16日]