25 About what prevent spoofing of misusing a session information

平成

25

年度

学士学位論文

セッション情報を

不正に利用したなりすましを

防止する方式に関する研究

About what prevent spoofing of misusing a session

information

1140349

田原 宏樹

指導教員

清水 明宏

2014

年

2

月

28

日

要 旨

セッション情報を

不正に利用したなりすましを

防止する方式に関する研究

田原 宏樹

近年，コンピュータの脆弱性の中で Webアプリケーション（Webサイト）のクロスサ イトスクリプティングが顕著に多い[1]. クロスサイトスクリプティングは主にクライアン ト側のセッション情報を盗み取り，なりすましに用いる攻撃方法である[2]．そこで，本研 究では，クロスサイトスクリプティングに代表されるセッション情報を盗み取る攻撃でセッ ション情報が漏洩した場合でも，そのセッション情報の正当性をSAS-2(Simple And Secure password authentication protocol, ver.2)[3]を用いて確かめることで，正規クライアント を判断できるシステムの提案，構築をおこなう．

Abstract

About what prevent spoofing of misusing a session

information

Hiroki TAHARA

It’s increasing XSS(cross-site scripting) in a web-application vulnerability recently. XSS is used for one of a misusing session information. And a attacker get spoofing with the misusing session information. In this paper, I have proposed to prevent spoofing using SAS-2(Simple And Secure password authentication protocol, ver.2) to confirm a regular user when a session information leak. And i was to evaluate safety and compare the preceding method.

目次

第1章 序論 1 第2章 既存方式 2 2.1 セッション管理のしくみ . . . 2 2.2 セッションハイジャック . . . 3 2.2.1 セッションの取得方法 . . . 4 セッションIDの推測 . . . 4 セッションIDの盗聴 . . . 5 セッションIDの固定化 . . . 6 2.3 クロスサイトスクリプティング . . . 6 2.3.1 クロスサイトスクリプティングの仕組み . . . 7 2.3.2 クロスサイトスクリプティングの対策 . . . 8 HTMLテキストの入力を許可しない場合の対策 . . . 8 HTMLテキストの入力を許可する場合の対策 . . . 8 全てのウェブアプリケーションに共通の対策 . . . 9 2.3.3 クロスサイトスクリプティングの現状 . . . 10 2.4 既存方式の問題点 . . . 10 セッションIDの正当性を確かめない. . . 11 Cookie領域は漏洩の危険性がある . . . 11 第3章 提案方式 12 3.1 SAS-2認証方式 . . . 12 3.1.1 定義と記述. . . 12 3.1.2 SAS-2プロトコル . . . 13

目次 登録フェーズ . . . 13 認証フェーズ . . . 14 プロトコルの安全性 . . . 17 3.2 SAS-2を用いたセッション管理 . . . 17 3.2.1 定義と記述. . . 18 3.2.2 提案方式の通信及び動作 . . . 18 登録フェーズ . . . 19 認証フェーズ . . . 21 第4章 評価・考察 23 4.1 既存方式の問題点の解決 . . . 23 4.1.1 セッションIDの正当性及び認証情報の安全性 . . . 23 4.1.2 Cookie領域外の認証情報保存 . . . 24 4.2 実装実験 . . . 24 4.2.1 実験構成 . . . 25 4.2.2 動作環境 . . . 25 4.2.3 実験 . . . 27 4.3 考察. . . 28 第5章 終わりに 29 謝辞 30 参考文献 31

図目次

2.1 セッション管理のしくみ1 . . . 2 2.2 セッション管理のしくみ2 . . . 3 2.3 セッションハイジャッのしくみ . . . 4 2.4 セッションIDの推測のしくみ . . . 5 2.5 セッションIDの盗聴のしくみ . . . 5 2.6 セッションIDの固定化のしくみ . . . 6 2.7 クロスサイトスクリプティングのしくみ . . . 7 2.8 クロスサイトスクリプティングの対策 . . . 9 2.9 ウェブサイトの脆弱性関連の届け出の推移 . . . 10 3.1 SAS-2の登録フェーズ. . . 14 3.2 SASプロトコルにおける認証フェーズi回目 . . . 16 3.3 提案手法登録フェーズ . . . 20 3.4 提案手法認証フェーズi回目 . . . 22 4.1 提案手法実装構成 . . . 25

表目次

4.1 サーバ ハードウェア環境 . . . 26

4.2 クライアント ハードウェア環境 . . . 26

4.3 既存方式結果 . . . 27

第

1

章

序論

近年，クラウドコンピューティング（以下「クラウド」）の発展に伴い，個人の生活，企業 間取引や重要なインフラの運用までwebサービスで管理する仕組みが定着しつつある．ク ラウドは，多数のユーザを識別するアカウント管理の機能が必要になる場合が多い．SNS， EC サイト，メールサービスなどはアカウント管理を行うことで個人を識別しサービスを 提供している．そのため，悪意のあるユーザが正規のユーザになりすましがおこなえると， SNSでの発言，ECサイトでの買い物，メールの閲覧・送信等の重大な被害につながること が考えられる． Webサービスのユーザの識別には，一般的にセッション管理を用いておこなわれる．セッ ション管理とは，アクセスをおこなってきたユーザに対してセッションIDを発行し，ユー ザはそのセッション IDをHTTPリクエストとともに送信することによりユーザを識別す る仕組みである．ユーサはセッション IDさえ持っていれば認証をおこなわずにWebサー ビスを利用できるが，このセッションIDが悪意のあるユーザにわたってしまうとなりすま しに利用される可能性がある． そこで本研究では，セッションIDが漏洩した場合でも，なりすましが出来ない仕組みを 提案，実装，評価をおこなう．

第

2

章

既存方式

2.1

セッション管理のしくみ

現在，Webサービスの多くにセッション管理が用いられている．例えば，図2.1の様に， ショッピングサイトにアクセスした際に，最初のWebページでログイン，次のWebページ で注文，更にその次のWebページで決済と言った具合に，何度もWebアクセスを繰り返し ながら処理を進め，最後にログアウトする．このログインからログアウトまでが，ひとつの セッションである．ユーザが意識をしなくても複数のWebアクセスが関連付けられ，前回 までのアクセス結果を元にアプリケーションが処理を進めていくことによってWebページ をまたがったWebサービスを実現している． 図2.1 セッション管理のしくみ1 セッション管理の実現方法はセッションIDをのやりとりで実現する．セッション IDは セッションを識別するための短いデータである．WebサイトがセッションIDを発行しWeb

2.2 セッションハイジャック

ブラウザに預け，一連のアクセスで同じセッション IDを送信することで，同じセッション ID を受けっとたサーバは同一のセッションと認識する．セッションID のやりとりで最も 多く使われているのは，Cookieを使う方法である．図2.2にその動きを示す．Cookieを使 うWebサイトは，Webブラウザに送るHTTPレスポンスの拡張ヘッダに，Cookieとし てセッションIDを書き込んで送る．Cookieを受け取った．Webブラウザは，そのCookie を持っておく．そしてそのWebサイトへの一連のアクセスの際に，HTTPリクエストの拡 張ヘッダにCookieをつけて送信する．Webサイトは，受け取ったCookieに含まれるセッ ションIDでセッションの識別を行うことでセッション管理を実現している．また，Cookie は，Webサイトが指定した有効期限までの間，Webブラウザが保存し続ける．そのため， Webブラウザはこの間，いつWebサイトにアクセスしても同じCookieを送る[4][7]．

図2.2 セッション管理のしくみ2

2.2

セッションハイジャック

セッション管理の仕組みを述べてきたが，セッション管理には設計の段階で潜り込むセ キュリティホールが存在する．それがセッションハイジャックである．セッションハイジャッ クとは，なりすましの一種でありクライアントとサーバの正規セッションに割り込み，セッ ションを奪い取る行為である． セッションハイジャックがおこる仕組みを図2.3で説明する．クライアントAがリクエス

2.2 セッションハイジャック 図2.3 セッションハイジャッのしくみ トを送信（１），セッションIDが発行される（２）．クライアントAがこのセッションID を使ったリクエスト（３）を使って送信するとレスポンス（４）が返ってくる．ところが， 攻撃者が同じセッションIDを使って（３）と同じリクエスト（５）を送信すると，レスポ ンス（４）と同じ内容のレスポンス（６）が攻撃者に返ってくる．そのため，クライアント A しか見られないはずのページが攻撃者も見ることが出来るのである．さらに攻撃者はA になりすまし以降の処理を継続することも可能である．そのため，被害は拡大する可能性が ある．これがセッションハイジャックである．その結果，クレジットカード番号の盗み出し， 無断の買い物，コミュニティからの退会，他のユーザへの犯罪，迷惑行為等，各種被害が生 じうる[2]．

2.2.1

セッションの取得方法

攻撃者がセッションハイジャックを行う上で重要視することがセッションの取得方法であ る．攻撃者は下記の３つの方法を用いてセッションハイジャックをおこなう． セッションIDの推測 攻撃者は，セッションIDの生成規則を割り出し，有効なセッションIDを推測する．

2.2 セッションハイジャック 図2.4 セッションIDの推測のしくみ セッションIDの盗聴 攻撃者は，罠を仕掛けたり，ネットワークを盗聴したりすることで利用者のセッションID を盗む． 図2.5 セッションIDの盗聴のしくみ

2.3 クロスサイトスクリプティング セッションIDの固定化 攻撃者は何らかの方法で自分が取得したセッションIDを利用者に送り込み，利用者のロ グインを狙ってその利用者になりすます． 図2.6 セッションIDの固定化のしくみ 攻撃者にセッションが漏洩する原因は，セッションIDの発行や管理に問題がある場合に である[2]．次節ではセッションIDの盗聴として分類されるクロスサイトスクリプティング について取り上げる．

2.3

クロスサイトスクリプティング

ウェブアプリケーションの中には，検索のキーワードの表示や個人情報登録時の確認内容， 掲示板，ウェブのログ統計画面等，利用者からの入力内容やHTTPヘッダの情報を処理し， ウェブページとして出力するものがある．ここで，ウェブページヘの出力処理に問題がある 場合，そのウェブページにスクリプトを埋め込まれてしまう可能性がある．この問題を悪用 した攻撃方法をクロスサイトスクリプティングと呼ぶ[8][9]．発生しうる脅威としては，以 下の２種類ある． • 本物サイト上にニセのページが表示される

2.3 クロスサイトスクリプティング • ブラウザが保存しているCookieを取得される 本論文では２つ目の「ブラウザが保存しているCookieを取得される」の解決について述べ ていく．

2.3.1

クロスサイトスクリプティングの仕組み

クロスサイトスクリプティングの仕組みを図2.7で説明する．ここではセッションIDが どのように盗まれるかを紹介する．登場人物は正規利用者，攻撃者，脆弱性のあるウェブサ イト，正規ウェブサイトの４つである．まず，正規利用者が罠とは知らず攻撃者の用意した 罠ページを閲覧する（１）．正規利用者がそこにある攻撃者の用意したスクリプト付きの URLをクリックすると脆弱性のあるウェブサイトへ悪意のあるスクリプト付きのリクエス トを送信してしまう（２）．脆弱性のあるウェブサイトは悪意のあるスクリプトを作成して いまい，正規利用者へ本来のページとともに送信する（３）．レスポンスを受け取った正規 利用者は脆弱性のあるウェブサイトを閲覧できるが，裏ではスクリプトが実行される．（４）． スクリプトの内容によっては攻撃者に正規利用者の持つ全てのCookie情報を送信するスク リプトが実行され，セッションIDの漏洩へとつながる（５）． 図2.7 クロスサイトスクリプティングのしくみ

2.3 クロスサイトスクリプティング

2.3.2

クロスサイトスクリプティングの対策

クロスサイトスクリプティングの対策は，主にウェブプログラムを設計・構築する段階で おこなう．図2.8に示すように，対策の種類は３つの種類に分類される[2]． • HTMLテキストの入力を許可しない場合の対策 • HTMLテキストの入力を許可する場合の対策 • 全てのウェブアプリケーションに共通の対策 HTMLテキストの入力を許可しない場合の対策 ウェブページを構成する要素として，ウェブページの本文やHTMLタグの属性値等に相 当する全ての出力要素にエスケープ処理をおこなう．エスケープ処理はウェブページの表 示に影響する特別な文字（「<」，「>」「&」等）をHTMLエンティティ（「&lt;」，「&gt;」， 「&amp;」等）に変換する方法である．これをおこなうことで，スクリプトをHTMLをし

て出力できるため．不正なスクリプトを実行させない効果がある．

HTMLテキストの入力を許可する場合の対策

入力された HTMLテキストに含まれる，スクリプトに該当する文字列を抽出し排除す る．たとえば，「<script>」や「javascript:」を無害な文字列へ変換する場合，「<xscript>」 「xjavascript:」のように，その文字列に適当な文字を付加することで無害化する． し か し ，こ の 方 法 で は ，ブ ラ ウ ザ に よって は「java&#09:script」な ど の 文 字 列 を 「javascript:」と解釈してしまうため単純なブラックリスト方式のパータンマッチングでは 危険な文字列を抽出できない場合が多い．そのため，入力されたHTMLテキストに対して 構文解析を行い，ホワイトリスト方式で許可する要素のみを抽出する方式を取らなければな らない．これには複雑なコーディングが要求され処理に負担がかかるといった影響もある．

2.3 クロスサイトスクリプティング

全てのウェブアプリケーションに共通の対策

HTTPレスポンスヘッダのContent-Typeフィールドには，「Content-Type: text/html: charset=UTF-8」のように文字コード（charset）を指定できる．この指定を省略した場合， ブラウザは，文字コードを独自の方法で推定して，推定した文字コードにしたがって画面表 示を処理する．一部のブラウザにおいては，HTMLテキストの冒頭部分に特定の文字列が 含まれると，必ず特定の文字コードで処理されるという挙動が知られている． Content-Typeフィールドで文字コードの指定を省略した場合，攻撃者がこの挙動を悪用 し，故意に特定の文字コードをブラウザに選択させるような文字列を埋め込んだ上で，そ の文字コードで解釈した場合にスクリプトタグとなるような文字列を埋め込む可能性があ る．具体的な例として，HTMLテキストに「 +ADw-script+AD4-alert(+ACI-test+ACI-)+ADsAPA-/script+AD4-」という文字列が埋め込まれた場合が考えられる．この場合ブ ラウザは「UTF-７」の文字コードでエンコードされた文字列として認識する．これが画面 に表示されると「<script>alter(’test’);</script>」として扱われるため，スクリプトが実行 される．そのため，文字コードの指定をおこなう． 図2.8 クロスサイトスクリプティングの対策

2.4 既存方式の問題点

2.3.3

クロスサイトスクリプティングの現状

図2.9は，IPAのソフトウェア等の脆弱性関連情報に関する活動報告レポートのウェブサ イトの脆弱性関連の過去２年間の脆弱性届け出の推移を示したものである[1]．過去２年間 は「クロスサイトスクリプティング」が届け出の８割以上を占めている．クロスサイトスク リプティングはウェブサイトの脆弱性の中で最も蔓延している脆弱性であることが伺える． 対策は存在するものの，納期や工数の問題でクロスサイトスクリプティングの対策は考慮さ れていない場合が多いのではないかと考えられる． 図2.9 ウェブサイトの脆弱性関連の届け出の推移

2.4

既存方式の問題点

ここでは既存方式における問題点を述べる. 既存の方式は，セッションIDが漏洩しないための対策をおこなってきた．しかし，前節に 示したようにセッションIDの漏洩の可能性は高い数値を示したままである．そこで，セッ ションIDが攻撃者に漏洩したとしてもなりすましを防止出来る新たな方式が必要であると 考える．既存の方式の問題点としては以下の2点があげられる． • セッションIDの正当性を確かめない • Cookie領域は漏洩の危険性がある

2.4 既存方式の問題点 セッションIDの正当性を確かめない 従来のセッションの仕組みでは，セッションIDをサーバに送るとサーバは送られてきた ものをそのまま比較し，一致していれば本人としてレスポンスを返す．この方法では，不正 に入手したセッションIDを送られてきた場合に，不正に入手したセッションIDであると 検知が出来ない．そこで，セッションIDとは別に，送られてきたセッションIDの正当性が 確かめる別の仕組みが必要である． Cookie領域は漏洩の危険性がある

セッションIDはCookieという領域に保存されている．CookieはWebアプリケーショ ンから自由に情報を読み書きできる領域である．そのため，javascriptなどで書かれた不正 なスクリプトを読み込んでしまうと，セッションIDが流出してしまう．また，今の方式は セッションIDがサーバにログインするための認証情報となっている．本来，認証情報は攻 撃者が触れない場所に保存しなければならない．しかし，クロスサイトスクリプティングは Cookie領域が触れてしまうため，認証情報の漏洩へとつながってしまう．Webアプリケー ションから自由に情報を読み書きできない領域であるローカルに認証情報を保存する仕組み が必要である． 以上2点が，既存方式が内在する漏洩の問題点であると考える．

第

3

章

提案方式

前章で，従来のセッション管理の問題点は「セッションIDの正当性を確かめない」「Cookie 領域は漏洩の危険性がある」の２点であると述べた．それらの問題点を解決するために， ワンタイムパスワード認証方式の SAS-2(Simple And Secure password authentication protocol, Ver.2) を用いたアクセスごとにセッション情報の正当性を確かめ，認証情報を ローカルに保存するアプリケーションを提案する． 本章ではSAS-2認証方式の動作と提案方式について述べる．

3.1

SAS-2

認証方式

SAS-2認証方式は，第三者による反射攻撃や中間者攻撃などによるなりすましの危険性 に対して高い安全性を持つワンタイムパスワード認証方式である．認証時に必要となる通信 セッションが２回であり，さらにハッシュ関数や排他的論理和の適用回数が特に少なく，処 理負荷が小さいという特性を持つ．以下に SAS-2認証方式で実行されるプロトコルについ て述べる[3][5][6]．

3.1.1

定義と記述

本稿で用いる定義と記法は以下の通りである． • Userは，認証されるユーザである • Serverは，Userを認証する認証者である • IDは，ユーザの識別子を示す

3.1 SAS-2認証方式 • Sは，ユーザのパスワードを示す • X，F，H，は，一方向性関数を示す．例として，H(x)はxを一方向性関数に適用して 得た出力値を示す．また，この一方向性関数は出力ビットが常に一定とする． • iは，認証セッション毎に加算される数値である • Niは，i回目の認証時に生成される乱数を示す • +は，加算演算子を示す • ⊕は，排他的論理和を示す

3.1.2

SAS-2

プロトコル

SAS-2プロトコルは登録フェーズと認証フェーズで構成される．登録フェーズは一度だ け実行され，認証フェーズはユーザがログインする度に毎回実行される．以下，これらの フェーズを順に説明する． 登録フェーズ SAS-2プロトコルにおける登録フェーズでは，ユーザは初期情報を生成し，安全なルート でサーバへ送信する．図3.1にSAS-2の登録フェーズを示す． 1. ユーザは，自身の識別子 ID，パスワード Sを入力する．それと同時に，乱数N1 を生 成し，保存する．そして，入力されたID，S，生成されたN1 を用い，A=X(ID，S ⊕ N1)を算出する． 2. ユーザは，ID，Aを安全なルートを用いてサーバへ送信する． 3. サーバは，受け取ったID，Aを保存する．

3.1 SAS-2認証方式

User Server

Generates a rondom number N1 and Stores N1 A=X(ΙD,S⊕N1) Stores ID,A ID,Α (secure) Input ID,S 図3.1 SAS-2の登録フェーズ 認証フェーズ SAS-2プロトコルにおける認証フェーズでは，まず，ユーザが生成した認証情報の正当性 をサーバが検証し，ユーザを認証する．次に，サーバが生成した認証情報の正当性をユーザ が検証し，サーバを認証する．これにより，ユーザとサーバでの相互認証が可能である．図 3.2にi回目の認証におけるSAS-2認証フェーズを示す． 1. ユーザは，自身の識別子ID，パスワードSを入力する．そして，入力されたデータと 保存された乱数Niを用い，A=X(ID，S⊕ Ni)を算出する．次に，ユーザは乱数Ni+1 を用い，α=C⊕(F(C)+A)，β=F(C)⊕ Aをそれぞれ求める． 2. ユーザは，ID，α，βをサーバへ送信する．この時使用するネットワークは，インター ネットなど安全でない共通ネットワークを用いても良い． 3. サーバは，受信したβと保存された A を用い，F(C) = β⊕A を算出する．さらに， サーバはC= α⊕(F(C)+A)を算出する．先に算出されたF(C)と，F(ID, C)を比較 し，不一致ならばユーザの認証は不成立となる．一致すれば認証が成立し，以下の処理 が実行される．

3.1 SAS-2認証方式 4. サーバは，保存されたA の代わりとしてCを保存し，次回認証に備える．さらに，γ = H(ID,F(C))を算出する． 5. サーバは，γをインターネットなどを通じてユーザへ送信する． 6. ユーザは，H(ID,F(C))を算出し，受信したγと比較する．もし一致すれば，サーバは ユーザに認証される．不一致ならば，認証は不成立となる．

3.1 SAS-2認証方式

User Server

Data strages : Ni _{Data strages : ID,A}

Generates a rondom number Ni+1

and stores Ni+1

C=X(ΙD,S⊕Ni+1) F(C)=F(ID,C) α=C⊕(F(C)+Α) β=F(C)⊕Α F(C)=β⊕Α C=α⊕(F(C)+Α) F(C)=F(ID,C)? ID,α,β A=C γ=Η(ΙD,F(C)) γ=H(ID,F(C))? True True Authentication fail True Authentication fail False γ Input ID,S A=X(ΙD,S⊕Ni) 図3.2 SASプロトコルにおける認証フェーズi回目

3.2 SAS-2を用いたセッション管理 プロトコルの安全性 ワンタイムパスワード認証方式に対する攻撃法として，反射攻撃による成りすましが考え られる．反射攻撃では，正当なユーザによる認証が行われた際に送受信された情報を，悪意 ある第三者が通信経路中で盗聴し再利用する．正当なユーザがSAS-2による(i+1) 回目の 認証を行う際に，ユーザが送信する情報を以下に示す． α= E⊕ (F (E) + C) β= F (E)⊕ C ID この時，悪意ある第三者が成りすまし攻撃を実行する場合，以下の情報を送信しなければ ならない. α′ = x⊕ (F (x) + C) β′ = F (x)⊕ C ID 第三者が，たとえi回目以前での認証情報を全て取得できたとしても，これら認証情報の 組み合わせを生成することは不可能である．以上より，SAS-2プロトコルによる認証は安全 であると言える．

3.2

SAS-2

を用いたセッション管理

既存方式の問題として述べた２点を解決するために，セッション管理にSAS-2認証方式 を適応した方式を提案する． 以下に提案方式の処理について述べる．

3.2 SAS-2を用いたセッション管理

3.2.1

定義と記述

提案方式の説明で用いる定義と記述は以下の通りである．

• Applicationは，ユーザが使用するWeb browserと連携したアプリケーションである

• Web browserは，ユーザが使用するWebブラウザである

• Web serverは，ユーザがサービスを受けるwebアプリケーションを提供しているサー

バのことである

• Qは，ユーザがwebサーバのサービスを受けるために入力したログイン情報である

• P は，サーバがユーザを認証するためにアカウント作成時に作成したログイン情報で ある

• Iは，サーバが発行するセッションIDである．Web browserのCookieに保存される

• Rは，HTTPレスポンスである．サーバが提供するコンテンツを示す • X，F，H，は，一方向性関数を示す．例として，H(x)はxを一方向性関数に適用して 得た出力値を示す．また，この一方向性関数は出力ビットが常に一定とする． • iは，認証セッション毎に加算される数値である • Niは，i回目の認証時に生成される乱数を示す • +は，加算演算子を示す • ⊕は，排他的論理和を示す

3.2.2

提案方式の通信及び動作

提案方式は，SAS-2プロトコルと同様に，登録フェーズと認証フェーズで構成される．登 録フェーズは，セッションIDが発行されていない状態のみ実行され，認証フェーズはユー ザがサーバにアクセスするたびに実行される．

3.2 SAS-2を用いたセッション管理 登録フェーズ 提案方式における登録フェーズでは，ユーザがセッションIDを持っていない状態の場合 に，アプリケーションが初期認証情報を生成し，ブラウザを経由してサーバへ送信する．図 3.3に提案方式の登録フェーズを示す． 1. アプリケーションは，乱数N1 を生成し，保存する．そして，A=X(N1)を算出する． 2. ユーザがサーバを訪れ，ログイン情報 Qを入力する．それと同時に A が読み込まれ， サーバにQとAを送信する．この通信は安全な通信とする． 3. サーバは，受け取ったQを自信が保存しているログイン情報Pと比較し，一致すれば 認証が成立し以下の処理が実行される． 4. サーバは，認証が成功したユーザに対してセッション IDIを生成する．そしてI とA を保存する． 5. サーバは，HTTPレスポンスRとセッションIDIをユーザに返す． 6. 受け取ったブラウザは，IをCookieに保存する．それと同時に，アプリケーションへI を送信する．

3.2 SAS-2を用いたセッション管理

3.2 SAS-2を用いたセッション管理 認証フェーズ 提案方式における登録フェーズでは，まず，アプリケーションが認証情報を生成し，ブラ ウザがサーバにアクセスをおこなうとブラウザはアプリケーションを読み込み，サーバに認 証情報とセッションIDを送信する．次に，サーバはユーザから受信した認証情報を用いて セッションIDの正当性を検証し，認証をおこなう．サーバは，認証情報から返信用の認証 情報を作成し，ユーザが返信用の認証情報を検証する．図3.4にi回目の認証における提案 方式の認証フェーズを示す． 1. アプリケーションは保存されている乱数Ni を用い，A=X(Ni)を算出する．次にアプ リケーションは，次回用認証情報に乱数 Ni+1 を生成し，保存する．さらに，アプリ ケーションはC=X(Ni+1)を生成し，α = C ⊕ A，β = (F(C) + A) ⊕ Aをそれ ぞれ求める． 2. ブラウザが，サーバへアクセスをすると，それと同時にα，βが読み込まれ，サーバに セッションIDI，α，βが送信される． 3. サーバは受信したαと保存しているAを用いα = α⊕ Aを算出する．算出されたα をCに保存する．さらに，サーバはβ = β⊕ (F(α) + A)を算出する． 4. 算出されたβと保存している Aを比較し，不一致ならば認証不成立となる．一致すれ ば認証が成功し，以下の処理が行われる． 5. サーバは保存されているAの代わりとしてCを保存する．さらに，返信用認証情報と してγ = (A)を算出する． 6. サーバは，HTTPレスポンスRとγをユーザへ送信する． 7. ユーザはH(F(X(Ni)))を算出し，受信したγ と比較する．不一致ならば，Cookieが 破棄される．一致すれば，保存されたNi がNi+1 に置き換わる．

3.2 SAS-2を用いたセッション管理

第

4

章

評価・考察

本章では提案方式の既存方式に対する優位性や実装実験による既存方式との速度比較・評 価・考察をおこなう．

4.1

既存方式の問題点の解決

２章で述べたように，既存方式には以下の２点の問題点が存在していた． • セッションIDの正当性を確かめない • Cookie領域は漏洩の危険性がある 提案方式ではこの２点を解決した．

4.1.1

セッション

ID

の正当性及び認証情報の安全性

提案方式では，セッションIDの正当性をα，βの２つの情報を認証することによって正 当性を確かめている．このα，βの安全性は，登録フェーズにおいては通信に暗号通信を用 いることを想定とするため盗聴における漏洩は安全であるといえる．認証フェーズについて の安全性を以下に示す． 認証フェーズの（i +1）回目の生成時にやりとりされる認証情報は以下の通りである． α= E⊕ (F (E) + C) β= F (E)⊕ C

4.2 実装実験 この時，悪意のある第三者がなりすましの攻撃を実行する場合は，以下の情報を送信しな ければならない． α′ = x⊕ (F (x) + C) β′ = F (x)⊕ C 第三者が，i回目以前で通信路を流れる情報を全て取得できたとしても，これらの認証情 報の組み合わせを生成することは不可能である．したがって認証フェーズも安全性であると いえる． さらに，提案方式は，上記で示したように盗聴におけるなりすましに強いため，暗号通信 をおこなっていない通信に対しても安全性が保てる．このため，公衆LANの悪意のある盗 聴によるなりすましを防ぐ効果がある． 以上の評価により，安全にセッションIDの正当性を確かめることが可能である．

4.1.2

Cookie

領域外の認証情報保存

既存方式はCookieの中にセッション IDという認証情報を保存していたが，提案方式で は，認証情報をCookieとは別の場所に保存している．そのため，スクリプトから自由に触 れるCookieに認証情報を保存しないことによって，安全性を高めている．また，Cookie内 に保存される情報は，セッションIDと返信用情報（γ）のみである．i回目以前の通信路を 流れる情報を全て取得し，Cookie無いの情報を全て取得できたとしても，これらの情報で 認証情報を生成することは不可能である．このことから，クロスサイトスクリプティングで Cookie内の情報を盗聴される脅威は解決できたといえる．

4.2

実装実験

提案方式の開発をおこない，従来方式との速度比較をおこなう．

4.2 実装実験

4.2.1

実験構成

クライアント側の開発言語は java を用いる．java からHTTP 通信を行うにはjava の APIであるHttpURLConnectionクラスを用いて行う．このHttpURLConnection部分を ブラウザとする．クライアントのアプリケーション部分は認証情報の生成・保存，サーバの 認証をおこなう． 認証情報の送受信はクライアントからサーバからの送信情報（A，α，β）はPOSTを使 用．サーバからクライアントへの送信情報（γ）はCookieを使用する． サーバ側の開発言語はPHPを用いる．この時，POSTで送られてきた送信情報（A，α， β）があれば認証をおこない，認証が成功すればセッション管理を行う．成功しなければ セッション管理が行われない．サーバは，認証情報の保存，クライアントの認証，返信情報 の生成・送信をおこなう． また，認証情報の鍵長が160bit，認証情報生成に用いたハッシュ関数がSHA１，そして アクセス毎に認証が行われる．全体の構成を図4.1に示す． 図4.1 提案手法実装構成

4.2.2

動作環境

表4.1，4.2に，実験時の各構成要素の動作環境を示す．

4.2 実装実験

H/W用件 名称

OS centos 64bit PHP php5.3

CPU 2.4GHz intel Coure 2 Duo

メモリ 480Mb

表4.1 サーバ ハードウェア環境

H/W用件 名称

OS mac osx 10.6 java JDK1.6

CPU 2.4GHz intel Coure 2 Duo メモリ 4Gb

4.2 実装実験

4.2.3

実験

クライアント側でURLが読み込まれてから，表示が完了するまでの時間を測定する．提 案手法は，提案手法の実行速度，提案手法からSASのAPIを取り除いたもの実行速度の2 種類のデータを取得する．時間測定にはjavaのAPIのcurrentTimeMillisの差分で実行速 度を求める．実験回数は，100回の読み込みを10回おこなう． 既存手法はGoogle Chrome を用いで SSL通信をおこなった場合と通常の HTTP通信 を行った場合の2種類のデータを取得する．速度測定にはGoogle Chromeのディベローッ パーツールを用いる．実験回数は，1000回の読み込みをおこなう．表4.3，4.4にその結果 を示す． 平均値 HTTP（ms/アクセス） 17.4 SSL（ms/アクセス） 41.8 上記2つの差分（ms/アクセス） 24.4 増加率（％） 140.2 表4.3 既存方式結果 数値全体 1回目アクセス 2回目以降アクセス SASなし（HTTP）（ms/アクセス） 105.5 119.2 105.4 SASあり（ms/アクセス） 248.5 259.1 248.4 上記2つの差分（ms/アクセス） 143.0 139.9 143.0 増加率（％） 135.5 117.46 135.7 表4.4 提案手法結果

4.3 考察

4.3

考察

提案手法はセッションID取得によるなりすましに強い．そのため，クロスサイトスクリ プティングによるセッションID取得のなりすまし攻撃もCookieの中に認証情報がないた め防ぐことが可能である．このことは，クロスサイトスクリプティングに限らず，セッショ ンIDだけの取得ではなりすましが不可能なことを示す． 既存方式のSSLは，通信路の盗聴には強いが，クロスサイトスクリプティングによるセッ ションID取得には対処が出来なかった．提案方式ではセッションIDが取得されてもなり すましが防げることから安全性の面で，提案手法の方が有効であると考えられる． 実行速度は，上記の結果でもわかるように既存方式のSSLが41.8（ms／アクセス）に対 し，提案手法のSASありが248.5（ms／アクセス）という結果になった．現時点ではSSL の方が6倍近く早い結果である．しかし，提案手法のSASなしは通常のHTTP通信とみな すことが出来る，そのため，提案方式のHTTP通信が既存方式のHTTP通信同じ速度を 出すことができれば，増加率の結果から（140.2-135.5）提案方式はSSLと比べて，4.7％の 速度削減が見込める結果となる．

第

5

章

終わりに

本稿では，SASを用いてセッションIDが漏洩した場合でも，正規クライアントのみを判 断できるセッション管理の手法を提案・実装・速度測定をおこない，SSLとの比較を述べた． 提案方式では，従来セッションIDが認証情報の役割を果たしていたものを，別の認証情 報の用いることでセッション情報の正当性を確かめるという考え方を導入し，それと合わせ ワンタイムパスワードをもちいることで，セッションIDが第三者に渡ったとしてもなりす ましを防ぐことを可能にした．また，クロスサイトスクリプティングでCookie情報を取得 されたとしても，Cookieとは別の場所に認証情報を保存することにより認証情報の漏洩を 防ぎ，なりすましを防ぐことも可能となった． 今後の課題として，提案方式を実際に導入するにはサーバ側とクライアント側両方に導入 をおこなうため，コストやより一般的に用いれるようにするための開発を検討する必要があ る．また，今回はクライアント側のブラウザをjavaで開発したが今後はGoogle Chrome， fire fox等のブラウザのアドオンでの開発をおこない．より一般的に使っていけるようにし ていく工夫が必要である．

謝辞

本研究の遂行と論文作成にあたって，言葉では言い表せないほどのご指導，御助言をいた だきました高知工科大学情報学群学群長 清水明宏教授に心より感謝し厚く御礼申し上げま す．最後に，有益な議論を交わして頂いた高知工科大学 清水研究室の関係者各位に深く感 謝いたします．

参考文献

[1] IPA, ”ソ フ ト ウェア 等 の 脆 弱 性 関 連 情 報 に 関 す る 届 出 状 況,” http://www.ipa.go.jp/security/vuln/report/vuln2012q3.html, 2012.

[2] IPA, ”安全なウェブサイトの作り方 改正第 6版,” 独立法人 情報処理 推進機構, pp.22-28, 2012.

[3] T.Tsuji, A.Shimizu, ”A one-time password authentication method for low spec machines and on internet protocols,”IEICE Trans.Commun., vol.E87-B, no.6. pp.1594-1600, 2004.

[4] 山本陽平, ”Webを支える技術 : HTTP、URI、HTML、そしてREST,” 技術評論 社, pp.80-87, 2010.

[5] 中原 知也, ”ワンタイムパスワード認証方式 SAS-2 を 適用したネットワーク機器開 発,” 高知工科大学大学院 フロンティア工学コース, 修士学位論文, pp.31-34, 2007. [6] 小西 竜也, ”SAS認証を用いたWeb通信方式,” 高知工科大学 情報システム工学科,

学士学位論文, pp.19-33, 2003.

[7] IETF, ”HTTP State Management Mechanism,” http://www.hcn.zaq.ne.jp/WEB/RFC6265-ja.html, 2013. [8] 高橋 裕樹, オマール イスマイル, 門林 雄基, 山口 英, ”クロスサイトスクリプティング 脆弱性の自動判定・収集システムの提案と実装,”奈良先端技術大学院大学 情報科学研 究科, pp.31-32, 2003. [9] 福田 洋治, 白石 善明, 森井 晶克, ”www上の安全なセッション管理手法の提案,: 徳島 大学 工学部 知能情報工学科, pp.22-24, 2005. [10] 高木浩光, 関口智嗣, 大蒔和仁, ”クロスサイトスクリプティング攻撃に対する電子商取 引 サイトの脆弱さの実態とその対策,” 社団法人情報処理学会, 2001.