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

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

阿部 博3,5

菅野 哲3,5

力武 健次1,2

松本 亮介1,4

概要：
Web アプリケーションの脆弱性を利用してデータベースから機密情報を窃取する攻撃が問題になっている．対策として，クエリのホワイトリストによる検知があるが，大規模なアプリケーションにおいてはク
エリパターンが膨大であり，開発者によるリストの手動作成が困難なため，リストの自動作成手法が利用される．しかし，従来のホワイトリスト自動作成手法には，ユーザが Web サービスを利用することによって，発行されるクエリを収集するのに時間がかかり検知の即時性が低い課題や，アプリケーション毎に異なる実装を必要とし汎用性が低い課題がある．本稿では，アプリケーションの動作テスト実行時の発行ク
エリからホワイトリストを作成する手法を提案する．提案手法はテスト時の発行クエリを使いアプリケー
ションの実装に依存せず作成できるため，検知の即時性や汎用性は向上する．

Automatic Whitelist Generation for SQL Queries Using Web
Application Tests
Komei Nomura1,a)Hiroshi Abe3,5Satoru Kanno3,5

Kenji Rikitake1,2

Ryosuke Matsumoto1,4

Abstract:
Stealing confidential information of the database has became a serious vulnerability issue of Web applications. Defining the whitelist of SQL queries issued by the Web application is a countermeasure to detect theattack. For large-scale Web applications, automated generation of the whitelist is conducted since manually
defining a large number of the query patterns is impractical for the developers. Conventional methods forthe automated generation are unable to detect the attacks immediately due to the long requiring time ofcollecting legitmate queries and require the application-specific implementations which reduce the versatilityof the methods. In this paper, we propose a method to automatically generate a whitelist using issued queries
during Web application tests. Our proposed method uses the generated queries during the application tests
and does not depend on the specific application, which results in improved timeliness against the attacks andversatility for the multiple applications.

1. はじめに特有の機密情報を窃取するセキュリティインシデントが発生している [13]．このような攻撃は，Web アプリケーショ

Web アプリケーションの脆弱性を利用した攻撃は後をンの脆弱性を利用して開発者の想定と異なる不正クエリを絶たず [12]，Web サービスが保有する個人情報やサービス

データベースで実行することによって行われる．また，1
つの不正クエリの実行が大規模な情報漏洩につながること

1

2
3
4
5
a)

GMO ペパボ株式会社 ペパボ研究所, Pepabo R&D Institute,
GMO Pepabo, Inc.
力武健次技術士事務所, Kenji Rikitake Professional.
ココン株式会社, Cocon, Inc.
さくらインターネット株式会社, SAKURA Internet, Inc.
株式会社レピダム, Lepidum Co. Ltd.
komei.nomura@pepabo.com

c 2018 Information Processing Society of Japan⃝もあり，サービスの信頼性低下を招いてしまう．そのため，
不正クエリはデータベースで実行される前に検知する必要がある．
不正クエリの検知には，ネットワーク攻撃検知に用いら1

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

れる不正検知 [15] が応用可能である [8]．不正検知には，ブ

自動作成手法を提案する．ホワイトリストには，クエリのラックリスト方式とホワイトリスト方式がある．ブラック

リテラル部分をプレースホルダーに置き換えたクエリ構造

リスト方式は，既知の不正なパターンを定義して，パターを登録する．提案手法は，Web アプリケーションが稼働

ンマッチングを行い，合致したクエリを検知する．ブラッ

する前のテストの段階においてホワイトリストを自動作成

クリストは，別の Web アプリケーションでも利用できる．

することで，Web アプリケーションが稼働した後，即時にしかし，パターンの定義に必要な事前知識が膨大であり，

不正クエリを検知可能な状態にできる．また，ホワイトリ

全ての既知の不正クエリのパターンを定義できたとしてストの作成に必要なクエリは，データベースの前段にデーも，リストに定義されていない想定外の不正クエリを検知

タベースプロキシを配置することで収集し，Web アプリ

できない．一方で，ホワイトリスト方式は，Web アプリ

ケーションの実装に依存しないホワイトリスト作成を実現

ケーションが発行するクエリをホワイトリストに定義し，する．提案手法で検知されるクエリは，テスト時に発行さパターンマッチングを行い，定義にないクエリを検知する．

れなかったクエリ，もしくは不正クエリである．

この方法は，想定外の不正クエリが発行されたとしても検本論文では，False positive は，開発者が想定するユー知できる．しかし，Web アプリケーション毎に発行される

ザ入力によって，Web アプリケーションが発行するクエ

クエリは異なるため，ホワイトリストはそれぞれに対してリを不正と判断した割合とする．また，False negative は，定義する必要がある．本研究では，機密情報の保護を目的

Web アプリケーションの脆弱性攻撃によって発行される，としており，不正クエリの検知漏れを許容できないため，開発者の想定外のクエリを不正と判断できなかった割合とホワイトリスト方式に着目した．

する．実験において，Web アプリケーションにブラウザか

不正クエリを検知するために，Web アプリケーション

ら HTTP リクエストを与えた時に発行された正常なクエが発行するクエリのホワイトリストを開発者が手動で作成

リデータと，SQL インジェクション攻撃によって発行されする方法がある [6]．しかし，大規模で複雑な Web アプリ

た不正なクエリデータを用いて，ホワイトリストの False

ケーションでは発行されるクエリ数が膨大となり，開発者

positive と False negative を計測し提案手法を評価する．

が全ての発行されるクエリを把握するのは困難である．さ

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

らに，作成したホワイトリストは，Web アプリケーションが発行するクエリのホワイトリスト作成の課題を整理すが更新されることによって発行されるクエリが変化するたる．3 章では，ホワイトリスト作成を組み込んだ開発プロ

め，その都度更新しなければならない．そのため，この方セスと提案手法の検知特性について述べ，提案手法の設計

法は開発者への負担が大きい．開発者への負担を軽減するについて述べる．4 章では，実験により，提案手法によってために，Web アプリケーションが発行するクエリのホワイ

作成したホワイトリストの False positive と False negative

トリストを自動で作成する手法が提案されている [11][4]．

を評価し，5 章で考察を述べ，6 章でまとめる．

しかし，これらの手法には，ユーザの入力によって生じる
クエリをホワイトリストの作成に利用するため，Web ア

2. ホワイトリスト作成の課題

プリケーションが稼働した後即時に検知できない課題や，

不正クエリを検知するために，Web アプリケーションがWeb アプリケーションの実装に依存するため，Web アプ

発行するクエリのホワイトリストを開発者が手動で作成しリケーション毎に対策の実装が必要となる課題がある．

て検知する方法がある．ホワイトリストの登録内容として

Web サービスの運営において，不正クエリ対策の実施はは，Web アプリケーションが発行するクエリはユーザ入重要であるが，サービス運営者は，対策導入によって既存力により変化することから，ユーザ入力が含まれるクエリのシステム構成や開発プロセスが変更され，サービスの開のリテラル部分をプレースホルダーに置き換えたクエリ構

発や運用に支障を出すことは避けたい．また，Web サービ

造が用いられる [5]．そのため，開発者は Web アプリケースの開発には，PHP や Ruby のような様々な言語や Web

ションのソースコードから全てのクエリを発行する処理をアプリケーションフレームワークが用いられるため，Web

特定し，発行されるクエリのクエリ構造をホワイトリスト

アプリケーションの実装に依存した対策は複数の実装が必に登録する．

要となる．そのため，不正クエリ対策は，導入時のシステ

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

ム構成や開発プロセスへの影響を抑えつつ，Web アプリの負担が大きい方法となっている．Web アプリケーショ

ケーションの実装に依存せず利用できる必要がある．これ

ンは開発が進むに伴って大規模化・複雑化するため，Webらの要件を満たしながら，高い不正クエリの検知精度が求アプリケーションが発行するクエリ数は増加する．そのためられる．

め，開発者が把握しなければならないクエリ数が膨大とな本研究では，開発者が Web アプリケーションの変更にり，ホワイトリストの作成が困難になる．また，Web アプ

追従してテストコードを整備する開発プロセスにおいて，リケーションの改修頻度は高いため [14]，Web アプリケー

テスト実行時に発行されるクエリを用いたホワイトリスト

ションが発行するクエリは頻繁に変化する．開発者は，ホc 2018 Information Processing Society of Japan⃝2

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

ワイトリストの False positive の増大を防ぐために，発行の段階でホワイトリストを作成しておく必要がある．学習

クエリに変化がある度にホワイトリストを更新しなけれ

フェーズとして，過去に収集しておいたクエリのログからばならないので，開発者への負担は大きい．さらに，Web

ホワイトリストを作成することもできる．しかし，収集しアプリケーションの実装にはオブジェクトリレーショナておいたクエリログには，Web アプリケーション改修に

ルマッピング（ORM）[1] が利用される場合があり，開発

よって新しく発行されるようになったクエリが含まれない者は Web アプリケーションが発行するクエリを意識する

場合や，発行されなくなったクエリが含まれている場合がことが少なくなっている．ORM はオブジェクト指向言語あるため，Web アプリケーションが発行するクエリとホワ

におけるオブジェクトとデータベースのレコードを関連

イトリストの整合性を保つことができない．

づける機能を提供している．これにより，開発者はデータ
ベースのレコードをオブジェクトとして扱えるため，直2.2 静的解析を用いたホワイトリスト自動作成

接 SQL 文を記述することが少なくなる．例えば，Web ア

Web アプリケーションのソースコードからクエリを発行

プリケーションの実装に Web アプリケーションフレーム

する処理を特定し解析することで，ホワイトリストを自動ワークである Ruby on Rails[2] を用いた場合，ORM としで作成する手法が提案されている [4]．この手法は Web アて ActiveRecord[3] が利用される．ActiveRecord によってプリケーションが稼動する前にホワイトリストを作成する

データベースのレコードと Ruby のクラスオブジェクトがことができ，Web アプリケーションが稼動した後，即時に関連づけられ，開発者はクラスオブジェクトを用いてクエ

不正クエリを検知できる．一方で，この手法はソースコー

リの発行処理を記述できる．例えば，クラスオブジェクト

ド内のクエリを発行する処理の解析を行うため，Web ア

User がデータベースの users テーブルのレコードに関連

プリケーションの実装に依存する．Web サービスの開発

づけられている場合，「User.find(1)」と Ruby のコードをには，PHP や Ruby などの様々な実装言語や Web アプリ

記述すると，「SELECT * FROM users WHERE (users.id

ケーションフレームワークが利用されるため，実装方法の= 1) LIMIT 1」というクエリが発行される．このように，異なる複数の Web アプリケーションで利用する場合，実装

ORM を用いた場合，開発者はオブジェクトを用いてデーしなければならない解析器は増大してしまう．そのため，タベースからデータを読み出せるので，Web アプリケー

実装方法の異なる複数の Web アプリケーションで利用すションが発行するクエリを把握しづらくなる．しかし，手るためには，Web アプリケーションの実装に依存しないよ

動でのホワイトリストを作成は，ORM の処理を理解し発うな方法を取るべきである．

行されるクエリを把握しなければならず，作業量が膨大になり ORM を用いた Web アプリケーション開発に適していない．これらのことから，ホワイトリストを手動で作成

3. 提案手法
提案手法は，Web アプリケーションの動作テストをテスすることは開発者への負担が大きい方法となるため，負担

トコードとして管理しており，開発者が Web アプリケーを軽減するための方法が必要となる．

ションの変更に応じてテストコードを整備する開発プロ
セスにおいて，テスト実行時のクエリを収集し，収集され2.1 発行クエリを用いたホワイトリスト自動作成

たクエリからホワイトリストを自動作成する．提案手法に

Web アプリケーションの稼動時に発行されたクエリを収よって，テストの段階でホワイトリストを作成できるため，

集し，クエリの構文解析を行いクエリ構造に変換すること

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

で，ホワイトリストを定義する手法が提案されている [11]．

ンが稼働した後，即時に不正クエリを検知できる．また，この手法を用いることで，Web アプリケーションの稼動

データベースの前段にデータベースプロキシを配置しクエ時に自動でホワイトリストを作成することができる．しかリの収集を行うことで，システム構成への影響を抑えつつ，し，この手法には，クエリを収集しホワイトリストを作る

Web アプリケーションの実装に依存しないホワイトリスト

学習フェーズと，作成したホワイトリストを用いて検知をの作成を実現する．

行う検知フェーズがあり，学習フェーズ中は不正クエリの検知を行うことができない．そのため，Web アプリケー

3.1 ホワイトリスト作成を組み込んだ開発プロセス

ションが稼動した後，即時に不正クエリを検知することが提案手法は，自動テストを用いた開発プロセスの自動テできない．また，更新頻度が高い Web アプリケーション

ストの段階にホワイトリストを作成する処理を組み込む．

においては，頻繁にホワイトリストの再学習を行わなけれ

開発プロセスに提案手法を適用する方法を示すために，自ばならず，その都度検知を行えない期間が発生してしまう．

動テストを採用した開発プロセスと提案手法の位置付けを

これは，Web アプリケーション稼動中にホワイトリストを

図 1 を用いて説明する．

作成していることが原因で発生し，Web アプリケーショ

図 1 の自動テストを用いた開発プロセスについて説明す

ン稼動後即時に不正クエリの検知を行うためには，稼動前

る．(1) で，開発者は，Web アプリケーションの新機能のc 2018 Information Processing Society of Japan⃝3

情報処理学会研究報告
IPSJ SIG Technical Reportの運用を開始するときには，不正クエリを検知できる状態にすることができる．この特性は，Web アプリケーションが稼動した後にホワイトリストを作成する方法では実現できない．また，提案手法は，開発プロセスを変更せずにホワイトリストを作成でき，導入時の既存の開発プロセスへの影響を低減できる．
自動テストを用いた開発プロセスにおいて，テストコー
ドを整備することと，手動でクエリ構造を登録しホワイト
リストを整備することの開発者への負担の差について述べる．テストコードには，想定される Web アプリケーショ
ンの動作であるテストケースを記述するのに対して，ホワ
イトリストには，Web アプリケーションが動作の過程で発行するクエリ構造を登録する．テストコードを書く場合，
図 1 自動テストを用いた Web アプリケーションの開発プロセス

Fig. 1 Web application development process using automatic
testing

開発者は，Web アプリケーションの動作を理解しなければならない．一方で，ホワイトリストを作成する場合，開発者は，Web アプリケーションの動作を理解した上で，その開発や既存機能の修正を行う．(2) で，開発者は，開発も過程で発行されるクエリ発行の動作を理解しなければなら

しくは修正した機能に対して，Web アプリケーションをテない．そのため，テストコードを整備することは，ホワイ

ストするときの動作手順であるテストケースと，期待されトリストを整備することに比べ，要求される Web アプリ

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

ケーションの動作の知識が少ないため，開発者への負担がの段階で，開発者は，テストコードを用いて全てのテスト

小さいと考えられる．

を実行し，Web アプリケーションが仕様通りに動作しているかを確認する．このとき，テストが失敗した場合は，開3.2 提案手法の検知特性

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

提案手法は，テストコードを元に Web アプリケーション

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

を動作させ，その過程で発行されたクエリを用いてホワイする．この場合，開発者は，テストが失敗した原因を特定

トリストを作成する．そのため，提案手法によって作成さし，Web アプリケーションのソースコードもしくはテスト

れたホワイトリストで検知されるクエリは，テスト時に発コードを修正する．テストが成功した場合，開発者は，開行されなかったクエリである．このようなクエリには，テ発した機能は仕様通りに動作しているとみなし，(4) 新し

ストされていないクエリと不正クエリが含まれる．テスト

い Web アプリケーションのソースコードがサーバに配置

されていないクエリは，テストケースの欠如によって，テ

し，(5) 運用を開始する．

スト時に発行されなかったクエリである．不正クエリは，次に，図 1 の提案手法を組み込んだ開発プロセスについWeb アプリケーションの脆弱性を利用した攻撃によって生て説明する．提案手法では，図 1 の (3)’ のように，自動テじる想定外のクエリである．また，ホワイトリストには，ストの実行中に Web アプリケーションから発行されたク

テスト時のみ発行されるクエリも登録される．テスト時のエリを用いて，ホワイトリストを作成する処理を追加する．

み発行されるクエリの例として，動作テストに用いるテス

テスト成功後に，新しい Web アプリケーションのソース

トデータを登録するクエリや，登録したテストデータを削

コードと，それに対応したホワイトリストをサーバに配置除するクエリが挙げられる．図 2 に前述したクエリの内包する．

関係を示す．

Web アプリケーションが発行するクエリは，開発による

図 2 より，提案手法は，テストケースの追加や，テスト機能追加や修正などによって変化するため，ホワイトリス

カバレッジの向上よって，テストされているクエリ領域を

トはクエリの変化に対応する必要がある．自動テストを用拡大し，Web アプリケーションが発行するクエリ領域に近いた開発プロセスでは，テストコードは Web アプリケー

づけることで，ホワイトリストの False positive を低減でションの機能変更に応じて開発者によって整備され，提案きる．このことから，開発者がテストケースを追加するこ

手法はテスト時に発行されるクエリを用いてホワイトリスとで，テストされていないクエリをホワイトリストに登録

トを作成するため，発行クエリに変化があった場合も Web

できるが，テストケース増加による管理の複雑化が懸念さアプリケーションが発行するクエリとホワイトリストの整れる．そのため，テストケースの追加を行わず，ホワイト

合性を保つことができる．また，テストの段階でホワイトリストに不足しているクエリを補う方法の検討が必要であ

リストを作成できるので，新しい Web アプリケーション

る．また，ホワイトリストに登録されたテスト時のみ発行

c 2018 Information Processing Society of Japan⃝4

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

アプリケーション稼働時の不正クエリの検知を行う．テス
ト時のホワイトリスト作成フローと Web アプリケーショ
ン稼動時の検知フローを図 3 を用いて説明する．
テスト時のホワイトリスト作成フローを説明する．図 3において，まず，テストが実行され，Web アプリケーショ
ンからデータベースプロキシにクエリが発行される．デー
タベースプロキシが受け取ったクエリは，テストの実行を妨げないために，そのままデータベースに渡される．このとき，データベースプロキシは通過したクエリを記録しておく．全てのテストが終了した後，データベースプロキシ
図 2 クエリの内包関係に記録されたクエリをクエリ構造に変換し，ホワイトリス

Fig. 2 Relationship of queries

トに登録する．このように，データベースプロキシを用いてクエリの収集を行うことで，Web アプリケーションの実されるクエリは，Web アプリケーションが発行するクエ

装に依存せず，ホワイトリストを作成できる．

リではないため，False negative につながる可能性がある．

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

しかし，Web アプリケーションの脆弱性を利用した攻撃とする．図 3 において，まず，Web アプリケーションがユー

して SQL インジェクション攻撃を想定した場合，SQL 文

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

を含む入力を与えることで Web アプリケーションが発行

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

するクエリに任意の SQL 文をインジェクションするため，シが受け取り，データベースプロキシは，クエリ構造に変テスト時のみ発行されるクエリと発行されたクエリが一致

換し，クエリ構造とホワイトリストの照合を行う．このとする可能性は低いと考えられる．そのため，提案手法は，き，ホワイトリストに登録されていた場合は，Web アプリ

SQL インジェクションによる不正クエリを検知するのに有ケーションから発行されたクエリをデータベースに渡し実効であると考えられる．

行する．ホワイトリストに登録されていなかった場合は，ホワイトリストには，クエリのリテラル部分をプレー

開発者に検知したクエリを通知する．

スホルダーに置き換えたクエリ構造を登録する．例えば，

不正クエリを検知する処理には，発行されたクエリとホ「SELECT * FROM users LIMIT 10」は，リテラルであワイトリストを照合する処理が含まれ，Web アプリケー

る「10」をプレースホルダー「?」に置き換え，「SELECT

ションとデータベース間のレイテンシーの増大が考えられ* FROM users LIMIT ?」としてホワイトリストに登録する．ホワイトリストの照合処理が低速だった場合，データる．提案手法は，ホワイトリストにないクエリ構造を持つ

ベースプロキシで発行されたクエリが停滞し，結果的に，クエリの発行を検知できる．そのため，SQL インジェク

Web アプリケーションのユーザへのレスポンス時間が増大

ション攻撃のように，SQL 文を含む文字列をリテラルにイすることが懸念される．Web アプリケーションから発行

ンジェクションし，クエリ構造を変化させる攻撃は，提案されたクエリに対してホワイトリストを全探索した場合，手法によって検知できる．しかし，提案手法では，数値リ

ホワイトリストの照合処理の計算量は，ホワイトリスト

テラルの閾値の設定や，文字列リテラルの正規表現によるのエントリ数 n に対して O(n) となる．これを避けるため

不正なパターンの定義を行っていないため，クエリ構造がに，ホワイトリストを作成する時に，クエリ構造をキーと同一でリテラル値が不正であるようなクエリを検知するこ

したハッシュテーブルを作成しておき，ハッシュテーブル

とができない．提案手法が検知できないクエリの違いの例

を用いてホワイトリストの照合処理を行うことで，探索のを以下に示す．

計算量は O(1) に抑えられ，Web アプリケーションとデー• 正常 : SELECT * FROM users LIMIT 30

タベース間のレイテンシーの増大を抑制できると考えられ• 異常 : SELECT * FROM users LIMIT 1000

る．このことから，提案手法は，ホワイトリストのエント

上記したクエリは，クエリ構造は同一であるが，LIMIT 句で指定されている数値リテラルが異なる．このような場合に対応するために，リテラル値の異常を検知する方法を検討する必要がある．

リ数に依存せず，リストの照合処理の計算量は一定となる．

4. 実験
提案手法の有効性を確認するために，図 4 に示す実験環
境を構築し，テストカバレッジに対する提案手法によって作

3.3 提案手法の設計成したホワイトリストの False positive と False negative，提案手法では，データベースの前段にデータベースプロ

およびホワイトリストの照合に要する時間の評価を行っキシを配置し，テスト時に発行されたクエリの収集と Webた．ただし，False positive は，開発者が想定するユーザ入c 2018 Information Processing Society of Japan⃝5

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

図 3 提案手法のアーキテクチャ

Fig. 3 Propose method architecture

これらの特性を確認するために，実験では，テストカバ
レッジに対する False positive と False negative を計測した．提案手法はテストカバレッジによってホワイトリスト
図 4 実験環境の構成

Fig. 4 Experimental environmentに登録されるクエリ構造が変化するため，実験では Web ア
プリケーションのテストカバレッジの計測を行った．Web

表 1 実装メソッド一覧

アプリケーションのテストカバレッジの算出には，テスト

Table 1 List of Implementation method

時に実行されたソースコードの行を計測して，行単位での

HTTP

URL

操作内容

カバレッジを算出する SimpleCov[9] を利用した．ホワイ

GET

articles

全ての article を表示

トリストに登録するクエリ構造には，Web アプリケーショ

GET

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

ンのテストを実行した後に，ProxySQL に記録されたクエ

POST

articlesarticle を一つ作成

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

GET

articles/:id

特定の article を表示

PATCH

articles/:id

特定の article を更新

DELETE

articles/:id

特定の article を削除作成した．
正常なクエリデータとして，ブラウザから手動で，表 1に示すメソッドを持つ Web アプリケーションに HTTP リ

力によって，Web アプリケーションが発行するクエリを不クエストを行い，その間に発行された 17 個のクエリを用意

正と判断した割合とする．False negative は，Web アプリ

した．用意した正常なクエリデータとホワイトリストを照ケーションの脆弱性攻撃によって発行される，開発者の想合して，誤検知されたクエリをカウントし，False positive

定外のクエリを不正と判断できなかった割合とする．

を算出した．不正なクエリデータとして，Web アプリケー

実験環境では，データベースプロキシとして ProxySQL[7]ションの article を title で検索するメソッドに，sqlmap[10]を採用した．ProxySQL には，受け取ったクエリを収集しを用いて SQL インジェクション攻撃を含んだ HTTP リク

クエリ構造に変換して保存する機能があり，この機能をホ

エストを行い，その間に Web アプリケーションから発行

ワイトリストの作成に利用した．また，データベースにはされた 265 個のクエリを用意した．用意した不正なクエリ

ProxySQL がサポートしている MySQL を採用し，article

データとホワイトリストを照合して，検知できなかったク

テーブルに title カラムと content カラムを作成した．Web

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

アプリケーションの実装には Ruby on Rails を用いた．表

実験結果はテストカバレッジ 68.97%に対して，False

1 のように，article テーブルに対して，新規作成，データ

positive が 17.65%，False negative が 0%となった．実験結一覧・個別取得，データの更新，データの削除の操作を行果より，False negative は発生しておらず，SQL インジェうメソッドを実装した．また，SQL インジェクションのイ

クション攻撃による不正クエリを全て検知できたことがわ

ンジェクションの脆弱性がある article を title で検索する

かる．また，False positive は 17.65%発生したため，正常メソッドを実装した．

な入力によって Web アプリケーションが発行するクエリの一部を誤検知することがわかった．

4.1 ホワイトリストの False positive と False negative

ホワイトリストに False positive が発生した原因につい3.2 節で述べた提案手法の検知特性から，提案手法は，て考察する．表 1 に示す全てのメソッドに対してテストは

SQL インジェクション攻撃を漏れなく検知できると考えら記述されており，テストカバレッジの算出にも含まれていれる．また，提案手法単体では，全ての Web アプリケー

たが，False positive が発生した．False positive として誤ションが発行するクエリをホワイトリストに登録すること検知されたクエリを以下に示す．

はできないため，False positive が発生すると考えられる．

c 2018 Information Processing Society of Japan⃝• UPDATE ‘articles‘ SET ‘content‘ = ?, ‘updated at‘

6

情報処理学会研究報告
IPSJ SIG Technical Report= ? WHERE ‘articles‘.‘id‘ = ?
• UPDATE ‘articles‘ SET ‘title‘ = ?, ‘updated at‘ = ?
WHERE ‘articles‘.‘id‘ = ?

トリストに False negative が発生しなかったと考えられる．
そのため，提案手法は，SQL インジェクション攻撃によって発行される不正クエリの検知に有効であると考えられる．

• UPDATE ‘articles‘ SET ‘title‘ = ?, ‘content‘ = ?, ‘updated at‘ = ? WHERE ‘articles‘.‘id‘ = ?

4.2 ホワイトリストの照合時間誤検知されたクエリは全て表 1 における PATCH リク

提案手法がホワイトリストのエントリ数に依存せずに，エストを送った時に動作する UPDATE メソッドが発行すリストを照合できることを示すために，不正クエリを判定るクエリであった．これらのクエリが発行されなかった

するソフトウェアを実装し，実験を行なった．実装したソ

原因は，テスト時に UPDATE メソッドが更新しようとしフトウェアでは，クエリのリテラルをプレースホルダーにている article データと，データベース上にある更新前の置き換えたクエリ構造をキーとするハッシュテーブルと

article データが同一になっていたことである．更新前のしてホワイトリストを作成する．また，このソフトウェア

article データと更新しようとしている article データが同は，与えられたクエリをクエリ構造に変換し，これをキー

一の時，Ruby on Rails で実装した Web アプリケーション

としてハッシュテーブルを参照することで，不正クエリをは UPDATE のクエリを発行せずテストは成功する．また，判定する．ホワイトリストのエントリ数に依存せず高速に

UPDATE メソッドの処理はテストカバレッジの算出にも照合できることを示すために，エントリ数 23 個のホワイト含まれる．このことから，テストケースによっては発行さリストとその 100 倍である 2300 個のホワイトリストをそれないクエリがあり，False positive を発生させる原因とれぞれ用意した．ホワイトリストに登録されていないクエなることが確認できた．このようなケースに対応し，False

リは，クエリ構造を文字列としてリストに登録した場合，

positive を低減するために，提案手法によってホワイトリ

全てのエントリを参照するため，エントリ数に対して線形ストに登録されなかったクエリを補う方法が必要となる．

に計算量が増加する．そのため，このクエリを評価対象とホワイトリストに False negative が発生しなかった原因

して用意した．用意したホワイトリストとクエリをソフトについて考察する．実験では，False negative は観測されなウェアに与え，照合に要した時間を計測した．1 回の試行

かったが，3.2 節で述べたように，ホワイトリストにはテス

では µs 単位の小さな値となり，CPU の利用状況が照合時

ト時のみ発行されるクエリが含まれており，False negative間に与える影響が大きく比較ができないため，100 回試行を発生させる可能性がある．そのため，ホワイトリストにし合計時間を ms 単位で比較した．実験は，CPU が Intel

含まれるテスト時のみ発行されるクエリの割合とそのクエ

Core i7 3.3 GHz 2core，メモリが 16 GB の環境で行った．

リ構造の一覧を調査した．調査の結果，ホワイトリスト全

照 合 に 要 し た 合 計 時 間 は ，エ ン ト リ 数 23 個 の 時 に体に対してテスト時のみ発行されるクエリは 39.13%含ま

13.50ms，エントリ数 2300 個の時に 13.05ms であった．

れており，含まれていたクエリの一覧を以下に示す．

この結果から，照合に要した合計時間の差は 0.45ms と小• ROLLBACK

さく，エントリ数がリスト照合に要する時間に与える影響• SELECT COUNT(*) FROM ‘articles‘

は小さいことが確認できた．

• RELEASE SAVEPOINT active record 1• SAVEPOINT active record 1

5. 考察• 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‘, ‘up-とができる．テストコードは開発プロセス内で Web アプ

dated at‘) VALUES (?, ?, ?, ?, ?), (?, ?, ?, ?, ?),リケーションの変更に応じて整備されるため，開発の過程(?, ?, ?, ?, ?);で作成されるホワイトリストは発行されるクエリに変化が• SELECT @@FOREIGN KEY CHECKS

あった場合にも対応できる．また，提案手法はデータベー• SELECT @@max allowed packet

スプロキシでクエリを収集しホワイトリストを作成するた

この結果から，提案手法では，上記したようなクエリ構

め，Web アプリケーションの実装に依存せず，複数の Web造を持つクエリを検知できないことがわかった．しかし，

アプリケーションで共通して利用できる．これらの特性か

SQL インジェクション攻撃は Web アプリケーションが発ら，提案手法は単一の実装で複数の Web アプリケーション

行するクエリに任意の SQL 文字列をインジェクションすに適用でき，かつ提案手法を導入することによる Web サー

ることによって引き起こすため，上記したクエリ構造と一ビスの開発や運用に与える影響は小さいと考えられる．

致する可能性は低いと考えられる．この理由から，ホワイ

c 2018 Information Processing Society of Japan
⃝

4.1 節での実験結果から，提案手法は，SQL インジェク

7

情報処理学会研究報告
IPSJ SIG Technical Reportション攻撃によって発行される不正クエリを検知できるこ

トケースによって発行クエリに変化が生じる場合があるたとが確認された．しかし，全ての実装されたメソッドに対め，ホワイトリストに登録されないクエリが存在し，False

してテストを記述したとしても，メソッドが発行するクエ

positive が発生することが確認された．

リはテストケースによって変化する場合があるため，ホワ

今後の課題としては，False positive を低減するために，

イトリストに登録できないクエリが存在し，正常なクエリ

Web アプリケーションが発行するクエリの内，ホワイトリの一部を誤検知してしまうことが確認された．誤検知されストに登録できなかったクエリを補うための方法や，デー

たクエリは，17 個の正常なクエリデータの 17.65%である 3

タベースにテストデータを登録するようなテスト時のみ個のクエリであった．このことから，より大規模な Web アに発行されるクエリへの対処方法の検討が挙げられる．まプリケーションに提案手法を適用する場合，発行クエリ数

た，今後は，提案手法のホワイトリストを用いた検知の実の増加により，誤検知されるクエリ数は増大すると考えら装を進め，提案手法の導入による Web アプリケーション

れる．この問題を解決するために，Web アプリケーションとデータベース間のレイテンシーへの影響の検証や大規模が発行するクエリの内，ホワイトリストに登録できなかっな Web アプリケーションにおける False positive と False

たクエリを補うための方法の検討が必要である．また，ホnegative の検証を行う．

ワイトリストには，テストデータを登録するクエリのようなテスト時のみ発行されるクエリが含まれる．これらのク

参考文献

エリは，ユーザ入力によって Web アプリケーションから[1]発行されるクエリではなく，テーブルのデータを全て削除するようなクエリが含まれた場合には，攻撃が通り抜けて[2]しまうため，ホワイトリストに含めるべきではない．その[3]

ため，テスト時のみ発行されるクエリへの対処方法の検討が必要である．

[4]

4.2 節の実験結果から，クエリ構造をキーとしたハッシュ
テーブルを用いて，ホワイトリストを表現することで，リストのエントリ数がリストを照合する時間に与える影響は[5]小さいことが確認できた．このことから，大規模な Web
アプリケーションに提案手法を適用した場合も，高速にリストを照合できる．

[6]

提案手法は，ホワイトリストの作成方法の特性と，実験で確認した不正クエリの検知特性やレイテンシーの抑制効
果から，Web サービスの開発や運用への影響を小さく抑え実現できる SQL インジェクション対策として，有効に利用できると考えられる．

6. まとめ
本稿では，Web アプリケーションが利用するデータベー

[7]
[8]

[9]
[10]
[11]

スに発行される不正クエリを検知するために，開発プロセ
スのテストに着目し，テスト時に発行されるクエリを用いて Web アプリケーションが発行するクエリのホワイトリ
ストを自動で作成する手法を提案し，実験により，提案手[12]

法の検知の特性を評価した．提案手法は，開発プロセスに[13]

ホワイトリストの自動作成を組み込むことによって，Web
サービスの開発者と運用者の負荷を低減しつつ，不正クエ
リの検知を行うことができると考えられる．

[14]

実験から，提案手法は SQL インジェクション攻撃によって発行された不正クエリを False negative を発生させず検知できることを確認し，SQL インジェクション攻撃に対して有効に利用できることがわかった．しかし，対象とするメソッドに対してテストを記述していたとしても，テス

c 2018 Information Processing Society of Japan⃝[15]

Ambler Scott W, Mapping objects to relational
databases, White Paper, Ronin International, 2000.
Bächle Michael and Paul Kirchberg, Ruby on rails, IEEEsoftware,pp.105-108, November, 2007.
Fowler Martin, Patterns of enterprise application architecture, pp.147-150, 2002.
Halfond William GJ and Alessandro Orso, AMNESIA:
analysis and monitoring for NEutralizing SQL-injection
attacks, Proceedings of the 20th IEEE/ACM international Conference on Automated software engineering,pp. 174-183, November, 2005.
Kar Debabrata and Suvasini Panigrahi, Prevention of
SQL Injection attack using query transformation andhashing, Advance Computing Conference (IACC), 2013
IEEE 3rd International, pp.1317-1323, May, 2013.
Kemalis Konstantinos and Theodores Tzouramanis,
SQL-IDS: a specification-based approach for SQLinjection detection, Proceedings of the 2008 ACM symposium on Applied computing, pp.2153-2158, March,
2008.
ProxySQL, http://www.proxysql.com/.
Rietta Frank S, Application layer intrusion detection for
SQL injection, Proceedings of the 44th annual Southeast
regional conference, pp.531-536, March, 2006.
SimpleCov, https://github.com/colszowka/simplecov.
sqlmap, http://sqlmap.org/.
Valeur Fredrik, Darren Mutz and Giovanni 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.
IPA 独立行政法人 情報処理推進機構, 安全なウェブサイ
トの作り方 改訂第７版, 3 月 2015.
NPO 日本セキュリティ協会セキュリティ被害調査ワーキ
ンググループ, 長崎県立大学 情報システム学部情報セキュ
リティ学科, 2016 年情報セキュリティインシデントに関する調査報告書 個人情報漏洩編 第 1.2 版, 6 月, 2017.
青井 翔平, 坂本 一憲, 鷲崎 弘宜, 深澤 良彰, DePoT:Web
アプリケーションテストにおけるテストコード自動生成
テスティングフレームワーク, 情報処理学会論文誌 Vol.56
No.3 pp.835–846, 3 月, 2015.
藤田 直行, 侵入検知に関する誤検知低減の研究動向, 電子
情報通信学会論文誌 B Vol.J89–B No.4 pp.402–411, 4 月,
2006.

8