第2回WSA研で「Webアプリケーションテストを用いたSQLクエリのホワイトリスト自動作成」について発表してきました
こちらのエントリは第2回Web System Architecture研究会の予稿です．
著者
1. はじめに
Webアプリケーションの脆弱性を利用した攻撃は後を絶たず，Webサービスが保有する機密情報を漏洩させるようなセキュリティインシデントが発生している． このような攻撃は，Webアプリケーションが利用するデータベースに対して不正クエリを発行し実行することで行われ，1つの不正クエリの実行が大規模な情報漏洩を引き起こす可能性がある． そのため，不正クエリをデータベースで実行される前に検知し，実行を停止する対策が必要となる． しかし，仕様変更により頻繁にWebアプリケーションの改修が行われるWebサービスにおいて，不正クエリの対策を導入することは機密情報を保護するために重要であるが，対策の導入によって開発やサービスの運営に影響を与えることは本末転倒となるため避けたい． そのため，対策導入時には，開発プロセスやシステム構成への影響を考慮する必要がある． また，Webサービスの実装には，RubyやPHPなどの様々なプログラミング言語が用いられることから，Webアプリケーションの実装に依存せず汎用的に利用できる不正クエリへの対策が求められている．
本研究では，開発プロセスやシステム構成への影響を考慮し，Webアプリケーションの実装に依存せずに，データベースに発行される不正クエリを検知する手法の検討を行う．
2. Webアプリケーションが利用するデータベースへの不正クエリ検知の課題
Webアプリケーションが利用するデータベースへの不正クエリ検知の課題について整理する．
2.1 不正検知と異常検知
ネットワークの攻撃検知手法として，不正検知や異常検知が一般的に利用される． 不正検知は，既知の不正をパターンを定義し，パターンと一致したものを不正とみなすため，未知の不正パターンを検知することができないという特性がある． 不正検知の方法の一つとして，既知の不正パターンを表すブラックリストを作成し，パターンマッチングにより不正を検知する方法がある． この方法には，不正パターンが膨大となるため，ブラックリストの作成が困難となる課題があり，たとえ全ての既知の不正パターンを定義することができたとしても，未知の不正パターンを検知することができない． このことから，不正クエリ検知に用いた場合，未知の不正クエリを実行される危険性がある． また，一般的な不正パターンが提供されている場合もあるが，不正パターンの更新は提供者側任せになる． そのため，運用にかかる負担を軽減することができるが，新たな不正パターンが発見された場合の対応が遅れる場合が考えられる．
異常検知は，正常なパターンを定義し，それから外れたものを不正とみなすため，未知の不正パターンを検知することできるという特性がある． 異常検知には，統計的な手法や学習的な手法を用いて，正しい利用状況を表すプロファイルを作成し，収集したデータとプロファイルの差分が大きい場合を不正とみなし検知する方法がある． この方法では，統計的な手法や学習的な手法をプロファイル作成に用いるため，プロファイルの作成に時間がかかるという特性があり，不正クエリ検知のに用いる場合は，プロファイル作成期間中に不正クエリを実行される危険性がある． さらに，利用状況を正確に表現したプロファイルを作成することは難しく，不正なパターンを正常と判断することや正常なパターンを不正と判断されてしまい，不正クエリを検知できず実行されてしまうことや正常なクエリの実行を妨げてしまうことが考えられる． また，異常検知には，前述した方法の他に，正常な利用状況のパターンを表すホワイトリストを作成し，パターンマッチングにより不正を検知する方法がある． この方法を不正クエリ検知に用いる場合，Webアプリケーションが発行するクエリをホワイトリストとして作成する． ホワイトリストには，Webアプリケーションが発行するクエリはユーザ入力によって変化することから，クエリのリテラルをプレースホルダーに置き換えたクエリ構造（クエリダイジェスト）を利用する． この方法は，Webアプリケーションの大規模化や複雑化に伴い，Webアプリケーションが発行するクエリが膨大になることや，Webサービスの仕様変更によるWebアプリケーションが発行するクエリに変化が発生するため，Webアプリケーションが発行するクエリとホワイトリストの整合性を取る必要があり，開発者にかかる負担は増大する傾向がある． しかし，Webアプリケーションが発行するクエリは，Webアプリケーションのソースコードや実際に発行されたクエリから限定することができるため，ホワイトリストを自動で作成する手法が提案されている．
2.2 Webアプリケーションが発行するクエリのホワイトリスト自動作成の課題
従来手法の一つに，Webアプリケーションの稼働時に発行されるクエリを収集し，クエリの構文解析を行いクエリダイジェストに変換することでホワイトリストを自動で作成する手法がある． この手法は，Webアプリケーション稼働時のクエリを利用するので，Webアプリケーションの実装に依存せず，汎用的に利用できる． しかし，クエリを収集しホワイトリストを作成する学習モードと作成されたホワイトリストを利用して不正クエリの検知を行う検知モードがあり，学習モード中は不正クエリを検知することができない． 頻繁な仕様変更によりWebアプリケーションが改修されるWebサービスにおいては，学習モードの頻発により，不正クエリを検知できない期間が増大する傾向がある． この課題の本質は，Webアプリケーション稼働後の不正クエリ検知の即時性であり，この課題を解決するためには，ホワイトリストの作成をWebアプリケーション稼動前に行う必要がある． この他にも，Webアプリケーションのソースコードからクエリ発行処理を解析し，発行されるクエリのパターンを特定しホワイトリストを自動で定義する手法がある． この手法は，ソースコードの解析によりホワイトリストを作成するため，Webアプリケーションの稼動後，即時に不正クエリを検知することができる． しかし，ソースコードの解析を行うことから，解析処理がWebアプリケーションの実装に依存してしまう． Webサービスの実装には，様々なプログラミング言語やオブジェクトリレーショナルマッピング（ORM）が利用されるため，それぞれに対して解析処理を実装することは開発者の負担の増大につながる． そのため，複数のWebサービスを運用している状況下においては，Webアプリケーションの実装に依存せず汎用的に利用できることが重要となる．
3. 提案手法
2章で述べた課題を解決するために，Webサービスの開発プロセスに着目し，自動テスト時にWebアプリケーションから発行されるクエリを用いてホワイトリストを自動作成する手法を提案する． 提案手法は以下の要件を満たす必要がある．
- Webアプリケーションの稼動前にホワイトリストを作成できる
- Webアプリケーションの実装に依存せずホワイトリストを作成できる
- 導入時の開発プロセスへの影響が小さい
- 導入時のシステム構成への影響が小さい
提案手法は，導入時の開発プロセスへの影響を抑えつつ，Webアプリケーションの稼動前にホワイトリストを作成するために，開発プロセスに自動テストが採用されていることを前提として，テスト時に発行されるクエリを利用する． また，システム構成への影響を抑えつつ，Webアプリケーションの実装に依存せずにホワイトリストを作成するために，データベースの前段にデータベースプロキシを配置しクエリの収集を行う．
3.1 自動テストを用いた開発プロセスと提案手法の位置付け
一般的な自動テストを用いた開発プロセスと提案手法を組み込んだ開発プロセスを以下に示す．
一般的な自動テストを用いた開発プロセスについて説明する． まず，開発者はWebアプリケーションの新機能の追加や既存機能の改修を行い，開発を行った部分に対してテストコードの記述を行う． テストコードには，テスト時のWebアプリケーションの動作手順であるテストケースと期待される動作結果を記述する． 次に，自動テストの段階で，テストコードを元に自動でテストを実行し，Webアプリケーションが正常に動作しているかの検証を行う． このとき，テストが失敗した場合は，開発した機能が仕様通りに動作していない，もしくはテストコードに記述したテストケースや動作結果が正しくないことが分かる． この場合，開発者は原因となる箇所を特定し，Webアプリケーションのソースコードかテストコードの修正を行う． テストが成功した場合は，Webアプリケーションは正常に動作しているとみなし，新しいWebアプリケーションのソースコードをサーバーに配置し，運用を開始する．
提案手法を組み込んだ開発プロセスについて説明する． 提案手法は前述した開発プロセスの中の自動テスト時にWebアプリケーションから発行されるクエリを用いてホワイトリストの作成を行う． そして，テスト成功後に，新しいWebアプリケーションのソースコードと作成されたホワイトリストをそれぞれサーバに配置する． このようにすることで，Webアプリケーションが発行するクエリとホワイトリストの整合性を保つことができ，かつ，新しいWebアプリケーションの運用を開始するときには，不正クエリを検知できる状態にすることができる． また，テスト時に自動でホワイトリストが作成されるため，導入時の開発プロセスへの影響は小さくなる．
3.2 提案手法の設計
提案手法によるテスト時のWebアプリケーションが発行するクエリの収集と稼働時の不正クエリの検知には，どちらも同じアーキテクチャを用いる．
上図を用いてテスト時のホワイトリスト作成フローについて説明する． まず，テストが実行されWebアプリケーションからクエリが発行される． 発行されたクエリは，テストの実行を妨げないようにするために，データベースプロキシを通り，そのままデータベースに渡される． このとき，データベースプロキシは通過したクエリを記録しておき，テスト終了後，収集した全てのクエリのリテラルをプレースホルダーに置き換えたクエリダイジェストに変換し，ホワイトリストに登録する． このように，データベースプロキシを用いてクエリの収集を行うことで，Webアプリケーションの実装に依存せずに，ホワイトリストを作成することができる．
上図を用いて不正クエリの検知フローについて説明する． まず，Webアプリケーションがクエリを発行し，それをデータベースプロキシが受け取る． 次に，データベースプロキシが受け取ったクエリをクエリダイジェストに変換しホワイトリストと照合する． ホワイトリストに登録されているクエリの場合は，データベースにクエリを渡し実行する． ホワイトリストに登録されていないクエリ場合は，データベースにクエリを渡さず実行を停止する．
3.3 提案手法の考察
提案手法にが作成したホワイトリストによって検知できるクエリについて述べる． 提案手法は，テスト時に，テストコードを元にWebアプリケーションを動作させ，その過程で発行されたクエリを用いてホワイトリストを作成している． そのため，提案手法によって作成されたホワイトリストを用いて検知されるクエリは，テスト時に発行されなかったクエリとなる． このようなクエリには，以下の2つのクエリが含まれると考えられる．
- テストケースの不足によりテスト時に発行されていないクエリ（テストされていないクエリ）
- Webアプリケーションの脆弱性攻撃により発行されたクエリ（不正クエリ）
クエリの内包関係を以下に示す．
上図より，提案手法はテストカバレッジを向上させ，テストされているクエリ領域を拡大し，Webアプリケーションが発行するクエリ領域に近づけることが，不正クエリの検知精度の向上につながると考えられる． また，テストカバレッジを向上させるには，検知されたクエリからテストされていないクエリを抽出し，対応するWebアプリケーションの処理のテストの追加する必要がある． しかし，検知されたクエリからどの処理のテストを追加するかを特定することは難しく，現状，この判断は開発者に任せるしかない．
テストコードを記述することとホワイトリストに手動でクエリを登録していくことによる開発者への負担の差について述べる． テストコードには想定されるWebアプリケーションの動作を記述していくのに対して，ホワイトリストにはWebアプリケーションの動作の過程で発行されるクエリを登録していく． テストコードを記述する場合，開発者はWebアプリケーションの動作を理解するのみで良いが，ホワイトリストにクエリを登録する場合，開発者はWebアプリケーションの動作を理解したうえで，その過程で発行されるクエリを理解しなければならない． そのため，テストコードを記述することの方が開発者に求められるWebアプリケーションの動作の理解度が低いため，開発者への負担は少ないと考えられる．
提案手法で検知できない不正クエリについて述べる． 提案手法によって作成されたホワイトリストには，クエリのリテラルをプレースホルダーに置き換えたクエリダイジェストを登録するため，クエリダイジェストが変化するような不正を検知することはできるが，クエリダイジェストが同一となる不正を検知することができない． 例えば，セッションハイジャックにより，あるユーザのアカウントが乗っ取られてしまい，そのユーザの個人情報を取得するようなクエリを発行される状況が考えられる． この場合，Webアプケーションから発行されるクエリは，ホワイトリストに登録されているクエリダイジェストと同じとなるため，提案手法では検知することができない．
不正クエリ検知の実装について述べる． 不正クエリの検知では，発行されたクエリとホワイトリストの照合処理を行うため，この処理の実装がWebアプリケーションとデータベース間のレイテンシーに影響を与えると予想される． 発行されたクエリに対してホワイトリストを全探索した場合，照合処理の計算量は，ホワイトリストに登録されているクエリダイジェスト数nに対してO(n)となり，Webアプリケーションとデータベース間のレイテンシーは大きいと考えられる． これを避けるために，ホワイトリストをクエリダイジェストをキーとしたハッシュテーブルとして作成し，ホワイトリストの照合処理を行うことで，Webアプリケーションとデータベース間のレイテンシーを抑えることができると考えられる．
4. まとめ
本研究では，Webアプリケーションが利用するデータベースに対しての機密情報を窃取するような不正クエリを防ぐために，開発プロセスに着目し，テスト時にWebアプリケーションが発行するクエリからホワイトリストを作成する手法を検討し，手法の設計について述べた． 今後は，提案手法を実装し，テストカバレッジに対する不正クエリの検知精度の検証や導入によるWebアプリケーションとデータベース間のレイテンシーへの影響の検証などを進めていく． また，今後の課題として，検知されたクエリから追加すべきテストを特定する方法の検討や提案手法で検知できないクエリダイジェストが同一の不正クエリへの対策の検討が挙げられる．
発表スライド
質疑・コメント
- リテラル部分の検知の課題について
- フィクスチャの登録のために発行されるクエリをどうするか
- ホワイトリストのマッチング速度に関して
- クエリダイジェストをキーとしたハッシュを保存することで高速に参照できると考えている
- 検知したクエリを開発者にどうのように指摘するのか
- 検知したクエリのみを見せるのではなく，どのようなWebアプリケーションの処理の過程で発行されたかを一緒に通知できたらいいと考えている
- ORMがデータの大きさによって違うSQLを発行することがあるのでそのような場合どうするか
- 検知精度の検証に利用するWebアプリケーションとして何があるか
- MWSというイベントを紹介していただいた
- テストと検知の関係性をどういう線引きで使っていくか
- 数千行に及ぶSQLをどうするか
- ストアドプロシージャに対してどうしたら良いか
発表を終えて
今回初めてWeb System Architecture研究会に参加させていただいて，様々なフィードバックを得ることができ，今後の研究の足がかりを作ることができたと感じました． 発表では，提案手法の実装や評価の部分ができていなかったため，手法の具体的なイメージがつきづらい内容になってしまった． そのため，今後は提案手法を実装と評価方法の調査し，テストカバレッジに対してのホワイトリストの網羅性や検知精度（false-positive, false-negative）の検証を行うことから進めていきたいと思います． また，データベース保護に関する方法として，データベースにデータを暗号化して保存するような方法なども考えられるため，それらと比較して提案手法にどのような優位性があるのかを調査・整理していきたいと思っています．
最後に，僕の発表にフィードバックをしていただき，また，刺激的な発表をしてくださった皆さん，ありがとうございました！
参考文献
- D Kar, S Panigrahi, Prevention of SQL Injection attack using query transformation and hashing, Advance Computing Conference (IACC), 2013.
- Valeur, D. Mutz and G. Vigna, A Learning-Based Approach to the Detection of SQL Attacks In Proceedings of the Conference on Detection of Intrusions and Malware Vulnerability Assessment (DIMVA), July 2005.
- William G.J. Halfond and Alessandro Orso, AMNESIA: analysis and monitoring for NEutralizing SQL-injection attacks, In Proceedings of the 20th IEEE/ACM international Conference on Automated software engineering (ASE ’05), ACM, New York, NY, USA, 174-183, 2005.
- 藤田 直行, 侵入検知に関する誤検知低減の研究動向, 電子情報通信学会論文誌 B Vol.J89B No.4 pp.402411, 2006.
