Vol.2018-CSEC-81 No.24
Vol.2018-IOT-41 No.24
2018/5/18

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

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

力武 健次1,2

松本 亮介1

概要：
データベースの情報を利用して動作する Web アプリケーションでは，入力検証やクエリ発行処理の脆弱性により，開発者の想定していない不正クエリがデータベースに発行され機密情報を窃取される攻撃が発生する．このような攻撃に対して，Web アプリケーションがデータベースに発行するクエリのホワイトリ
ストを作成し不正クエリの検知を行う方法がとられてきたが，Web アプリケーションの大規模化や実装言語の多様化に伴いホワイトリストの作成が難しくなっている．そのため，Web アプリケーション解析や運用時のクエリを用いた学習により生成を用いてホワイトリスト作り，検知する手法が提案されている．しかし，手法が実装言語依存の問題や Web アプリケーションの仕様変更の頻度が高いことによるホワイト
リストの管理が難しい問題がある．本稿では，Web アプリケーションの動作を保証するためのテストがあり，Web アプリケーションの更新に追従してテストの更新が行われる開発プロセスが採用されていることを前提とし，テスト時に発行されるクエリからホワイトリストを自動作成する手法を提案する．Web アプ
リケーションの運用時には作成されたホワイトリストを用いて不正クエリを検知する．提案手法は，Web
アプリケーションの複雑性や実装言語に依存せずにクエリのホワイトリストを自動作成することができ，
新クエリが実装された場合もテストの更新に伴いホワイトリストが更新される．また，検知されたクエリはテストされていないクエリもしくは不正クエリであり，これらを早期に発見することで原因となる Web
アプリケーションの脆弱性が長期化することを防ぐことができる．

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

Ryosuke Matsumoto1

Abstract:
Database-driven Web applications are vulnerable to the attacks by the malicious queries which are not expected by the developers and are not correctly processed due to the incomplete input processing and thequery issuing process. Defining the whitelist of the database queries issued by the Web applications has
been conducted to detect the malicious queries. However, as the Web applications themselves become more
complex and the implementation programming languages become more diverse, the whitelisting approach
becomes more challenging to implement. In this paper, we propose a method to automatically generate awhitelist of database queries from those generated by the Web applications during the testing phase, provided that the application development process includes the operation testing. In the proposed method, themalicious queries are detected using the generated whitelist during the Web application is executed. Our
method can automatically generate the whitelist of the queried regardless of the Web application complexity
and independent of the implementation language and can update the whitelist as the test cases are updated
when new queries are implemented. The detected queries are either untested or malicious and detecting thequeries in the early stage of the attack may help an early removal of the respective Web application defects.

c 2018 Information Processing Society of Japan⃝1

Vol.2018-CSEC-81 No.24
Vol.2018-IOT-41 No.24
2018/5/18

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

1. はじめに様々な言語で実装され，改修が頻繁に行われる Web サー
ビスにおいて，不正クエリへの対策は重要であるが，対策

Web アプリケーションの脆弱性を利用した攻撃は後をを行うことでサービスの運営を妨げることは避けたい．そ絶たず [8]，Web サービスが保有する個人情報やサービスのため，導入時のシステムの構成や開発プロセスへの影響

特有の機密情報を漏洩させるようなセキュリティインシデ

を抑えつつ，不正クエリへの対策を行うことが求められる．

ントが発生している [10]．このような攻撃は Web アプリ

このことから，Web アプリケーションの実装言語に依存せケーションが利用するデータベースに不正クエリを発行すず，既存のシステム構成や開発プロセスに大きく影響を与ることで行われ，場合によっては 1 つの不正クエリが大規

えない不正クエリへの対策が必要となる．

模な情報漏洩を引き起こす．そのため，不正クエリはデー本研究では，Web アプリケーションの実装に依存せず，タベースで実行される前に検知し，実行を停止する必要が

Web アプリケーションの運用前に，自動でホワイトリス

ある．また，PHP や Ruby など様々なプログラミング言語

トを作成するための手法について述べる．提案手法は，開が実装に用いられる Web サービスにおいては，Web アプ

発プロセスに自動テストが採用されている状況において，リケーションの実装に依存せず汎用的に利用できる不正ク

Web アプリケーション運用前のテスト実行時に Web アプ

エリの検知方法が求められている．

リケーションが発行するクエリを収集してホワイトリスト

ネットワークの攻撃検知方法として，異常検知と不正検を自動で作成する．テスト時のクエリを収集することよっ知が一般的に用いられる [11]．異常検知では，統計的な手て，開発者が想定する Web アプリケーションの動作の過程

法や学習的な手法を用いて，正しい利用状況を表すプロで生じるクエリがホワイトリストに登録される．提案手法

ファイルを作成し，不正なパターンの検知を行う．統計的によって検知されたクエリは開発者が想定できていないクな手法や学習的な手法を用いることから，プロファイルのエリであり，そのようなクエリはテスト時に発行されてい作成に時間がかかり，即時に検知を行うことができない．

ないもしくは不正クエリに限定され，テストカバレッジをまた，プロファイルの正確性によっては，誤検知率が高く向上させることが不正クエリの検知精度向上につながる．

なってしまう．そのため，不正クエリ検知に用いた場合，検Web アプリケーションの実装に依存しないようにするた

知漏れにより不正クエリを実行されてしまうことや，Web

めに，提案手法はデータベースの前段にデータベースプロ

アプリケーションの正常なクエリ発行の実行を妨げてしま

キシを配置することでクエリの収集を行い，ホワイトリス

う問題が発生する．一方で，不正検知には，既知の不正なトに定義する方法を検討している．

パターン（ブラックリスト），もしくは既知の正常なパター

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

ン（ホワイトリスト）を定義して，パターンマッチングを利用するデータベースへの不正クエリ検知の課題を整理す

行い検知する方法がある．不正クエリをブラックリストをる．3 章では，提案手法の開発プロセスにおける位置付け

用いて検知する場合は，既知の不正クエリのパターンを全と提案手法の設計について述べ，提案手法の考察を述べる．

て定義できたとしても，未知の不正クエリを検知すること4 章でまとめを述べる．

ができない．これ対して，ホワイトリストを用いる場合は，

Web アプリケーションが発行するクエリを定義すること
で，未知の不正クエリにも対応可能である．

2. Web アプリケーションが利用するデータベースへの不正クエリ検知の課題

Web アプリケーションが発行するクエリのホワイトリス

Web アプリケーションが利用するデータベースへの不正トを定義することは，Web アプリケーションの大規模化やクエリ検知の課題を整理する．ネットワークの攻撃検知方

複雑化などの理由で，ホワイトリストの作成が困難となっ法として，異常検知と不正検知が一般的に用いられる [11]．

ている．そのため，Web アプリケーションが発行するクエ

異常検知は，統計的な手法や学習的な手法を用いて，正しリのホワイトリストを自動で作成する手法が提案されていい利用状況を表すプロファイルを作成し，収集したデータ

る [2][7]．しかし，これらの手法は，ホワイトリスト作成のとプロファイルを比較しその差が大きい場合を不正とみなための学習期間が必要であることによる検知の即時性の課す．統計的な手法や学習的な手法を用いることから，プロ

題や，Web アプリケーションの実装言語に依存してしまう

ファイルを作成するのに時間がかかる課題があり，不正ク

課題がある．

エリ検知に用いる場合は，検知できない期間が発生し，不正クエリを実行される危険性がある．また，プロファイル

1

2

a)

GMO ペパボ株式会社 ペパボ研究所
Pepabo R&D Institute, GMO Pepabo, Inc., Tenjin, Chuo
ku, Fukuoka 810-0001 Japan
力武健次技術士事務所
Kenji Rikitake Professional Engineer’s Oﬃce, Toyonaka
City, Osaka 560-0043 Japan
komei.nomura@pepabo.com

c 2018 Information Processing Society of Japan
⃝の正確性によっては，不正なパターンを正常なパターン，
もしくは正常なパターンを不正なパターンと誤検知することが多い．そのため，不正クエリ検知において，不正なパターンを正常なパターンと誤検知した場合は，不正クエリを実行されてしまい，正常なパターンを不正なパターンと2

Vol.2018-CSEC-81 No.24
Vol.2018-IOT-41 No.24
2018/5/18

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

誤検知した場合は，Web アプリケーションが発行する正常

表 1 Ruby コードと発行されるクエリの対応例

なクエリの実行を妨げてしまう．一方で，不正検知は，既Table 1 Example of Ruby code and issued query

知の不正を定義し，収集したデータとパターンマッチングを行い，不正なパターンを検知する．不正検知には，不正

Ruby コード
User.find(1)なパターンをブラックリストとして定義しパターンがマッチしたものを不正とみなす方法や，正常なパターンをホワ

User.first

発行されるクエリ
SELECT * FROM users WHERE(users.id = 1) LIMIT 1
SELECT * FROM users ORDER BY
users.id ASC LIMIT 1

イトリストとして定義しパターンがマッチしないものを不正とみなす方法がある．ブラックリストを用いて検知するとして扱えるため，直接 SQL 文を記述することが少なく場合，全ての不正のパターンをブラックリストに定義するなる．例えば，Web アプリケーションの実装に Web アプ

こと難しく，定義できたとしても未知の不正パターンに対リケーションフレームワークである Ruby on Rails を用い応することができない．また，一般的な不正パターンが提た場合，ORM として ActiveRecord が利用される [4]．開供されている場合もあり [5]，この場合，導入は容易にな

発者は，ActiveRecord を用いて，データベースのレコード

るが，不正パターンの更新は提供側任せになるため，新たと Ruby のクラスオブジェクトを関連づけることで，クラな不正パターンへの対応が遅れる場合が考えられる．ホワ

スオブジェクトを用いてクエリの発行処理を記述できる．

イトリストを用いて不正クエリを検知する場合，Web アプ

クラスオブジェクト User がデータベースの users テーブ

リケーションが発行するクエリのパターンを正常なパター

ルのレコードに関連付けされている場合の Ruby コードとンとして定義し，それ以外のクエリを不正クエリとみなす

発行されるクエリは表 1 のようになる．このように，開発

ことで，未知の不正クエリにも対応できる，ホワイトリス

者は Web アプリケーションが発行するクエリを意識する

トに定義する Web アプリケーションが発行するクエリの必要がなくなるため，ホワイトリストを手動で定義するこパターンには，Web アプリケーションが発行するクエリはとは，ORM を用いた開発の妨げとなる．

ユーザからの入力により変化するため，クエリのユーザ入

Web アプリケーションの運用時に発行されるクエリを収力部分をプレースホルダに置き換えたクエリ構造（クエリ

集し，構文解析を行いクエリダイジェストに変換すること

ダイジェスト）が用いられることがある [1]．ホワイトリス

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

トを手動で定義する場合，開発者は Web アプリケーション

この手法には，クエリを収集しホワイトリストを作る学習のソースコードから全てのクエリ発行処理を特定し，そこ

モードと作成したホワイトリストを用いて検知を行う検知から発行されるクエリダイジェストを把握しなければならモードがあり，学習モード中は検知を行うことができない．

ず，開発者への負担は増加する．さらに，Web アプリケー

この手法を用いることで，Web アプリケーションの運用時

ションの以下の特徴から，手動で Web アプリケーションに自動でホワイトリストを定義することができる．しかし，が発行するクエリをホワイトリストに定義することが困難

ホワイトリストの作成には学習期間を要するため，Web アになっており，開発者への負担は増加する傾向にある．

プリケーションの更新頻度が高い特性から，頻繁に再学習( 1 ) Web アプリケーションの大規模化を行わなければならず，その都度検知を行えない期間が発( 2 ) Web アプリケーションの複雑化

生してしまう．そのため，学習期間中に不正クエリを発行( 3 ) Web アプリケーションの更新頻度が高い [9]された場合は，検知することができず実行されてしまう．

( 4 ) Web アプリケーションの実装にオブジェクトリレー

これは，Web アプリケーション運用時にホワイトリストをショナルマッピング（ORM）[6] の利用（1）（2）により，Web アプリケーションのクエリ発行
処理が増加するうえに，条件分岐によってクエリ発行処理

作成していることが原因であり，Web アプリケーションデ
プロイ後即時に不正クエリの検知を行うためには，運用前の段階でホワイトリストを作成する必要がある．

が複雑化し，ホワイトリストを作成するための開発者の負Web アプリケーションのソースコードからクエリの発行担が増大する．
（3）により，Web アプリケーションが発行処理を特定し，クエリ発行処理を解析することで，ホワイするクエリダイジェストが変化する頻度が向上し，その度トリストを自動で作成する手法が提案されている [7]．このにホワイトリストを更新することは開発者の負担を増大さ手法を用いることで，Web アプリケーション運用前にホワせる．これらのことから，Web アプリケーションの開発を

イトリストを作成することができ，Web アプリケーション行いながら，ホワイトリストを定義することは，開発者にデプロイ後即時に不正クエリの検知を行える．一方で，ことって大きな負担となる．さらに，（4）により，開発者はの手法では，ソースコードのクエリ発行処理の解析を行う

Web アプリケーションが発行するクエリを意識することがため，Web アプリケーションの実装言語ごとに解析器を実少なくなる．ORM[6] はオブジェクト指向言語におけるオ

装しなければならない．これは Web アプリケーションのブジェクトとデータベースのレコードを関連づける．これ

実装言語が多様化していることと，様々な ORM が利用さにより，開発者はデータベースのレコードをオブジェクトれるようになっていることが原因で課題となる．筆者が所

c 2018 Information Processing Society of Japan⃝3

Vol.2018-CSEC-81 No.24
Vol.2018-IOT-41 No.24
2018/5/18

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

属する GMO ペパボ株式会社では，PHP や Ruby のような様々な言語や Web アプリケーションフレームワークを用いて Web サービスの開発が行われている．このような状況において，不正クエリへの対策をすることは重要である
が，対策を行うことによってサービスの運営を妨げることは避けたい．そのため，導入時のシステムの構成や開発プ
ロセスへの影響を抑えつつ，Web アプリケーションの特性などに依存しない汎用的な不正クエリへの対策を行うことが求められる．このことから，Web アプリケーションの実
装言語に依存せず汎用的に利用でき，かつ，現状のシステ
ム構成や開発プロセスに影響の少ない対策が必要となる．

3. 提案手法
2 で述べた課題を解決するために，提案手法は以下の要件を満たす必要がある．

• Web アプリケーションが発行するクエリのホワイトリ
ストを自動で作成できる• Web アプリケーションの運用前にホワイトリストを作成できる

図 1 自動テストを用いた Web アプリケーションの開発プロセス

Fig. 1 Web application development process using Automatic
testing• Web アプリケーションの実装に依存せずホワイトリス
トを作成できるのソースコードもしくはテストコードの修正を行う．テス

提案手法は，開発プロセスへの影響を抑えつつ，Web ア

トが成功した場合は，開発した機能が仕様通りに動作してプリケーションのデプロイ後即時に不正クエリの検知を行いることを確認できたとみなし，本番環境に Web アプリ

うために，開発プロセスに自動テストが採用されている場

ケーションをデプロイし運用する．

合を想定し，テスト時に発行するクエリを利用してホワイ

この開発プロセスの特徴は，開発された機能に対して，

トリストを自動で作成する．また，提案手法は，導入時の開発者が想定する Web アプリケーションの動作をテスト

システム構成への影響を抑えつつ，Web アプリケーショ

コードに記述していくことであり，これにより Web アプ

ンの実装に依存せず，ホワイトリスト作成を行うために，

リケーションの動作を保障する．しかし，テストコードにデータベースの前段にデータベースプロキシを配置しクエ

記述されているテストケースには漏れが生じる可能性があリを収集する．

るため，機能が定義したテストケースに対して正常に動作していないことは分かるが，機能の動作に欠陥がないこと

3.1 自動テストを採用した開発プロセスにおける提案手法の位置付け保証することはできない．このことから，テスト時に発行されるクエリは，開発者が想定した Web アプリケーショ

自動テストを採用した開発プロセスを図 1 に示す．

ンの動作の過程で発行されたクエリであり，開発者が想定

図 1 で示した開発プロセスについて説明する．まず，開できているクエリである．そのため，提案手法は Web ア

発者は Web アプリケーションの新機能の開発や既存機能

プリケーション運用時における開発者の想定できていないの修正を行う．次に，開発した機能が既存の他の機能に影クエリを検知することができる．

響を与えている場合や，開発した機能に対してのテストが提案手法は，図 1 の開発プロセスの自動テスト時に Web行われていない状態が発生している場合は，開発者はテスアプリケーションが発行するクエリのホワイトリストが作

トコードの記述を行う．ここで，テストコードには，Web

成できており，Web アプリケーションのデプロイ時にホワ

アプリケーションをテストするときの実行手順であるテス

イトリストの更新を行うことができる．これにより，Web

トケースと期待される動作結果が記述されており，Web ア

アプリケーションの仕様変更により，発行されるクエリダ

プリケーションが仕様通りに動作しているかの検証を行う．

イジェストに変化があったとしても，変化に追従しホワイ

そして，自動テストの段階で，全てのテストコードを用いトリストを更新することができる．

てテストを行う．このとき，テストが失敗した場合は，開発した機能の動作が仕様通りでない，もしくはテストコー

3.2 提案手法の設計

ドの記述，すなわち仕様の定義に誤りがあることが分かる．

提案手法は，テスト時と Web アプリケーション運用時

この場合，開発者は原因を特定し，Web アプリケーション

において，どちらも同じアーキテクチャを用いて，テスト

c 2018 Information Processing Society of Japan⃝4

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

Vol.2018-CSEC-81 No.24
Vol.2018-IOT-41 No.24
2018/5/18

時の Web アプリケーションが発行するクエリの収集と運ある．現状，提案手法では，検知されたクエリがテスト不用時の発行されるクエリの監視を行う．提案手法のテスト

足により検知されたクエリか不正クエリかを判断すること

時のホワイト作成フローと Web アプリケーション運用時はできないため，この判断は開発者に任せるしかない．その検知フローを図 2 を用いて説明する．

のため，今後の課題として，この判断を行い開発者に知らテスト時のホワイトリスト作成フローを説明する．図 2せるための方法の検討が必要である．

において，まず，テストが実行されることにより，テスト

テストコードを記述することとホワイトリストにクエリ

コードに基づいて Web アプリケーションが動作する．次ダイジェストを手動で定義することの開発者への負担の差に，その動作の過程で，データベースにアクセスする処理について述べる．テストコードには想定される Web アプがある場合，Web アプリケーションはデータベースにクリケーション動作であるテストケースを記述していくのにエリを発行する．このとき，データベースの前段に配置さ対して，ホワイトリストには Web アプリケーションが動れているデータベースプロキシがクエリを受け取り，受け作の過程で発行するクエリダイジェストを定義していく．

取ったクエリに対して構文解析行いクエリダイジェストに

テストコードを書く場合，開発者は Web アプリケーショ

変換し記録する．データベースプロキシが受け取ったクエンの動作を意識する．これに対して，ホワイトリストを作

リはそのままデータベースに渡すことで，テストの実行に成する場合，開発者は Web アプリケーションの動作を理支障が出ないようにする．テスト終了後，データベースプ

解したうえで，その過程で発行されるクエリを意識しなけ

ロキシに保管されているクエリダイジェストの一覧がホワ

ればならない．そのため，テストコードを記述していくこ

イトリストとなる．

との方が開発者への負担が少ないと考えられる．

Web アプリケーション運用時の検知フローについて説明提案手法で検知できない不正クエリについて述べる．提する．図 2 において，まず，Web アプリケーションがユー

案手法のホワイトリストにはクエリのユーザ入力部分をプ

ザからの入力を受けクエリを発行する．次に，発行された

レースホルダーに置き換えたクエリダイジェストが定義さクエリをデータベースプロキシが受け取り，構文解析を行れており，ユーザ入力部分が不正かどうかの判断は行なっいクエリダイジェストに変換し，ホワイトリストと照合すていない．そのため，クエリダイジェストが同じであるが，る．このとき，発行されたクエリのクエリダイジェストがユーザ入力部分が不正であるようなクエリを検知すること

ホワイトリストに定義されていた場合，そのクエリを正常はできない．例えば，セッションハイジャックにより，あとみなしデータベースに渡し実行する．発行されたクエリるユーザのアカウントが乗っ取られてしまい，そのユーザのクエリダイジェストがホワイトリストに定義されていなの個人情報を取得するようなクエリを発行される状況が考かった場合は，クエリをデータベースに渡さず実行を停止えられる．この場合，Web アプケーションから発行されする．

るクエリは，ホワイトリストに定義されているクエリダイ
ジェストと同じとなるため，提案手法では検知することが

3.3 提案手法の考察
提案手法によって検知できるクエリについて述べる．提できない．そのため，このようなクエリに対しては，提案
手法とは別に対策を検討する必要がある．

案手法は，テスト時のクエリを用いてホワイトリストを作

Web アプリケーション運用時の検知の実装について述べ成しているため，これを用いて検知されるクエリはテスト

る．Web アプリケーション運用時の検知には，発行された時に発行されたクエリダイジェストに一致しないものであクエリとホワイトリストの照合を行うため，この処理の実る．つまり，提案手法によって作成されたホワイトリスト

装方法が Web アプリケーションとデータベース間のレイで検知されたクエリは，テストコードを記述した開発者がテンシーに影響を与えると予想される．Web アプリケー

想定できていないテストケースが，運用時に実行されたこションから発行されたクエリに対してホワイトリストを全とによって生じた想定できていないクエリである．このよ

探索した場合，ホワイトリストの照合処理の計算量はホワ

うなクエリには，テスト不足により検知されたクエリと不イトリストに定義されているクエリダイジェスト数 n に正クエリが含まれている．図 3 にクエリの内包関係の概略

対して O(n) となる．そのため，Web アプリケーションと図を示す．

データベース間のレイテンシーが増大することが予想され

図 3 より，Web アプリケーションのテストカバレッジをる．これを避けるために，ホワイトリストの作成時には，向上させることによって，開発者が想定できているクエリ

クエリダイジェストをキーとしてハッシュテーブルに登録

領域を Web アプリケーションが発行するクエリ領域に近しておき，運用時のホワイトリストの照合処理を行うこと

づけることができ，その結果，不正クエリの検知精度向上

で，Web アプリケーションとデータベース間のレイテンに繋がると考えられる．テストカバレッジを向上させるたシーの増大を抑えられると考えられる．

めには，検知されたクエリの中からテスト不足により検知されたクエリであることを判断し開発者に知らせる必要がc 2018 Information Processing Society of Japan⃝5

Vol.2018-CSEC-81 No.24
Vol.2018-IOT-41 No.24
2018/5/18

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

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

Fig. 2 Propose method architecture

[2]

[3]

[4]
[5]
[6]

[7]

図 3 クエリの内包関係

Fig. 3 Relationship of queries

4. まとめ

[8]
[9]

[10]

本稿では，Web アプリケーションが利用するデータベースに対して個人情報を窃取するような不正クエリを防ぐために，開発プロセスに着目し，テスト時に Web アプリケー[11]

puting Conference (IACC), 2013.
F. Valeur, D. Mutz and G. Vigna, A Learning-Based Approach to the Detection of SQL Attacks In Proceedingsof the Conference on Detection of Intrusions and Malware Vulnerability Assessment (DIMVA), July 2005.
Martin Fowler, David Rice, Matthew Foemmel, Edward
Hieatt, Robert Mee, Randy Staﬀord, Patterns of Enterprise Application Architecture, Addison-Wesley, 2002.
M Bachle, P Kirchberg, Ruby on rails, 2007.
OWASP ModSecurity Core Rule Set (CRS),
https://modsecurity.org/crs/.
Scott W. Ambler, Mapping objects to relational
databases What you need to know and why Ronin International, July 2000.
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.
IPA, 安全なウェブサイトの作り方 改訂第７版, 2015 年,
3 月.
青井 翔平, 坂本 一憲, 鷲崎 弘宜, 深澤 良彰, DePoT:Web
アプリケーションテストにおけるテストコード自動生成
テスティングフレームワーク, 情報処理学会論文誌 Vol.56
No.3 835846, March, 2015.
情報セキュリティインシデントに関する調査報告書 個人
情報漏洩編 第 1.2 版, NPO 日本セキュリティ協会セキュ
リティ被害調査ワーキンググループ, 長崎県立大学 情報システム学部情報セキュリティ学科, 2017 年 6 月.
藤田 直行, 侵入検知に関する誤検知低減の研究動向, 電子
情報通信学会論文誌 B Vol.J89B No.4 pp.402411, 2006.

ションが発行するクエリを収集し，Web アプリケーショ
ンが発行するクエリのホワイトリストを自動で作成する手法を提案し，手法の設計について述べた．今後は，提案手法を実装し，テストカバレッジに対する不正クエリの検知
精度の検証や導入による Web アプリケーションとデータベース間のレイテンシーへの影響の検証などを進めていく．また，今後の課題として，検知されたクエリがテスト不足により検知されたクエリか不正クエリかを判断する方法や，提案手法では検知できないクエリダイジェストが同一の不正クエリへの対策を検討が挙げられる．
参考文献
[1]

D Kar, S Panigrahi, Prevention of SQL Injection attack
using query transformation and hashing, Advance Com-

c 2018 Information Processing Society of Japan⃝

6