テストテンプレートを⽤用いた

(1)

2015 年度修⼠士論⽂文

テストテンプレートを⽤用いた

セキュリティ設計パターンの実装⽀支援に関する研究

2016 年 2 ⽉月 1 ⽇日（⽉月）提出

指導：深澤良彰教授

早稲⽥田⼤大学⼤大学院基幹理⼯工学研究科情報理⼯工・情報通信専攻

学籍番号：5114F095-4

芳澤正敏

(2)

i

第 1 章はじめに

ソフトウェアのシステム開発において、セキュリティ対策を施すことは重要であり、現代のネットワーク社会ではある種義務といっても過⾔言ではない。セキュアなソフトウェアを開発するためには、セキュリティに関する専⾨門知識が必要になる。セキュリティの問題というのは、悪意のある第三者によって引き起こされるため、対応可能な問題については設計段階から⼗十分に考慮しておく必要がある [1]。

セキュリティの関⼼心事はソフトウェア開発の要求から設計、実装、テスト、

運⽤用の全てのフェーズで扱えるようにしなくてはならない [2]。しかしながら、ソフトウェア開発者が必ずしもセキュリティの専⾨門家ではなく、開発の早い段階でのシステムにおけるセキュリティ項⽬目について⼗十分に考慮されていない。そこでセキュリティの専⾨門家の知識を活⽤用・再利⽤用する⽅方法としてセキュリティパターン [3]がある。セキュリティパターンとは、セキュリティに関する特定の状況下で幾らか抽象化された問題およびその解決法である。

しかし、現状では設計レベルのパターンは記述が抽象的なため、設計⽅方針は理解できても、それを具体的にどう実装に落としていけばよいかが分かりにくい [1]。そのため、実装がセキュアな要求仕様を満たしているか確認することが必要になるが、そのためのセキュリティ機能のテストには、特殊なテストケースなどの通常の機能テストと異なる準備とテストの実施が必要になる [4]。

そこで本稿では、テストテンプレートを⽤用いたテストによるセキュリティ設計パターンの実装⽀支援を提案する。本⼿手法では、設計レベルのセキュリティパターンに定義された情報からテストテンプレートを新たに定義した。このテストテンプレートに設計情報を与えてテストを⽣生成する。テストを⾏行うことでセキュリティ設計パターンの適⽤用検証を⾏行い、そのテストの結果より実装の⽀支援をする。

本研究の研究課題(RQ)として以下の4つを⽰示す。

(5)

2

RQ1 既存⼿手法に⽐比べて本⼿手法は効率的にセキュリティ設計パターンの実装の誤りを発⾒見できるか。

RQ2 既存⼿手法に⽐比べて本⼿手法は効果的なセキュリティ設計パターンの実装の誤りを発⾒見できるテストを作成できるか。

RQ3既存⼿手法に⽐比べて本⼿手法は回帰テスト可能なセキュリティ設計パターンの実装の誤りを発⾒見できるテストを作成できるか。

RQ4既存⼿手法に⽐比べて本⼿手法はセキュリティパターンの実装の誤りの修正を⽀支援することができるか

本研究の貢献を以下に⽰示す。

l セキュリティ設計パターンから再利⽤用可能なテストテンプレートの作成。

l 効率的なセキュリティ設計パターンの実装の誤りの発⾒見。

l 効果的なセキュリティ設計パターンの実装の誤りの発⾒見のテストの作成。

l 回帰テスト可能なテストの作成。

l セキュリティ設計パターンの実装⽀支援。

以下に本稿の構成を述べる。第2章では、本研究の背景を述べる。第3章では、関連研究について述べる。第4章では、本研究の提案を述べる。第5章では、提案⼿手法の評価について述べる。第6章では、本⼿手法の制限について述べる。第7章では、本稿のまとめと展望について述べる。

(6)

3

第 2 章背景

2.1 セキュリティ

情報セキュリティの定義は、ISO/IEC2700 [5]では、「情報の機密性、完全性及び可⽤用性を維持すること。さらに、真正性、責任追従性、否認防⽌止及び、信頼性のような特性を含めてもよい。」としている。セキュリティの問題とは、このような特性が成り⽴立たなくさせる攻撃が発⽣生するために起こる。例えば、機密性を守りたい個⼈人情報があった場合、その情報を漏えいさせる攻撃により、

機密性が保たれなくなるというセキュリティ上の問題が発⽣生する[2]。

また、吉岡らは[1]でセキュリティに関する概念として以下の9つを挙げている。

l Asset(アセット):

組織や⼈人が、価値のあると認めることができる情報、またはリソース

l Stakeholder(ステークホルダー):

アセットに特定の価値を満たすための宣⾔言⽂文

l Security objective(セキュリティ⽬目標):

脅威に対する安全が脅かされている可能性があること

l Threat(脅威):

アセットに対する安全が脅かされている可能性があること

l Attack(攻撃):

アセットの安全性を破壊する⾏行為

l Attacker(攻撃者):

攻撃を実⾏行する実体

(7)

4 l Vulnerability(脆弱性):

アセットに関するセキュリティを破ることができる⽋欠陥や弱点

l Countermeasure(対策):

脆弱性や攻撃に対してアセットを保護するための⾏行為

l Risk(リスク):

攻撃が成功する確率の⾼高さ

セキュリティは、守るべき価値のあるアセットに対する故意の攻撃と、その攻撃に対する概念である。

ソフトウェア開発において、セキュリティの関⼼心事は、要求、設計、実装、

テスト、運⽤用のすべての段階で扱えなくてはならない。しかし、ソフトウェア開発者が必ずしもセキュリティの専⾨門家であるというわけではない。そこで、

専⾨門家の知識を活⽤用、再利⽤用する⽅方法としてソフトウェアパターンがある。そして、このソフトウェアパターンのうち、セキュリティに関する知識をまとめたものがセキュリティパターンである。ユーザビリティは、⽇日本語では「使いやすさ」と訳されている。しかし、ソフトウェアにおいては、そのシステムの性質やそれを使うユーザ、利⽤用状況などによって「使いやすさ」は変化するため、この「使いやすさ」を定義することは難しい。

2.2 ソフトウェアパターン

ソフトウェアパターンとは、どこかで⾒見たことのあるような繰り返されるソフトウェア設計やコードを集めたもののことである [6]。また、ただ単に集めただけではなく、様々なソフトウェア開発事例のうち、熟練者による類似の成功事例を集めて共通部分を抽象化し、名前を与えたものである。代表的なものとしてはGoFデザインパターンが挙げられる。パターンを⽤用いることによるメリットとしてまず、過去の成功体験者やビジョン策定者の思考過程と成果を再利⽤用して、同じような状況で似た問題の解決に成功する確率を⾼高めることができる [5]。また、難しい問題に⾜足してその解決策を⾃自ら考えるのではなく、あらかじめノウハウとして蓄積されているパターンを適⽤用することで、開発者のコストを⼤大幅に低減させることができる。次に、意思疎通を促進できることが

(8)

5

挙げられる。様々なパターンの名前をソフトウェア開発における語彙として使うことで、状況や解決策をいちいち説明しなくてもよくなるため、複数の開発者と仕事をする際に意志疎通をスムーズに⾏行うことができる。結果、ソフトウェアパターンを⽤用いることで、低コストで⾼高品質なソフトウェア開発を⾏行うことができる。

2.2.1 セキュリティ設計パターン

機密性など、情報(資産)に対するセキュリティ特性を守るためには、暗号機能や認証フレームワークなどセキュリティ機能を利⽤用し、セキュリティを設計する必要がある。セキュリティ機能は、できる限り安全性が確認されている既存のにものを利⽤用し、独⾃自に実装しないことが望ましい。そのためにセキュリティ機能をどのように使えばよいのかの設計⽅方針を⽰示したセキュリティ設計パターンの利⽤用がある。M.Schumacherらは[3]で、セキュリティの設計に役⽴立つ7 種類、38パターンが紹介されている。具体的には、セキュリティの基盤やアプリケーションによって、IDの証明、アクセス制御モデル、アクセス制御アーキテクチャ、OSのアクセス制御、真証性確認・監査、ファイヤーウォール、インターネットアプリケーションの7種類にセキュリティパターンを分類している。

セキュリティ設計パターンの代表例として、組織や役割ごとに情報のアクセス制御について説明しているロールベースアクセス制御パターン(Role-Based

Access Control Pattern)が挙げられる。このパターンでは、図2.1のようにロール

ベースアクセス制御を⾏行う際のユーザと情報との静的な構造をクラス図によって⽰示している。しかし、実装における脆弱性への対策のパターンは対象外であるという問題がある。

図2.1 ロールベースアクセス制御の構造([2]から引⽤用)

(9)

6 2.2.2 セキュリティ実装パターン

ソフトウェアをセキュアに実装するためには、セキュリティ設計を正しく実装するとともに、実装(コード)に付随して発⽣生する脆弱性を排除する必要がある。また、実装がセキュリティ要求仕様を満たすことを、テストによって確認する必要がある。実装時のセキュリティパターン(セキュリティ実装パターン) はこれらの⽀支援を⾏行う。

プログラマの視点で、セキュアなプログラムを書くための設計や実装をガイドラインとしてまとめたものを、⼀一般に“セキュアプログラミング”と呼ぶ。セキュアプログラミングの例として、[8]では、取り除くべきプログラム上の問題点に関して、18個の実装のルールを定めている。また、[9]では、6種類について推奨される実例と、23個の悪い実例を整理している。

ソフトウェアを破壊する⽅方法に焦点を当てたパターンにアタックパターン

[10]がある。[11]では、19個のアタックパターンを紹介しており、Webブラウ

ザなどの特定のアプリケーションの例を説明している。アタックパターンでは、直接コーディングを⽀支援していないが、実装を改善するために有効である。

アタックパターンをWeb上で共有する枠組みとしてCommon Attack Pattern Enumeration and Classification (CAPEC)[12]がある。CAPECでは、既知の攻撃を、その分類、過酷さ、対応⽅方針、関連する攻撃などとともに登録して情報を共有することができる。また、多数の攻撃の分類や関連を⾃自動化するために、

XML形式で共有している。そのデータベースは、現在380パターン以上が登録されている。図2.2はSpoofingについて書かれたものである。

図2.2 CAPEC Spoofing

(10)

7

問題点として、実装レベルのパターンは数が多く、必要なパターンを⾒見つけ出すのが困難であるということが挙げられる。設計レベルのパターンはそれほど数があるわけではないが、記述が抽象的なため、設計⽅方針は理解できても、

それを具体的にどう実装に落としていけばよいかが分かりにくい。なぜならば、現状、設計⽅方針、詳細設計、実装のそれぞれのパターン間での関連が定義されていないため、設計時に選ばれたパターンがどう実装と関連するのかが明確ではない。また、実装がセキュアな要求仕様を満たしているか確認するためのセキュリティ機能のテストには、特殊なテストケースなどの通常の機能テストと異なる準備とテストの実施が必要になる。

2.3 動機付けの例

図2.3にEMSsec[13]という学⽣生情報管理システムのWebアプリケーションに

対してセキュリティ設計パターンを適⽤用した設計の⼀一部を⽰示す。

図2.3 EMSsecの設計の⼀一部

(11)

8

EMSsecはセキュリティとプライバシーに関連したソフトウェア開発⼿手法の

ための共通問題として開発されたものである。このアプリケーションには、正規のユーザのみアクセス可能にしたい、不正な⼊入⼒力があった場合には検出したいというセキュリティ要求がある。図2.3の設計段階におけるクラス図ではこの要求に対して、Password Design and UseパターンとPrevent SQL Injectionパターン、Prevent XSSパターンの3つが正しく適⽤用されている。しかし、この設計を実装した場合、実装段階においてセキュリティ設計パターンが適切に適⽤用できているのか確認できない。なぜならば、セキュリティ設計パターンと実装間の関係が定義されていないため、どのように実装すれば良いのかわからないからである。また、実装した場合にそれが適切な実装であるのか確認することもできない。そのため、脆弱性を含んだシステムを構築する可能性がある。

(12)

9

第 3 章関連研究

UMLモデルのシミュレーション環境を⽤用いたモデルテストにより、セキュリティパターンの⼀一貫した適⽤用⽀支援を⾏行い、適⽤用検証を⾏行う研究がある[14]。既存のセキュリティパターンに新たな定義を加えた拡張セキュリティ要求パターン(Extended Security Requirement Pattern)(以下Ex SRP)と拡張セキュリティ設計パターン(Extended Security Design Pattern)(以下Ex SDP)を提案している。

図3.1 Ex SRPとEx SDPの構造概要

Ex SRPには新たに「対策」としてセキュリティ要求とセキュリティテストテ

ンプレートが与えられている。セキュリティ要求はモデル記述のための形式⾔言語であるオブジェクト制約⾔言語(Object Constraint Language)(以下OCL)記述で表現され、曖昧であったパターンの厳密な定義を可能にしている。セキュリティテストテンプレートは要求段階でのモデルがEx SRPで与えられ、セキュリティ要求を満たしているか確認する。セキュリティ要求の例を図3.2、セキュリ

(13)

10

ティテストテンプレートの⼀一部の例を図3.3に⽰示す。Ex SDPはEx SRPの「対策」と関連付けられているので⼀一貫した適⽤用⽀支援を⾏行うことができる。

図3.2 Ex SRPのセキュリティ要求の例(OCL)

図3.3 Ex SRPのセキュリティテストテンプレートの⼀一部の例

しかし、この研究では要求と設計間でのセキュリティパターンの適⽤用⽀支援・

検証に留まっている。本⼿手法では、設計と実装間でのセキュリティパターンの適⽤用⽀支援、検証を⾏行うことができる。

また、セキュリティパターンが利⽤用者に与える効果の程度を測るために学⽣生 32名を対象とした実験を⾏行った研究がある[15]。この研究では、設計段階にお

(14)

11

けるセキュリティの対策をセキュリティパターンを⽤用いた場合と⽤用いない場合で事前に埋め込んだ脅威への対処を⽐比較し、加えてアンケートによってセキュリティパターンの効果について調べた。アンケートの結果では被験者の多くかセキュリティパターンを⽤用いた場合の⽅方を好み、またセキュリティパターンによって⾃自分⾃自⾝身では気づかなかった解決策を⾒見つけることができたと答えた。

しかし、この研究では設計段階のみでの⽀支援の実験に留まっている。本研究では実装段階での実装⽀支援を⾏行い、被験者から本⼿手法の優位性を調べた。

(15)

12

第 4 章本研究の提案

4.1 本⼿手法の全体像

本⼿手法の全体像を図4.1に⽰示す。

図4.1 本⼿手法の全体像

本⼿手法では、設計時に使われたセキュリティ設計パターンからテストテンプレートを作成し、テンプレートに設計の情報を与えることでテストの⽣生成を⾏行

(16)

13

う。実装に対して⽣生成されたテストを⾏行い、修正を繰り返すことによりセキュリティ設計パターンの実装⽀支援を⾏行う。また、TESEM[16]というUMLのモデリングとセキュリティ設計パターンの適⽤用検証を⾏行うことのできるWebアプリケーションを拡張し、テストケースの⾃自動⽣生成を実現した。

以下に本⼿手法の具体的な流れについて説明する。

ステップ0 : テストテンプレートの作成

事前にセキュリティ設計パターンからテストテンプレートを作成する。テストテンプレートは「アスペクトテストテンプレート」と「テストケーステンプレート」の2つからなる。

ステップ1 : 設計の実装

セキュリティ設計パターンが使⽤用されている設計を実装する。しかし、この時点では、セキュリティ設計パターンが適切に実装されているかわからない。

ステップ2 : テストテンプレートからテストの⽣生成

テストテンプレートに設計の情報を与えることでテストを⽣生成する。

ステップ3 : 実装のテスト

テスト駆動開発を基として、パターンが使⽤用されている実装に対してパターンの適⽤用確認のためにテストをする。

ステップ4 : 実装のリファクタリング

ステップ3でエラーを基に実装のリファクタリングをする。

ステップ5 : 実装の再テスト

リファクタリングされた実装に対して再度テストを⾏行い、パターンの適⽤用を確認する。テストに成功すればそのパターンが実装段階において適切に適⽤用されていることが確認できる。失敗した場合、成功するまでステップ4を繰り返し、システムを洗練する。

まず以下にテスト実⾏行の際に⽤用いる考え⽅方であるモデルベーステスト、テスト駆動開発とアスペクト指向について説明する。

(17)

14

4.2 モデルベーステスト

モデルベーステスト(MBT: Model-based Testing)は⼀一部かすべてのテストケースをモデルから⽣生成する技術である[17]。モデルとはシステムを実現すべき処理を表現したものである。MBTは複雑でコストのかかるテストを緩和することができる。⾃自動MBTツール[18]やセキュリティにおけるMBT[19]についてなどがある。

本研究ではセキュリティ設計パターンから作成したテストテンプレートを定義した。そのため、テストテンプレートは抽象的かつ再利⽤用できる。このテストテンプレートを⽤用いたMBT ツールを使⽤用し、テストを⽣生成する。

4.3 テスト駆動開発

テスト駆動開発(TDD：Test Driven Development)とは、プログラム開発⼿手法の

⼀一種で、プログラムに必要な各機能について、最初にテストを書き(テストファースト)、そのテストが動作する必要最低限な実装をとりあえず⾏行った後、コードを洗礼させる、という短い⼯工程を繰り返すスタイルである[20]。

本研究では、Selenium[21]というWebアプリケーションのテストツールを使

⽤用して、テストを実施する。実装する際に、まずテストが動作する最低限のコードの実装を⾏行い実装上の脆弱性を検出させ、その後コードの洗練を⾏行い、テストを満たすことでセキュリティ設計パターンの適⽤用の確認を⾏行う。

4.4 アスペクト指向

アスペクト指向とは、各プログラム(モジュール)から共通に利⽤用される機能のことであり、この機能はさまざまなモジュールにおいて横断的に利⽤用される。そして、モジュールの機能とは独⽴立している[22]。

本研究では、AspectJというアスペクト指向のJava実装を⽤用いてテストテンプレートを作成する。AspectJではモジュールをクラスとしてではなく、アスペクトとして定義し、アスペクトの要素としてポイントカットとアドバイスを持つ。ポイントカットは、「いつアドバイスを実⾏行するのかの指定」を⾏行い、ア

(18)

15

ドバイスは、「ポイントカットで指定されたタイミングで実⾏行する処理」を⾏行う。また、アドバイスが実⾏行可能なポイントをジョインポイントと呼び、ポイントカットにより多数のジョインポイントからアドバイスを実⾏行するジョインポイントを選別する。

本研究では、AspectJによって実装時の内部処理の観測を⾏行い、テストによる検証に⽤用いる。

4.5 テストテンプレート

テストテンプレート作成の⼿手順は以下通りである。

1. セキュリティ設計パターンのOCL記述よりディシジョンテーブルの作成。

2. ディシジョンテーブルとセキュリティ設計パターンで定義された構造より実装時の内部処理を観測するためのアスペクトのテンプレート作成。

3. ディシジョンテーブルとセキュリティ設計パターンで定義された振る舞いよりテストケースのテンプレート作成

テンプレートには「アスペクトのテンプレート」と「テストケースのテンプレート」があり、これらのテンプレートに設計の情報を与えることによってテストを⽣生成することができる。以下に代表的なセキュリティ設計パターンである「Password Design and Use」と「Prevent SQL Injection」を⽤用いてテストテンプレート作成の流れを説明する。

4.5.1

Password Design and Use

Password Design and Useのテストテンプレート作成について説明する。

Password Design and UseはOCL記述により図4.2のように定義されている。

(19)

16

図4.2 Password Design and UseのOCL記述

これは「ユーザがログイン画⾯面から⼊入⼒力したIDとPassがUser DataのIDと Passに⼀一致するものが存在すれば正規ユーザと判断されアセットへのアクセスが可能であり、それ以外であるならばシステムの⾮非正規ユーザと判断されアセットにアクセスが不可能である」ということを定義している。このセキュリティ設計パターンの構造を図4.3に、正規ユーザかどうか判断する振る舞いを図 4.4に、アセットへのアクセスの振る舞いを図4.5に⽰示す。

(20)

17

図4.3 Password Design and Useの構造

(21)

18

図4.4 Password Design and Use の振る舞い(ユーザの判断)

図4.5 Password Design and Use の振る舞い(アセットへのアクセス)

(22)

19

テストテンプレートはOCL記述と構造、振る舞いの図より作成し、テストによってテストケースの振る舞い通りに実⾏行されるかを確認する。テストケースはOCL記述より表4.1のように作成した。

表4.1 Password Design and Use のSITPのディシジョンテーブル

1 2 3 4

条件入力されたＩD が User Data と一致する Yes Yes No No 入力された Pass が User Data と一致する Yes No Yes No

振る舞い

正規ユーザと判断される ×

アセットへのアクセス可能 ×

非正規ユーザと判断される × × ×

アセットへのアクセス不可能 × × ×

表4.1のディシジョンテーブルはテストによって確認するべき対象の決定とテストに必要なテストケースの作成に利⽤用する。

次に、ディシジョンテーブルと設計の構造よりアスペクトのテンプレートを作成する。ディシジョンテーブルよりテストによって確認するべき対象が「正規ユーザか⾮非正規ユーザか判断」と「アセットへのアクセスが可能か不可能か判断」であることがわかる。

「正規ユーザか⾮非正規ユーザか判断」の部分は図4.3の構造の図より

password_design_and_useクラスのcheck_identificationメソッドであることがわかる。この部分のAspectJのポイントカットをLoginCheckと定義し図4.6に⽰示す。

図4.6 ポイントカットLoginCheck

このポイントカットに対するアドバイスからcheck_identificationメソッドの戻り値を取得する。LoginCheckのアドバイスを図4.7に⽰示す。

(23)

20

図4.7 アドバイスLoginCheck

setTemporaryメソッドはAspectJ内で図4.8のように定義している。

図4.8 setTemporaryメソッド

setTemporaryメソッドではアドバイスによって得られたデータを⼀一時保存し

ておくためのものである。⼀一時保存されたデータはテストの時に使⽤用される。

「アセットへのアクセスが可能か不可能か判断」の部分も同様に

Subject_Controlクラスのsubject_functionメソッドであることがわかる。この部分のAspectJのポイントカットをAssetAccessと定義し図4.9に⽰示す。

(24)

21

図4.9 ポイントカットAssetAccess

このポイントカットに対するアドバイスからsubject_functionメソッドの戻り値を取得する。AssetAccessのアドバイスを図4.10に⽰示す。

図4.10 アドバイスAssetAccess

次に、テストケースのテンプレートを作成する。表3.1のディシジョンテーブルと設計の振る舞いより作成する。

図4.4よりユーザの判断の振る舞いが「Login_UI」に対して、アクションとして「id、passを⼊入⼒力」することでregular_userのboolean型が戻り値として与えられることがわかる。テストケースのテンプレートではこの振る舞いを実⾏行し、アスペクトによって保存された値を検証するように作成する。同様に図 4.5のアセットへのアクセスの振る舞いに対してもテストケースのテストテンプレートを作成する。このテストケースにディシジョンテーブルの条件を与えることでテストケースのテンプレートとなる。作成されたテストテンプレートを図4.11に⽰示す。

(25)

22

図4.11 Password Design and Use テストケース(⼀一部)

4.5.2

Prevent SQL Injection

Prevent SQL Injectionのテストテンプレートの作成⼿手順について説明する。

Prevent SQL InjectionはOCL記述により図4.12のように定義されている。

(26)

23

図4.12 Prevent SQL InjectionのOCL記述

これは「Prevent SQL Injection のエスケイプ処理が正しく⾏行われている場合、その⼊入⼒力は正しい⼊入⼒力であり、そうでなければ疑わしい⼊入⼒力である」と読み取ることができる。このセキュリティ設計パターンの構造を図4.13、振る舞いを図4.14に⽰示す。

図4.13 Prevent SQL Injectionの構造

(27)

24

図4.14 Prevent SQL Injectionの振る舞い

OCL記述より表4.2のようにディシジョンテーブルが作成できる。

表4.2 Prevent SQL Injectionのディシジョンテーブル 1 2 条件エスケイプ処理が正しく行われている Yes No

振る舞い

正しい入力と判断される ×

疑わしい入力と判断される ×

(28)

25

表4.2よりPrevent SQL Injectionでテストするべき対象が「^{エスケイプ処理が正} しく行われているか行われていないかの判断」であることがわかる。

「エスケイプ処理が正しく行われているか行われていないかの判断」は図4.9の構造よりprevent_SQL_Injectionクラスのescape_input_dataであることがわかる。この部分のAspectJのポイントカットをEscapeCheckと定義し図4.15に⽰示す。

図4.15 ポイントカットEscapeCheck

このポイントカットに対するアドバイスからescape_input_dataメソッドの戻り値を取得する。EscapeCheckのアドバイスを図4.16に⽰示す。

図4.16 アドバイスEscapeCheck

図4.14よりエスケイプ処理の振る舞いが「UI」に対して、アクションとして何かの「⼊入⼒力」をすることでescape_input_dataのboolean型が戻り値として与えられることがわかる。テストケースのテンプレートではこの振る舞いを実⾏行し、アスペクトによって保存された値を検証するように作成する。このテストケースにディシジョンテーブルの条件を与えることでテストケースのテンプレートとなる。作成されたテストテンプレートを図4.17に⽰示す。

(29)

26

図4.17 Prevent SQL Injectionのテストケース

このように、セキュリティ設計パターンの OCL 記述と構造と振る舞いより形式的にテストテンプレートの作成ができる。作成されたテストテンプレートからテストを⽣生成し、セキュリティ設計パターンの適⽤用検証を⾏行う。

4.6 ケーススタディ

ケースステディとしてEMSsec[13]という学⽣生情報管理システムに対し本⼿手法を適⽤用する。EMSsecは産学の参加者が共同で、セキュリティとプライバシーに関連した開発⼿手法の実験評価のために開発した共通問題である。

最初にセキュリティ設計パターンが適⽤用された設計を作成する。UMLモデリングツールであるastahで作成した設計を図4.18に⽰示す。この設計をxml形式に出⼒力し、TESEMで読み込ませる。読み込ませた結果を図4.19に⽰示す。次にセキュリティ設計パターンが適⽤用されているメソッドを選択し、セキュリティ設計パターンとバインドしていく。今回、EMSsecで適⽤用されているセキ

(30)

27

図4.18 EMSsecの設計

図 4.19 TESEM での EMSsec のクラス図

(31)

28

ュリティパターンは「Password Design and Use」、「Prevent SQL

Injection」、「Prevent XSS」の 3 つのパターンを適⽤用した。これらのセキュリティパターンを適⽤用したメソッドは StudentController クラスの edit、

create、list メソッド、FinishedStudentController の edit、create、list メソッド、InformationController クラスの edit、create、list メソッド、

LoginController クラスの loginCheck メソッドである。

ステップ 1 : 設計の実装を⾏行う。

次にセキュリティ設計パターンの適⽤用された設計の実装を⾏行う。Prevent SQL Injection を適⽤用した実装のコードを図 4,20、4.21 に⽰示す。今回、このパターンでは「ʼ’ (シングルクォーテーション)」「” (ダブルクォーテーション)」

「/ (バックスラッシュ)」の 3 つの⽂文字をそれぞれ「ʼ’ʼ’」「””」「//」へ変換することによってエスケイプ処理が正しく⾏行われたこととする。しかし、図 4.20 ではダブルクォーテーションへの処理が正しく⾏行われていないため SQL Injection の脅威が存在する。また、図 4.21 ではメールアドレスを挿⼊入する処理においてエスケイプ処理が⾏行われていないため SQL Injection の脅威が存在する。そのため、セキュリティパターンが正しく適⽤用されておらず、脆弱性があるといえる。

(32)

29

図 4.20 Prevent SQL Injection の実装の⼀一部(その 1)

(33)

30

図 4.20 Prevent SQL Injection の実装の⼀一部(その 2)

ステップ 2 : テストテンプレートからテストを⽣生成する。

TESEM よりセキュリティ設計パターンの適⽤用をテストするための AspectJ のコードと JUnit のコードを⽣生成する。テスト⽣生成のためには Selenium によるテストするメソッドを含む振る舞いのテストケース、正しい⼊入⼒力セット、脅威になりうる⼊入⼒力セットを TESEM に⼊入⼒力する。⽣生成された AspectJ のコードを図 4.21、JUnit のコードを図 4.22 に⽰示す。

(34)

31

図 4.21 AspectJ のコード

(35)

32

図 4.22 JUnit のコードの⼀一部

(36)

33 ステップ 3 : 実装のテストをする。

ステップ 2 で⽣生成したテストを実⾏行しセキュリティ設計パターンが適切に実装できているか確認する。実⾏行した結果を図 4.23 に⽰示す。この結果からセキュリティ設計パターンが正しく実装されていないことがわかる。また、エラーの結果のテストケースを図 4.24、図 4.25 に⽰示す。エラーの結果のテストケースと成功したテストケースを⽐比較することでセキュリティ設計パターンの実装のバグの箇所が特定できる。testEmssec02、testEmssec03,、testEmssec04 を⽐比較することでダブルクォーテーションを⼊入⼒力した場合のみエラーの結果になっていることがわかる。この結果からダブルクォーテーションの⼊入⼒力時に正しく処理が⾏行われていないことがわかる。また、testEmssec05、testEmssec06、

testEmssec07 を⽐比較し email のフィールドに SQL Injection を引き起こす⽂文字列が⼊入⼒力されることで正しく処理されないことがわかる。以上の結果より、ダブルクォーテーションの⽂文字列を処理している箇所と email フィールドに⼊入⼒力された⽂文字を処理している箇所に問題があることが確認できる。

図 4.23 テスト結果

(37)

34

図 4.24 エラーの結果のテストケース(その 1)

図 4.25 エラーの結果のテストケース(その 2)

ステップ 4 : 実装のリファクタリング

スッテプ 3 の結果よりダブルクォーテーションの⽂文字列を処理している箇所と email フィールドに⼊入⼒力された⽂文字を処理している箇所を正しい処理となるように修正する。図 4.26、図 4.27 に修正したコードを⽰示す。

(38)

35

図 4.26 修正後の Prevent SQL Injection の実装の⼀一部(その 1)

(39)

36

図 4.27 修正後の Prevent SQL Injection の実装の⼀一部(その 2)

(40)

37 ステップ 5 : 実装を再度テストする。

ステップ 4 で修正後のシステムに対して再度テストを実⾏行する。テストの結果を図 4.28 に⽰示す。この結果よりセキュリティ設計パターンが適切に実装されていることがわかる。

図 4.28 修正後のテスト結果

以上の流れより本⼿手法によってセキュリティ設計パターンの実装の誤りを検出し、そのテストの結果より正しい実装の⽀支援を⾏行うことができる。セキュリティ設計パターンを適切に実装することでそのパターンで解決できる脆弱性に関して強固なシステムを構築できる。

(41)

38

第 5 章評価

本章では、EコマースシステムとEMSsecのログインの実装部分に対して本

⼿手法と既存の技術によるセキュリティ設計パターンの誤り検出と修正を⾏行い評価を⾏行う。評価⽅方法として対象システムに3つのセキュリティ設計パターンの実装の誤りを埋め込み、本⼿手法と既存の⼿手法での誤り検出と修正を被験者に実施してもらい、そのテストに掛かった時間を測り、発⾒見・修正できた⽋欠陥箇所を数える。実験後にどちらの⼿手法を被験者は好むのかをアンケートに答えてもらう。

評価ではPassword Design and Useパターン、Prevent SQL Injectionパターン、

の2つのパターンの実装の検証を⾏行う。このシステムに対して以下の実験を⾏行う。

⼿手順1 : 実験前アンケートを⾏行う

⼿手順2 : JUnit、Selenium、本⼿手法の説明を⾏行う

⼿手順3 : 既存⼿手法(本⼿手法)による誤り検出、修正を⾏行う

⼿手順4 : 本⼿手法(既存⼿手法)による誤り検出、修正を⾏行う

⼿手順5 : 実験後アンケートを⾏行う

それぞれの⼿手順について詳しく説明する。

⼿手順 1 : 実験前アンケートを⾏行う

実験を⾏行う前に被験者の能⼒力を測るためにアンケートを⾏行う。アンケートの項⽬目を以下にしめす。

l プログラミング能⼒力はどれくらいですか

l セキュリティに関する知識はどれくらいですか

l ソフトウェアテストに関する知識はどれくらいですか l Webシステムの開発能⼒力はどれぐらいですか

これらの項⽬目に対して、「⾮非常に⾼高い」「⾼高い」「あまり⾼高くない」「低い」

の選択肢より選択してもらう。

⼿手順2 : JUnit、Selenium、本⼿手法の説明を⾏行う

(42)

39

本実験で使⽤用するJUnit、Seleniumと本⼿手法の利⽤用⽅方法について説明を⾏行う。それぞれの⼿手法について被験者と共に具体的なテストを⾏行い、既存⼿手法と本⼿手法の利⽤用⽅方法と実⾏行結果から得られる情報について講義を⾏行う。

⼿手順3、4 : 既存⼿手法(本⼿手法)による誤り検出、修正を⾏行う

⼿手順3、4では被験者にEコマースシステムまたはEMSsecに対して既存⼿手法と本⼿手法を⽤用いたセキュリティ設計パターンの実装の誤り検出とその誤りの修正を⾏行う。⼿手順3、4では既存⼿手法を先に⾏行い本⼿手法をその後に⾏行うグループと本⼿手法を先に⾏行い既存⼿手法を後に⾏行う2つグループに分けて⾏行う。

⼿手順5 : 実験後アンケートを⾏行う

⼿手順3、4でそれぞれ⼿手法を⾏行った後にアンケートを取りどちらの⼿手法を好むのか確認する。アンケートの項⽬目を以下に⽰示す。

l ソフトウェアの誤り発⾒見を⾏行う場合にどちらの⼿手法を好みますか l どちらの⼿手法のほうが効率的に誤り発⾒見できると感じましたか l ソフトウェアの誤り修正においてどちらの⼿手法を好みますか

また、⼿手順2にて⾏行ったJUnit、Selenium、本⼿手法の説明で理解ができたかを確認するため以下の項⽬目にも答えてもらう。

l JUnit, Seleniumの使い⽅方はどれぐらい理解できましたか l 本⼿手法の使い⽅方はどれぐらい理解できましたか

これらの実験を4名に⾏行った。実験前アンケートの結果を表6.1に実験後アンケートの結果を表6.2に⽰示す。

表6.1 実験前アンケートの結果

被験者

プログラミング能⼒力はどれくらいですか

セキュリティに関する知識はどれくらいですか

ソフトウェアテストに関する知識はどれくらいですか

Web システムの開発能⼒力はどれぐらいですか

1 ⾼高いあまり⾼高くない⾼高いあまり⾼高くない 2 あまり⾼高くない低いあまり⾼高くないあまり⾼高くない 3 あまり高くないあまり高くないあまり高くない低い

4 あまり高くない高いあまり高くないあまり高くない

(43)

40

表6.2 実験後アンケートの結果(その1)

被験者

ソフトウェアの誤り発⾒見を⾏行う場合にどちらの⼿手法を好みますか

どちらの⼿手法のほうが効率的に誤り発⾒見できると感じましたか

ソフトウェアの誤り修正においてどちらの⼿手法を好みますか

1 提案⼿手法を好む提案⼿手法提案⼿手法 2 提案手法を好む提案手法提案手法 3 提案手法を好む提案手法

どちらかというと提案手法

4 提案手法を好む提案手法

どちらかというと提案手法

表6.3実験後アンケートの結果(その2)

被験者

JUnit, Seleniumの使い⽅方はどれぐらい

理解できましたか

本⼿手法の使い⽅方はどれぐらい理解できましたか

1 あまり理解できなかった理解できた 2 理解できた理解できた

3 理解できた理解できた

4 あまり理解できなかった理解できた

次に被験者による誤り発⾒見・修正の結果を表6.4、表6.5に⽰示す。

(44)

41

表6.4 被験者による誤り発⾒見結果

被験者回数⼿手法発⾒見時間

テストによる⽋欠陥発⾒見数

1 つあたりの平均発⾒見時間 1

1 回⽬目 JUnit,Selenium 10 分 2 5 分

2 回⽬目提案⼿手法 8 分 3 2.6 分

2

1 回⽬目提案⼿手法８分 3 2.6 分

3

2 回⽬目提案⼿手法 50 分 3 16.6 分

4

1 回⽬目提案⼿手法 11 分 2 5.5 分

表6.5被験者による誤り修正結果

被験者回数⼿手法修正時間修正数

1 つあたりの平均修正時間 1

1 回⽬目 JUnit,Selenium 8 分 3 2.6 分

2 回⽬目提案⼿手法 4 分 3 1.3 分

2

1 回⽬目提案⼿手法 26 分 3 8.6 分

2 回⽬目 JUnit,Selenium 5 分 3 1.6 分 3

2 回⽬目提案⼿手法 22 分 3 7.3 分

4

1 回⽬目提案⼿手法 9 分 2 4.5 分

2 回⽬目 JUnit,Selenium 3 分 2 1.5 分

以上の結果よりRQに答える。

被験者1、3では既存⼿手法を⽤用いた1回⽬目よりも提案⼿手法を⽤用いた2回⽬目の

⽅方が発⾒見時間が短くなっている。また、被験者2、4においても2回⽬目に⾏行った既存⼿手法による発⾒見よりも提案⼿手法を⽤用いた発⾒見の法が発⾒見時間が短くなっている。これらのことからRQ1の既存⼿手法に⽐比べて本⼿手法は効率的にセキュリティ設計パターンの実装の誤りを発⾒見できるかという問いに対してプログラミ

(45)

42

ング能⼒力やWeb開発能⼒力に関係なく既存⼿手法に⽐比べて本⼿手法は効率的に実装の誤りを発⾒見できると結論付けることができる。

テストによる⽋欠陥発⾒見数に関しては、被験者1、2、3では既存⼿手法を⽤用いた場合1つまたは2つの発⾒見であるが本⼿手法を⽤用いた場合に3つすべてのバグを発⾒見できている。被験者4においても既存⼿手法では1つのみの発⾒見であるが、

本⼿手法では2つの⽋欠陥を発⾒見している。これらのことからRQ2の既存⼿手法に⽐比べて本⼿手法は効果的なセキュリティ設計パターンの実装の誤りを発⾒見できるテストを作成できるかという問いに対してプログラミング能⼒力やWeb開発能⼒力に関係なく既存⼿手法に⽐比べて本⼿手法は効果的な実装の誤りを発⾒見できるテストの作成ができると結論付けることができる。

被験者によって作成されたテストを図5.1、図5.2に⽰示す。

図5.1 被験者1によって1回⽬目(既存⼿手法)に作成されたテストの⼀一部

(46)

43

図5.2被験者1によって2回⽬目(本⼿手法)に作成されたテストの⼀一部

図5.1のテストは被験者によってテストを⾏行う毎にテストを書き換え、実施したテストである。そのため、再度同様にテストを⾏行う場合にこのテストを利

⽤用することができない。また、すべてのテストが正しく⾏行われた結果もこのテストからは確認することができない。図5.2のテストはテストケースが再度実施できる状態で作成されている。また、すべてのテストが正しく⾏行うことができたかどうかについても確認することができる。被験者2、4においても既存

⼿手法において再度テストができる状態でテストを作成できていなかった。本⼿手法を⽤用いた場合では被験者全員において再度テストを実施できるテストを作成できていた。これらのことからRQ3の既存⼿手法に⽐比べて本⼿手法は回帰テスト可能なセキュリティ設計パターンの実装の誤りを発⾒見できるテストを作成できるかという問いに対してプログラミング能⼒力やWeb開発能⼒力に関係なく既存⼿手法に⽐比べて本⼿手法は回帰テスト可能なセキュリティ設計パターンの実装の誤りを発⾒見できるテストを作成できると結論付けることができる。

被験者1、2、4において既存⼿手法、本⼿手法ともに誤り修正数に違いはなかった。被験者3では1回⽬目の既存⼿手法による修正では1つ修正のみであったが2 回⽬目の本⼿手法では3つの⽋欠陥を修正することができた。修正時間に関しては既

(47)

44

存⼿手法によるテストを先に⾏行った被験者1、3では2回⽬目の本⼿手法では1回⽬目の約半分の時間で修正できている。本⼿手法によるテストを先に⾏行った被験者 2、4では2回⽬目の既存⼿手法では3分の1以下の時間で修正できている。これらのことからRQ4の既存⼿手法に⽐比べて本⼿手法はセキュリティパターンの実装の誤りの修正を⽀支援することができるかという問いに対してWeb開発能⼒力の低い利

⽤用者に対しては既存⼿手法に⽐比べて本⼿手法は効果的にセキュリティ設計パターンの実装の誤りを修正できると結論付けることができる。しかし、修正に掛かる時間において既存⼿手法よりも多くの時間が掛かると⾔言える。これはTESEMによって⾃自動⽣生成されたテストから修正内容を推測する作業に時間が掛かったためだと考えられる。

(48)

45

第 6 章制限

本章では本⼿手法の制限を述べる。今回、TESEM によって確認したパターンは「Password Design and Use」、「Prevent SQL Injection」、「Prevent XSS」、「Role-Based Access Control」の 4 つのパターンに限られている。これらのパターンはセキュリティパターンの中でも代表的なものを選択した。本⼿手法において適⽤用可能なパターンは設計が具体的に与えれら、対称アプリケーション上で実装が可能なものである。また、セキュリティ設計パターンの実装⽅方法に関して、パターンの定義、構造、振る舞いを正確に実装したことが前提条件となる。

(49)

46

第 7 章おわりに

本稿ではAspectJを⽤用いたテストによるセキュリティ設計パターンの実装⽀支援を提案した。セキュリティ設計パターンは抽象的なパターンであるために実装にどう落としていけばわかりにくいが、本稿ではテストを先に与えテスト駆動開発を⾏行うことでパターンの正しい実装を⽀支援する。具体的には、TESEM というWebアプリケーションを⽤用いてテストテンプレートに設計情報を与えることでテストを⽣生成し、そのテストを満たすように実装を⾏行っていくことでセキュリティ設計パターンの実装⽀支援を可能とした。また、実験によって本⼿手法がパターンの誤り発⾒見やそのためのテスト作成において既存⼿手法よりも効果的であることを確認した。誤り修正においてもWeb開発能⼒力の低い利⽤用者に対しては効果的であることがわかった。

今後の課題としては、今回の実験ではJUnit、Seleniumの経験の浅い被験者による実験を⾏行ったため本⼿手法を⽀支持する意⾒見が多かったが、評価実験におい

てJUnit、Seleniumの熟練者に本⼿手法と既存⼿手法を⽤用いたテストを⾏行った場合

にどちらの⼿手法を好むのかを検証したい。加えて、より複雑な⽋欠陥において本

⼿手法は有効的か評価を⾏行いたい。今回は4つの代表的なパターンにおいてのみの実装⽀支援を⾏行ったが他のパターンにおいても同様な結果が得られるのか検証する必要がある。

(50)

47

謝辞

本研究を進めるにあたり、数々のご指導を頂いた深澤良彰教授、鷲崎弘宜准教授、また、数々のお世話をしてくださった秘書の⼭山崎さんに深く感謝いたします。

また、共に研究に励み、様々な⾯面でご協⼒力いただいた深澤研究室、鷲崎研究室の皆様に深く感謝いたします。

(51)

48

参考文献

[1] 吉岡信和, “セキュリティの知識を共有するセキュリティパターン,” 第巻

9, 第 52, pp. 1134-1139, 2011.

[2] N.Yoshioka、H.Washizaki、K.Maruyama, “A Survey on Security Patterns,” Progress in Informatics、No.5, pp. 35-47, 2008.

[3] M.Schumacher, Eduardo Fernandez-Buglioni, Duane Hybertson, Frank Buschmann and Peter Sommerlad, “Security Patterns: Integrating Security and Systems Engineering John Wiley & Sons,” 2006.

[4] 吉岡信和隆夫, 宗藤誠治, ⼤大久保隆夫, “セキュリティソフトウェア⼯工学の研究動向,” コンピュータソフトウェア Vol.28,No.3, 2011.

[5] “ISO/IEC27001,” http://www.bsigroup.com/ja-JP/ISO27001/ .

[6] 天野勝, 平澤章, 平鍋健児, ⽮矢沢久雄, ⼭山本啓⼆二, “正しく学ぶソフトウェア設計,” ⽇日経BP出版センター, 2005.

[7] 鷲崎弘宜, “ソフトウェアパターン ─時を超えるソフトウェアの道─ ソ

フトウェアパターン概観,” 第巻Vol.52, 第 No.9, 2011.

[8] M.Bishop, “Computer Security: Art and Science, Chapter 29: Program Security,” Addison Wesley, pp. 869-921, 2003.

[9] McGraw, Greg Hoglund and Gary, Secure Coding: Principles and Practices, Chapter 4: Implementation, Oʼ’Reilly, 2003, pp. 99-123.

[10] McGraw,G., Hoglund,G.; Exploiting Software: How to Break Code, Addison-Wesley, 2004.

[11] Mike Whittaker, James A. Andrews, How to Break Web Software, Addison-Wesley, 2006.

[12] “CAPEC,” https://capec.mitre.org.

[13] ⼤大久保隆夫、海⾕谷治彦、鷲崎弘宣、⼩小形真平、柿崎淑郎、櫨⼭山淳雄、吉岡

信和, “セキュリティ，プライバシー向け共通問題 EMSsec の提案,” 研究報告ソフトウェア⼯工学（SE）, 2015-SE-189, pp. 1 - 6, 2015.

[14] Takanori Kobashi, Nobukazu Yoshioka, Haruhiko Kaiya, Hironori

(52)

49

Washizaki, Takano Okubo and Yoshiaki Fukazawa, “ Validating Security Design Pattern Applications Using Model Testing,” ARES, 2013.

[15] R. S. J. Koen Yskout, “Do Security Patterns Really Help Designers?,”

International Conference on Software Engineering, 2015.

[16] TESEM http://patterns.fuka.info.waseda.ac.jp

[17] Dalal,S.R, Jain,A., Karunanithi,N, Leaton,J.M, Lott,C.M, Patton,G.C.

and Horowitz,B.M, “ Model-based Testing in practice, Proc. The International Conference on Software Engineering,” The International Conference on Software Engineering, 1999.

[18] J. B. Tretmans, “ TorX: Automated Model-Based Testing, ” The Conference on Model-Driven Software Engineering, 2003.

[19] Felderer,M, Agreiter,B, BreuR. and Armenteros,A, “Security Testing by Telling TestStories,” The conference on Modellierung, 2010.

[20] ケント・ベック, テスト駆動開発⼊入⾨門, ヒアソン・エテュケーション, 2003.

[21] “Selenium,” http://docs.seleniumhq.org/.

[22] ⻑⾧長瀬嘉秀,天野まさひろ,鷲崎弘宜,⽴立堀道昭, AspectJ によるアスペクト指向プログラミング⼊入⾨門, 2004.

(53)

50

外部発表

l Masatoshi Yoshizawa, Takanori Kobashi, Hiroyoshi Washizaki, Yoshiaki Fukazawa, Takao Okubo, Haruhiko Kaiya and Nobukazu Yoshioka,

“Verification of Implementing Security Design Patterns Using a Test Template,” Proceedings of 9th International Conference on Availability, Reliability and Security (ARES2014), pp.178-183,Fribourg, Switzerland, September 8-12, 2014.

l Takanori Kobashi, Masatoshi Yoshizawa, Hironori Washizaki, Yoshiaki Fukazawa, Nobukazu Yoshioka, Haruhiko Kaiya, Takano Okubo,

“TESEM: A Tool for Verifying Security Design Pattern Applications by Model Testing,” Proceedings of the 8th IEEE International Conference on Software Testing, Verification, and Validation (ICST 2015), Tool Track, Graz, Austria, 13-17 April 2015.

テストテンプレートを⽤用いた

2015 年度 修⼠士論⽂文