情報処理学会研究報告
IPSJ SIG Technical Report

Web アプリケーションテストを用いた SQL クエリの
ホワイトリスト自動作成手法
野村 孔命1,a)

力武 健次1,2

松本 亮介3

概要：Web アプリケーションの脆弱性を利用してデータベースから機密情報を窃取する攻撃が問題になっている．対策として，アプリケーションが発行するクエリを正常なクエリとしてホワイトリストに定義し，リストにないクエリを検知する方法がある．従来のホワイトリスト自動作成手法では，Web サービスのユーザがサービスを利用する過程で発行されるクエリからリストを自動で作成するため，クエリを収集している間は検知が行えない．また，複数の実装の異なるアプリケーションを運用しており，これらに従来手法を適用する場合，それぞれに対して手法の実装が必要となり実装の工数が多い．これらの課題を解決するためには，アプリケーションが稼動する前の段階でアプリケーションの実装に依存せず，ホワイトリ
ストを作成する必要がある．そこで，本稿では，アプリケーション稼動前の動作テスト実行時に発行されるクエリからホワイトリストを作成する手法を提案する．提案手法の評価のため，SQL インジェクション
の脆弱性のあるアプリケーションに提案手法を適用し，SQL インジェクション攻撃を検知できることを確認した．しかし，提案手法はテスト時に発行されたクエリを利用するため，正常なクエリを異常とみなす，
もしくは異常なクエリを正常とみなす誤検知が発生することが懸念される．この誤検知への対策を検討するために，実環境のアプリケーションに提案手法を適用し，誤検知されたクエリの発行元となったアプリ
ケーションの処理を特定することで，誤検知の原因を調査し考察する．

Automatic Whitelist Generation for SQL Queries Using Web
Application Tests
Komei Nomura1,a)Kenji Rikitake1,2

1. はじめに

Ryosuke Matsumoto3

こり得る．これを防ぐには，不正クエリはデータベースで実行される前に検知する必要がある．

Web アプリケーションの脆弱性を利用した攻撃は後を絶不正クエリの検知には，ネットワーク攻撃検知に用いらたない．攻撃によって，Web サービスの個人情報などサーれる不正検知の手法 [13] が応用される [3]．不正クエリのビスの機密情報の漏洩が発生している [5, 7]．このような検知には，ブラックリスト方式とホワイトリスト方式があ

攻撃は，Web アプリケーションの脆弱性を利用して開発者

る [16]．ブラックリスト方式は，既知の不正なパターンをの想定と異なる不正クエリをデータベースで実行すること定義して，パターンマッチングを行い，合致したクエリをで行われる．この際，1 つの不正クエリの実行が大規模な検知する．不正なパターンには，攻撃に利用される特定の情報漏洩を招くことにより，サービスの信頼性の低下が起

SQL の文字列を定義できるため，ブラックリストは，共通の不正なパターンとして，別の Web アプリケーションでも

1

2

3

a)

GMO ペパボ株式会社 ペパボ研究所, Pepabo R&D Institute,
GMO Pepabo, Inc.
力武健次技術士事務所, Kenji Rikitake Professional Engineer’sOﬃce.
さくらインターネット株式会社 さくらインターネット研究所,
SAKURA Research Center, SAKURA Internet Inc.
komei.nomura@pepabo.com

c 2018 Information Processing Society of Japan⃝

利用できる．しかし，不正なパターンの定義には，攻撃に関する膨大な知識が必要であり，開発者の知識の不足による定義漏れが発生することがある．また，全ての不正なパターンを定義できたとしても，リストに定義されていない

1

情報処理学会研究報告
IPSJ SIG Technical Report

未知のパターンを持つ不正クエリを検知できない [11]．一

不正クエリを検知可能な状態にできる．ホワイトリストの方，ホワイトリスト方式は，Web アプリケーションが発行作成に必要なクエリは，データベースの前段にデータベー

するクエリをホワイトリストに定義し，パターンマッチン

スプロキシを配置して収集する．これらの収集したクエリグを行い，定義にないクエリを検知する．この方法では，のリテラルをプレースホルダーに置き換えたクエリ構造を

未知のパターンを持つ不正クエリが発行されたとしても検ホワイトリストに登録する．このように，データベースプ

知できる．しかし，それぞれの Web アプリケーション毎

ロキシでクエリを収集することで，Web アプリケーショに発行されるクエリは異なるため，ホワイトリストはそれンの実装に依存しないホワイトリスト作成を実現する．まぞれの Web アプリケーションに対して定義する必要があた，提案手法では，テスト時のクエリを用いてホワイトリ

る．ブラックリストのみの利用では，未知のパターンを持ストを作成するため，検知されるクエリは，ホワイトリス

つ不正クエリを検知できないため，ホワイトリストを併用

トに載っていないテスト時に発行されなかったクエリであすることで未知のパターンにも対応することができる．

り，これには不正クエリも含まれる．

ホワイトリストの作成には，Web アプリケーションが発

本稿の構成を述べる．2 章では，Web アプリケーション

行するクエリを開発者が手動でリストに登録する方法があが発行するクエリのホワイトリスト作成の課題を整理す

る [8]．しかし，大規模で複雑な Web アプリケーションでる．3 章では，ホワイトリスト作成を組み込んだ開発プロは発行されるクエリ数が膨大となり，開発者が全ての発行セスと提案手法の検知特性について述べた後，提案手法のされるクエリを把握するのは困難である．さらに，Web ア

設計について述べる．4 章で，実験により提案手法の検知

プリケーションが更新されることによって，発行されるク

精度を評価し，5 章で，実環境のクエリログを使った実験

エリは変化する．この発行クエリの変化に対応するため，

により実運用上の課題と考察を述べ，6 章でまとめる．

開発者はホワイトリストを更新しなければならない．これらのことから，この方法は開発者への負担が大きい．開発

2. ホワイトリスト作成の課題者への負担を軽減するために，Web アプリケーションが発

不正クエリを検知するために，Web アプリケーションが行するクエリのホワイトリストを自動で作成する手法が提発行するクエリのホワイトリストを開発者が手動で作成し案されている [4, 18]．しかし，これらの手法は，ユーザのて検知する方法がある [8]．Web アプリケーションが発行

入力によって生じるクエリをホワイトリストの作成に利用するクエリのリテラル値は，ユーザ入力によって変化する

するため，(1)Web アプリケーションが稼働した後即時にことがあるので，ホワイトリストには，クエリのリテラル

不正クエリを検知できないことや，Web アプリケーション

値をプレースホルダーに置き換えたクエリ構造が登録されの実装に依存するため，(2)Web アプリケーションごとにる [1]．そのため，開発者は Web アプリケーションのソー対策の実装が必要となることが課題となる．

スコードから全てのクエリを発行する処理を特定し，発行不正クエリ対策の実施を行う際，サービス運営者は，サーされるクエリのクエリ構造をホワイトリストに登録する．

ビスの開発や運用に支障をきたすことを最小限にしたい．

開発者による手動でのホワイトリストの作成は開発者へ

また，Web サービスの開発には，PHP や Ruby のようなの負担が大きい方法となっている．Web アプリケーショ

様々な言語や Web アプリケーションフレームワークが利ンは開発が進むに伴って大規模化・複雑化するため，Web

用されるため，Web アプリケーションの実装に依存したアプリケーションが発行するクエリ数は増加する．そのた対策は，適用する Web アプリケーションそれぞれに対し

め，開発者が把握しなければならないクエリ数が膨大となて実装が必要となり，工数が多く作業効率が低い．そのたり，ホワイトリストの作成が困難になる．また，開発者は，

め，不正クエリ対策は，Web アプリケーションの実装に依ホワイトリストの検知精度を保つために，Web アプリケー

存しない方法である必要がある．また，不正クエリの検知

ションが発行するクエリの変化に追従してホワイトリスト

漏れや，Web アプリケーションが発行するクエリの誤検知を更新しなければならない．しかし，Web アプリケーショを軽減するために，不正クエリ対策には，Web アプリケー

ンの改修頻度は高く [6]，発行クエリは頻繁に変化するたション稼働後即時に不正クエリを検知でき，かつ稼動直後

め，開発者がホワイトリストを更新しなければならない頻からの高い検知精度が求められる．

度も高い．さらに，Web アプリケーションの実装にはオブ

本研究では，不正クエリ対策の実施による開発者への負ジェクトリレーショナルマッピング（ORM）[15] が利用さ担を軽減するために，開発者が Web アプリケーションの変れる場合があり，開発者は Web アプリケーションが発行更に追従してテストコードを整備する開発プロセスにおいするクエリを意識することが少なくなっている．ORM はて，テスト時に発行されたクエリを用いたホワイトリスト

オブジェクト指向言語におけるオブジェクトとデータベー

自動作成手法を提案する．提案手法では，Web アプリケー

スのレコードを関連づける機能を提供している．これによションが稼働する前のテストの段階にホワイトリスト作成

り，開発者はデータベースのレコードをオブジェクトとを組み込むことで，Web アプリケーション稼働後，即座にして扱えるため，直接 SQL 文を記述することが少なくな

c 2018 Information Processing Society of Japan⃝2

情報処理学会研究報告
IPSJ SIG Technical Report
表 1 Ruby のコードによって発行される SQL クエリの例

Ruby code
SQL query

User.find(1)なったクエリや，改修後に新たに発行されるようになったクエリが，クエリログに含まれるからである．

SELECT * FROM users WHERE(users.id = 1) LIMIT 1

2.2 静的解析を用いたホワイトリスト自動作成
Web アプリケーションのソースコード内のクエリを発る．例えば，Web アプリケーションの実装に Web アプリ

行する処理を解析することで，ホワイトリストを自動で作ケーションフレームワークである Ruby on Rails [9] を用成する手法が提案されている [18]．この手法は Web アプ

いた場合，ORM として ActiveRecord [10] が利用される．

リケーションが稼動する前にホワイトリストを作成できる

ActiveRecord によってデータベースのレコードと Ruby のため，Web アプリケーションが稼動した後，即時に不正

クラスオブジェクトが関連づけられ，開発者は Ruby のクエリを検知できる．一方，この手法では，ソースコード

コードで SQL クエリの発行処理を記述できる．Ruby のの解析処理が，実装に利用されている言語や Web アプリ

コードによって発行される SQL クエリの例を表 1 に示す．

ケーションフレームワークなどに依存するため，適用する

表 1 は，クラスオブジェクト User がデータベースの users

Web アプリケーションそれぞれに対して実装が必要となテーブルのレコードに関連づけられている場合の，Ruby

る．Web サービスの開発には，PHP や Ruby などの様々のコードと SQL クエリの対応関係を示している．このよな実装言語や Web アプリケーションフレームワークが利

うに，ORM を用いた場合，開発者はオブジェクトを用い用されるため，実装方法が異なる複数の Web アプリケーてデータベースからデータを取り出せるので，Web アプ

ションが開発される場合がある．このような状況においリケーションが発行するクエリを把握しづらくなる．しかて，Web アプリケーションの実装に依存する方法は，適用し，手動でのホワイトリストを作成は，ORM の処理を理するそれぞれの Web アプリケーションに対して実装が必

解し発行されるクエリを把握しなければならず，作業量は要となるため，適していない．このことから，実装が異な増えるため，ORM を用いた Web アプリケーション開発にる複数の Web アプリケーションに対してホワイトリスト

適していない．これらのことから，手動でのホワイトリス

を作成する場合は，Web アプリケーションの実装に依存しト作成は開発者への負担が大きくなるので，負担を軽減すない方法をとるべきである．

るための方法が必要となる．

2.1 発行クエリを用いたホワイトリスト自動作成

3. 提案手法
本研究では，ホワイトリスト作成が開発者に与える負荷

Web アプリケーションの稼動時に発行されたクエリをを軽減するために，Web アプリケーションテストを用い収集し，クエリの構文解析を行いクエリ構造に変換する

たホワイトリストの自動作成手法を提案する．提案手法でことで，ホワイトリストを作成する手法が提案されていは，Web アプリケーションの動作テストをテストコード

る [2, 4]．この手法を用いることで，Web アプリケーショとして管理しており，開発者が Web アプリケーションのンの稼動時に自動でホワイトリストを作成することができ

変更に応じてテストコードを整備する開発プロセスにおいる．しかし，この手法には，クエリを収集しホワイトリスて，テスト実行時のクエリを収集し，収集されたクエリかトを作る学習フェーズと，作成したホワイトリストを用い

らホワイトリストを作成する．提案手法は，開発プロセスて検知を行う検知フェーズがあり，学習フェーズ中は不正内のテストの段階でホワイトリストを作成するため，開発

クエリの検知を行うことができない．そのため，Web アプ

プロセスへの影響を抑えつつ，Web アプリケーションが稼

リケーションが稼動した後，即座に不正クエリを検知する

働した後，即時に不正クエリを検知できる．また，データことができない．更新頻度が高い Web アプリケーション

ベースの前段にデータベースプロキシを配置し，クエリのにおいては，頻繁にホワイトリストの再学習を行わなけれ収集を行うことで，Web アプリケーションの実装に依存しばならず，その都度検知を行えない期間が発生してしまう．

ないホワイトリストの作成を実現する．

Web アプリケーション稼働中にホワイトリストを作成する方法は，不正クエリを検知できない期間を生じさせてし3.1 ホワイトリスト作成を組み込んだ開発プロセス

まうため，ホワイトリストの作成は，稼働前に行う必要が提案手法は，自動テストを用いた開発プロセスのテストある．また，この手法では，Web アプリケーション稼働前の段階にホワイトリストを作成する処理を組み込む．開発に，過去に収集しておいたクエリログからホワイトリスト

プロセスにホワイトリストの作成を組み込む方法を示すたを作成できる．しかし，クエリログによるホワイトリスト

めに，自動テストを用いた開発プロセスとホワイトリスト

作成は，Web アプリケーションが改修されたときの発行ク

作成を組み込んだ開発プロセスを図 1 を用いて説明する．

エリの変化に対応できない．これは，Web アプリケーショ

図 1 の自動テストを用いた開発プロセスについて説明すンの改修前には発行されていたが，改修後に発行されなくる．(1) で，開発者は，Web アプリケーションの新機能のc 2018 Information Processing Society of Japan⃝3

情報処理学会研究報告
IPSJ SIG Technical Report

図 2 Web アプリケーションがテスト時と稼働時に発行するクエリの集合の関係
図 1 自動テストを用いた開発プロセスとホワイトリスト作成の組み込み実現できない．さらに，開発者は既存の開発プロセスを変更せずにホワイトリストを作成できるため，提案手法を導開発や既存機能の修正を行う．(2) で，開発者は，開発も入した時の既存の開発プロセスへの影響は小さい．

しくは修正した機能に対して，Web アプリケーションをテ

開発者がテストコードを記述することと，ホワイトリス

ストするときの動作手順であるテストケースと，期待されトを手動で作成することの負担の差について述べる．テス

る動作結果をテストコードに記述する．(3) の自動テスト

トコードには，想定される Web アプリケーションの動作での段階で，開発者は，テストコードを用いて全てのテスト

あるテストケースを記述するのに対して，ホワイトリストを実行し，Web アプリケーションが仕様通りに動作していには，Web アプリケーションが動作の過程で発行するクエ

るかを確認する．このとき，テストが失敗した場合は，開リ構造を登録する．テストコードを記述する場合，テスト

発した機能の動作が仕様通りでない，もしくはテストコー

ケースを導出するために，開発者は Web アプリケーショ

ドの記述，すなわち仕様の定義に誤りがあることを意味

ンの動作を理解しなければならない．一方，ホワイトリス

する．この場合，開発者は，テストが失敗した原因を特定

トを作成する場合，クエリ構造を導出するために，開発者

し，Web アプリケーションのソースコードもしくはテスト

は Web アプリケーションの動作を理解した上で，その動コードを修正する．テストが成功した場合，開発者は，開作の過程で行われるクエリ発行の動作を理解しなければな発した機能が仕様通りに動作しているとみなし，(4) 新し

らない．また，Web アプリケーションの開発に ORM が利い Web アプリケーションのソースコードがサーバに配置

用されている場合，ソースコードから発行されるクエリをし，(5) 運用を開始する．

導出するためには，ORM の動作の理解も必要になる．そ次に，図 1 のホワイトリストの作成を組み込んだ開発プのため，この場合は，開発者がクエリを発行する動作を詳

ロセスについて説明する．図 1 の (3)’ のように，自動テス

細に理解している可能性は低い．これらのことから，テストを実行する工程にホワイトリストを作成する処理を追加

トコードを記述することは，ホワイトリストを手動で作成する．ホワイトリストは，自動テスト実行中に Web アプ

することに比べ，要求される Web アプリケーションの動

リケーションから発行されたクエリを用いて作成する．テ

作に関する知識が少ないため，開発者への負担が小さいとスト成功後に，新しい Web アプリケーションのソースコー

考えられる．

ドと，それに対応したホワイトリストをサーバに配置する．

Web アプリケーションが発行するクエリは，機能追加や

3.2 提案手法の検知特性修正によって変化するため，それに対応してホワイトリス

ホワイトリストによる検知では，Web アプリケーション

トを作成する必要がある．自動テストを用いた開発プロセが稼働時に発行するクエリを正常なクエリとして定義する

スにおいて，テストコードは Web アプリケーションの変が，提案手法はテスト時に発行されたクエリからホワイト

更に応じて整備されるので，テスト時に発行されるクエリ

リストを作成する．そのため，Web アプリケーションがテも，それに応じて変化する．提案手法では，このクエリをスト時と稼働時に発行するクエリの集合の関係が提案手法

ホワイトリスト作成に利用しているので，Web アプリケーの検知特性に影響するので，この関係を図 2 に示す．

ションが稼働中に発行するクエリとホワイトリストの整合図 2 を用いて提案手法の検知特性について説明する．テ

性を保つことができる．また，テストの段階でホワイトリ

スト時の Web アプリケーションの実行パターンであるテストを完全に作成できるので，新しい Web アプリケーショ

ストケースは，Web アプリケーション稼働時の実行パターンが稼働したときには，不正クエリを即座に検知できる状ンの一部でしかないため，テスト時に発行されるクエリは，態にすることができる．この特性は，Web アプリケーショ

Web アプリケーションが発行するクエリの一部しか含んンが稼動した後でホワイトリストの作成を始める方法ではでいない．そのため，開発者が想定するユーザ入力によっ

c 2018 Information Processing Society of Japan⃝4

情報処理学会研究報告
IPSJ SIG Technical Report
表 2 提案手法で検知できないクエリの例
正常なクエリ
SELECT * FROM users LIMIT 30
異常なクエリ

SELECT * FROM users LIMIT 1000て Web アプリケーションが発行する正常なクエリを不正と判断する，False positive が発生する．提案手法では，テ

図 3 提案手法の設計

ストケースを追加することによって，False positive を低減することができるが，テストケース増加による管理の複雑化が懸念されるため，テスト時に発行されなかったクエのテストが終了した後，データベースプロキシは，記録さリを補う方法が必要となる．また，テスト時に発行されるれたクエリのリテラル値をプレースホルダーに置き換え，クエリには，Web アプリケーション稼働時に発行されない

クエリ構造に変換し，ホワイトリストに登録する．このよがテスト時のみ発行されるクエリがある．テスト時のみ発

うに，データベースプロキシを用いてクエリの収集を行う

行されるクエリの例として，テストデータの登録や削除をことで，Web アプリケーションの実装に依存せず，ホワイ

行うクエリが挙げられる．提案手法では，テスト時のみ発トリストを作成できる．

行されるクエリが作成されるホワイトリストに含まれるた

Web アプリケーション稼動時の検知フローについて説明

め，Web アプリケーションが発行しない不正なクエリを不する．図 3 において，まず，Web アプリケーションがユー正と判断できない，False negative が発生する．

ザからの入力を受けクエリを発行する．次に，Web アプリ

ホワイトリストには，クエリのリテラル部分をプレー

ケーションから発行されたクエリをデータベースプロキシ

スホルダーに置き換えたクエリ構造を登録する．例えば，が受け取り，受け取ったクエリをクエリ構造に変換し，ホ「SELECT * FROM users LIMIT 10」は，リテラルであワイトリストと照合する．照合した結果，ホワイトリスト

る「10」をプレースホルダー「?」に置き換え，「SELECTに登録されていた場合は，クエリをデータベースに渡し実* FROM users LIMIT ?」としてホワイトリストに登録す

行する．ホワイトリストに登録されていなかった場合は，る．提案手法は，ホワイトリストにないクエリ構造を持つ開発者に検知したクエリを通知する．

クエリを検知する．そのため，SQL インジェクション攻

不正クエリの検知には，発行されたクエリとホワイトリ

撃 [17] のように，SQL 文を含む文字列をリテラルにインストを照合する処理がある．ホワイトリストの照合処理がジェクションし，クエリ構造を変化させる攻撃は，提案手低速だった場合，データベースプロキシで発行されたクエ法によって検知できる．しかし，提案手法では，数値リテ

リが停滞し，ユーザへのレスポンス時間が増加することがラルの閾値の設定や，文字列リテラルの正規表現による不懸念される．そのため，ホワイトリストの照合処理は高速

正なパターンの定義を行っていないため，クエリ構造が同である必要があり，照合処理の計算量が重要となる．Web

一でリテラル値が不正であるようなクエリを検知すること

アプリケーションから発行されたクエリに対してホワイトができない．提案手法が検知できないクエリの違いの例を

リストを全探索した場合，ホワイトリストの照合処理の計

表 2 に示す．

算量は，ホワイトリストのエントリ数 n に対して O(n) と表 2 に示したクエリは，クエリ構造は同一であるが，なる．これを避けるために，クエリ構造をキーとしたハッLIMIT 句で指定されている数値リテラルが異なる．このシュテーブルとしてホワイトリストを作成し，ハッシュような場合に対応するために，リテラル値の異常を検知す

テーブルを用いて照合することで，探索の計算量を O(1)る方法を検討する必要がある．

に抑えることができる．このことから，提案手法は，ホワ
イトリストのエントリ数に依存せず一定の計算量で，高速3.3 提案手法の設計提案手法では，データベースの前段にデータベースプロ
キシを配置し，テスト時に発行されたクエリの収集と Webに照合処理を行えると考える．

4. 実験

アプリケーション稼働時の不正クエリの検知を行う．テス

提案手法の有効性を確認するために，提案手法によってト時のホワイトリスト作成フローと Web アプリケーショ

作成したホワイトリストの検知精度の評価を行った．ホン稼動時の検知フローを図 3 を用いて説明する．

ワイトリストの検知精度の指標として，False positive とテスト時のホワイトリスト作成フローを説明する．図 3

False negative を利用する．False positive は，開発者が想において，まず，テストが実行され，Web アプリケーショ

定するユーザ入力によって Web アプリケーションが発行すンからデータベースプロキシにクエリが発行される．デー

る正常なクエリを不正と判断することとし，False negative

タベースプロキシは受け取ったクエリをそのままデータ

は，Web アプリケーションが発行し得ない不正なクエリをベースに渡し，この間に中継したクエリを記録する．全て不正と判断できなかったこととする．

c 2018 Information Processing Society of Japan⃝5

情報処理学会研究報告
IPSJ SIG Technical ReportHTTP

表 3 実装メソッドの一覧
URL
操作

GET

articles

全ての article を表示

GET

articles?title=””title で検索して article を表示

POST

articlesarticle を作成

GET

articles/:id

id の article を表示

PATCH

articles/:id

article を更新

DELETE

articles/:id

article を削除• UPDATE ‘articles‘ SET ‘content‘ = ?, ‘updated at‘ =? WHERE ‘articles‘.‘id‘ = ?
• UPDATE ‘articles‘ SET ‘title‘ = ?, ‘updated at‘ = ?
WHERE ‘articles‘.‘id‘ = ?
• UPDATE ‘articles‘ SET ‘title‘ = ?, ‘content‘ = ?, ‘up-

dated at‘ = ? WHERE ‘articles‘.‘id‘ = ?
図 4

False positive として検知されたクエリ

4.1 ホワイトリストの検知精度提案手法によって作成したホワイトリストの検知精度

False positive として誤検知されたクエリは，17 個の正常なを評価するために，実験環境を構築し，False positive とクエリデータの 17.65%である 3 個のクエリであった．誤False negative を測定する実験を行った．

検知されたクエリを図 4 に示す．

実 験 環 境 で は ，デ ー タ ベ ー ス プ ロ キ シ と し て Prox-

図 4 に示すようなクエリがテスト時に発行されなかった

ySQL [12] を採用した．ProxySQL には，受け取ったク

原因は，データベース上にある更新前の article データと，エリを収集しクエリ構造に変換して保存する機能があり，

UPDATE のクエリを実行した後に生じる更新後の article

この機能をホワイトリストの作成に利用した．また，デー

データが同一になっていたことである．このように，更新

タベースには ProxySQL がサポートしている MySQL を採前と更新後でデータが同一となる時，Ruby on Rails で実用し，article テーブルに title カラムと content カラムを作装した Web アプリケーションは UPDATE のクエリを発成した．Web アプリケーションには，Ruby on Rails を用

行しない．しかし，UPDATE のクエリを発行するメソッ

いて，article テーブルの操作を行うメソッドを実装し，全ドは，テスト時に実行されるため，テストカバレッジの算てのメソッドに対してテストを記述した．実装したメソッ出に含まれる．このことから，テストカバレッジが 100%

ドを表 3 に示す．表 3 に示すメソッドの内，title で検索しであっても，テストケースによっては発行されないクエリて article を表示するメソッドには，SQL インジェクショがあり，False positive が発生することがわかった．False

ンの脆弱性を持たせた．

positive を低減するために，テストケースの欠如によって，

ホワイトリストに登録するクエリ構造には，Web アプリ
ケーションのテストを実行した後に，ProxySQL に記録さテスト時に発行されなかったクエリをホワイトリストに補う方法が必要となる．

れたクエリ構造を利用し，エントリ数が 23 個のホワイト

False negative について考察する．実験では，False neg-

リストを作成した．正常なクエリデータとして，ブラウザ

ative は発生しなかったが，3.2 節で述べたように，ホワイ

から手動で，表 3 に示すメソッドを持つ Web アプリケー

トリストにはテスト時のみ発行されるクエリが含まれておションに HTTP リクエストを行い，その間に発行された

り，False negative を発生させる可能性がある．そのため，17 個のクエリを取得した．この正常なクエリデータとホ

ホワイトリストに含まれるテスト時のみ発行されるクエリ

ワイトリストを照合して，誤検知されたクエリをカウントの割合とそのクエリ構造を調査した．調査の結果，ホワイ

し，False positive を算出した．不正なクエリデータとしトリストには，テスト時のみ発行されるクエリが 39.13%て，Web アプリケーションの article を title で検索するメ

含まれていた．これらのクエリ構造の一覧を図 5 に示す．

ソッドに，sqlmap [14] を用いて SQL インジェクション攻提案手法では，図 5 に示すようなクエリ構造を持つクエ撃を含んだ HTTP リクエストを行い，その間に発行されリを検知できないことがわかった．SQL インジェクション

た 265 個のクエリを取得した．この不正なクエリデータと攻撃では，Web アプリケーションが発行するクエリに任意

ホワイトリストを照合して，検知できなかったクエリをカの SQL 文字列をインジェクションし，クエリの実行結果

ウントし，False negative を算出した．

を変更する．そのため，SQL インジェクション攻撃によっ

実験結果は False positive が 17.65%，False negative がて発行されるクエリは，Web アプリケーションが発行する0%となった．実験結果より，False positive は 17.65%発生

クエリに攻撃に利用される特定の SQL 文字列を加えたもしたため，正常なクエリの一部を誤検知することがわかっのである．このようなクエリが上記したクエリ構造と一致た．また，False negative は発生しておらず，SQL インジェする可能性は否定できないが，実験では，False negative がクション攻撃による不正クエリを全て検知できることがわ

発生しなかったことから，このような場合が発生する可能かった．

性は低いと考えられる．

False positive について考察する．表 3 に示す全てのメ
ソッドに対してテストは記述されており，テストカバレッ
ジの算出にも含まれていたが，False positive が発生した．

c 2018 Information Processing Society of Japan
⃝

5. 実環境での評価
4.1 節の実験により，提案手法では False positive と False

6情報処理学会研究報告
IPSJ SIG Technical Report• ROLLBACK• SELECT COUNT(*) FROM ‘articles‘• RELEASE SAVEPOINT active record 1• SAVEPOINT active record 1• SET FOREIGN KEY CHECKS = ?
• SELECT ‘articles‘.* FROM ‘articles‘
ORDER BY ‘articles‘.‘id‘ DESC LIMIT ?
• DELETE FROM ‘articles‘; INSERT INTO
‘articles‘ (‘id‘, ‘title‘, ‘content‘, ‘created at‘, ‘updated at‘) VALUES (?, ?, ?, ?, ?), (?, ?, ?, ?, ?), (?, ?,?, ?, ?);• SELECT @@FOREIGN KEY CHECKS• SELECT @@max allowed packet

図 6 実環境ので発行されたクエリ構造とテスト時に発行されたク

図 5 テスト時のみ発行されるクエリ

エリ構造の関係

らのクエリは，テーブルのデータを全削除するなどのサービスに損害を与えるような操作ではなかったため，False

negative の発生が懸念されることが確認された．実環境に

positive として誤検知された可能性がある．そのため，こ

おいて，これらの誤検知の発生頻度を確認し，実運用上でれらのクエリの発行元となった Web アプリケーションのの課題を考察するために，筆者が所属する GMO ペパボ株

処理を特定することで，検知されたクエリが正常なクエリ式会社が運営する Web サービスのクエリログを用いた実であるかの調査を行った．調査の結果，全てのクエリの発験を行なった．実験では，Web アプリケーションが実環境

行元の Web アプリケーションの処理を特定できたため，こで稼働している間に発行するクエリと，テスト時に発行す

れらのクエリは全て False positive として誤検知されたクるクエリの集合の関係を調査した．

エリである．また，False positive として誤検知されたク

提案手法は Web アプリケーションの更新に追従してホエリがテスト時に発行されなかった理由は，テストケース

ワイトリストの更新を行うので，実験では，Web アプリ

が実際の利用パターンを網羅できていないことや，クエリ

ケーションが発行するクエリとホワイトリストの整合性をの発行処理の実行がテスト時のみ省略されていたことであ取る必要がある．実験対象の Web アプリケーションは 1

る．また，実験に利用したクエリログは休日に発行された

営業日に複数回の更新が行われ発行クエリに変化が生じる

クエリを記録したものであったため，サービスの運用者がため，休日で Web アプリケーションの更新が行われてい手動で実行するクエリは含まれなかった．

ない 2019 年 1 月 12 日から 2019 年 1 月 14 日の 3 日分の本実験から，提案手法ではテストケースの不足などにクエリログを取得した．クエリログには 172086 個のクエより False positive が発生することが確認された．False

リが含まれ，クエリ数は膨大であるため，実験では 66 個

positive への対処として，ホワイトリストによる検知をテーのクエリ構造に変換して利用した．また，テスト時に発行

ブル単位で限定的に適用することが挙げられる．本研究のされるクエリの収集には，実環境で稼働している Web ア

目的は，データベース上の機密情報の窃取や改竄を防ぐこ

プリケーションとの対応を取るために，クエリログの取得となので，全てのテーブルに対してホワイトリストによる開始日の前日である 2019 年 1 月 11 日時点の Web アプリ

検知を適用する必要はないと考える．そのため，機密情報

ケーションを利用した．テスト時に発行されるクエリ数はが保管されたテーブルに対してはホワイトリストによる検11514 個であり，これを 99 個のクエリ構造数に変換して実知を適用し，その他のテーブルには適用しないなど，テー験に利用した．実環境で発行されたクエリ構造とテスト時

ブル単位でホワイトリストの利用の有無を選択することに発行されたクエリ構造を比較し，図 6 に示すクエリ構造

で，検知対象となるクエリを削減できる．その結果，Falseの集合の関係を求めた．

positive となるクエリの総数を削減できると考える．しか図 6 より，実環境で発行されたクエリ構造とテスト時にし，この方法だけでは，False positive を完全に排除するこ発行されたクエリ構造の総数は 119 個であった．この内，とはできないので，ホワイトリストにテストケースの不足

46 個のクエリ構造が実環境とテストの両方で発行されたクによって登録できなかったクエリを補う方法も別途必要とエリとして観測され，提案手法はこれらのクエリを正常な考える．

クエリと判断する．

図 6 において，テストでは発行されたが実環境では発行

図 6 において，実環境でのみ発行された 20 個のクエリ構されなかった 53 個のクエリ構造について考察する．提案造について考察する．提案手法はこれらのクエリ構造に一手法において，これらのクエリ構造はホワイトリストに登致するクエリを不正クエリとして検知する．しかし，これ録されているが検知に利用されない．これらのクエリには

c 2018 Information Processing Society of Japan⃝7

情報処理学会研究報告
IPSJ SIG Technical Report

2 種類のクエリが含まれていた．1 種類目は，実験に利用しに，ホワイトリストに不足しているクエリを補う方法の検たクエリログの期間に利用されていない Web アプリケー

討が挙げられる．また，今後は，ホワイトリストによる検ションの機能があったことによって，実環境では発行され知を機密情報が保管されたテーブルに限定した場合の検知なかった正常なクエリである．2 種類目は，テスト時のみ精度の評価や，ブラックリストとホワイトリストを併用し発行され，Web アプリケーション稼働時には発行され得なた場合の検知精度の評価を行う．

いクエリである．このようなクエリは False negative を引き起こす可能性があり，これらのクエリには，テーブルの参考文献

データを全て削除するなどのサービスに損害を与えるもの[1]が含まれていた．
本実験から，提案手法ではテスト時のみ発行されるクエリによる False negative が確認された．この問題に対して[2]

は，ホワイトリストのみではなく，ブラックリストを併用
し多層的に対処する必要があると考える．ブラックリストには，機密情報が保管されているテーブルの全件取得や全[3]件削除など，予め想定される不正クエリを定義する．この
ブラックリストと提案手法で作成したホワイトリストを併[4]用することで，ホワイトリストで検知できない不正クエリをブラックリストによって検知できると考える．また，ブラックリストが検知できなかった不正クエリをホワイトリ[5]

ストで検知できる場合も考えられる．そのため，ブラック
リストとホワイトリストを併用し多層的に対処することで，[6]

相補的に不正クエリの検知漏れを低減できると考える．

6. まとめ[7]

本稿では，ホワイトリスト作成が与える開発者への負荷を軽減するために，開発プロセスのテストに着目し，テス
ト時に発行されるクエリを用いてホワイトリストを自動で[8]作成する手法を提案した．提案手法は，開発プロセスにホワイトリストの作成を組み込むことで，開発者への負荷を軽減しながら，Web アプリケーションが稼働した直後からの不正クエリの検知を実現する．また，提案手法は，デー
タベースプロキシでホワイトリスト作成に必要なクエリを収集するため，Web アプリケーションの実装に依存しな
い．このことから，実装が異なる複数の Web アプリケー
ションそれぞれに対して，ホワイトリストを作成する場合

[9]
[10]
[11]
[12]
[13]

に適している．
実環境のクエリログを使った実験から，提案手法では，

[14]
[15]

テストケースの不足により False positive が発生すること
や，テスト時のみ発行されるクエリによる False negative[16]の発生が確認された．False positive に関しては，ホワイト[17]

リストによる検知を適用するテーブルを機密情報が保管されたテーブルに限定することで，検知対象となるクエリを削減し，結果として誤検知されるクエリ数を削減できると考察した．また，False negative に関しては，ブラックリ
ストに予め想定される不正クエリを定義し，ブラックリス
トとホワイトリストを用いて多層的に検知を行うことで，[18]

D. Kar and S. Panigrahi, ”Prevention of SQL Injection attack using query transformation and hashing”,
Advance Computing Conference (IACC), 2013 IEEE
Third International, pp.1317-1323, May, 2013.
F. José, V. Marco and M. Henrique, ”Detecting malicious SQL”, International Conference on Trust, Privacy and Security in Digital Business, Vol.4657, pp.259268, 2007.
F. S. Rietta, ”Application layer intrusion detection for
SQL injection”, Proceedings of the 44th Annual Southeast Regional Conference, pp.531-536, Mar, 2006.
F. Valeur, D. Mutz and G. Vigna, ”A learning-based approach to the detection of SQL attacks”, International
Conference on Detection of Intrusions and Malware,and Vulnerability Assessment, pp.123-140, 2005.
IT Security Center, Information-technology promotion
agency (IPA), How to Secure your Website Fifth edition, Apr, 2011.
J. Mehdi, ”Some Trends in Web Application Development”, Future of Software Engineering, 2007, FOSE
’07, pp.199-213, Jun, 2007.
J. Rahul and S. Pankaj, ”A survey on web application
vulnerabilities (SQLIA, XSS) exploitation and security
engine for SQL injection” 2012 International Conference on Communication Systems and Network Technologies, pp.453-458, May, 2012.
K. Kemalis and T. Tzouramanis, ”SQL-IDS: aspecification-based approach for SQL-injection detection”, Proceedings of the 2008 ACM symposium on Applied computing, pp.2153-2158, Mar, 2008.
M. Bächle and P. Kirchberg, ”Ruby on rails”, IEEE Software, pp.105-108, Nov, 2007.
M. Fowler, Patterns of enterprise application architecture, pp.147-150, 2002.
M. Ofer, and S. Amichai, ”SQL injection signatures evasion”, Imperva, Inc. White paper, Apr, 2004.
ProxySQL, http://www.proxysql.com/.
S. Axelsson, ”Intrusion detection systems: A survey andtaxonomy”, Technical Report 99-15, Mar, 2000.
sqlmap, http://sqlmap.org/.
S. W. Ambler, ”Mapping objects to relational
databases”, An AmbySoft Inc. White Paper, 2000.
V. Luong, ”Intrusion detection and prevention system:
SQL-injection attacks”, Master’s Projects. 16, 2010.
W. G. Halfond and A. Orso, ”A Classification of SQL
Injection Attacks and Countermeasures”, Proceedings ofthe IEEE International Symposium on Secure Software
Engineering, Vol.1, pp.13-15, 2006.
W. G. Halfond and A. Orso, ”AMNESIA: analysis
and monitoring for NEutralizing SQL-injection attacks”,
Proceedings of the 20th IEEE/ACM international Conference on Automated Software Engineering, pp.174183, Nov, 2005.

不正クエリの検知漏れを削減できると考察した．
今後の課題としては，False positive の根本解決のため

c 2018 Information Processing Society of Japan⃝

8