以下、本発明に係る悪性ウェブコード判別システムの一例であるウェブコード判別サーバ(悪性ウェブコード判別システム、ウェブサーバ)について、図面を参照して説明を行う。
図1は、ウェブコード判別サーバ(以下、サーバとする。)が、ネットワークを介してクライアントに接続された様子を示した概略図である。サーバ1は、ネットワーク接続機能(後述する通信部など)を備えており、このネットワーク接続機能を利用することによりネットワーク2を介して接続されるクライアント3へ、さまざまなウェブ情報(ウェブページ、動画、音楽など)を提供することが可能となっている。
ネットワーク2は、世界的に広く公開されており、数多くの人たちと情報の送受信を行うことが可能なインターネットであってもよく、また、一定のユーザに情報の送受信が限定されるLAN(ローカルエリアネットワーク)であってもよい。
クライアント3には、サーバ1と同様にネットワーク接続機能が設けられており、ネットワーク2を介してサーバ1へウェブ情報の要求を行ったり、サーバ1より提供されたウェブ情報を取得することが可能となっている。具体的に、一般的なクライアント3には、ブラウザがインストールされている。ユーザが、ブラウザに対して所定のURLやコメントなどを入力し、所定のアクションを行うことによって、サーバ1への様々な要求を行うことが可能となっている。また、サーバ1より提供されたウェブ情報をクライアント3で取得した場合には、ブラウザにウェブ情報を表示することが可能となっている。
サーバ1は、所謂、ウェブサーバに該当し、ネットワーク2を介してクライアント3より取得した要求に応じてウェブ情報を提供することが可能となっている。サーバ1からクライアント3に対して提供されるウェブ情報は、例えば、クライアント3のブラウザにおけるURL入力欄に入力されたURLに基づいて判断され、また、ブラウザに表示されたウェブページのコメント入力欄への入力内容等に応じて判断される。
なお、図1には、説明の便宜上、サーバ1とクライアント3とが1台ずつしか示されていないが、サーバ1およびクライアント3の接続台数はそれぞれ1台ずつには限定されず、複数台ずつ接続されるものであってもよい。
図2は、サーバ1の概略構成を示したブロック図である。サーバ1は、ディスプレイ部11と、入力操作部12と、本体部13とを有している。
ディスプレイ部11は、本体部13における処理内容を、ユーザに対して視認可能に表示させる役割を有している。ディスプレイ部11には、液晶ディスプレイや、CRTディスプレイなどの一般的な表示装置が用いられる。また、入力操作部12は、ユーザがサーバ1の本体部13に対してデータ等の入力を行う場合に操作される入力手段であって、例えば、キーボードやマウスなどの一般的な入力デバイスによって構成される。
なお、本実施の形態に係るサーバ1においては、ディスプレイ部11や入力操作部12が設けられているが、サーバ1としての機能を確保するためには、本体部13のみが少なくとも設けられていればよいため、ディスプレイ部11や入力操作部12は必要に応じて省略することも可能である。
本体部13は、制御部(文字列分割手段、文字列抽出手段、特徴ベクトル生成手段、判別手段)20と、データ記憶部21と、通信部22とを有している。
データ記憶部21は、ハードディスク、SSD(Solid State Drive)などの補助記憶装置により構成されている。データ記憶部21には、制御部20において実行される悪性ウェブコードの判別処理に関するプログラムが記録されている。また、データ記憶部21は、クライアント3からの要求に応じてクライアント3に提供するウェブ情報が記録されている。
通信部22は、制御部20の指示に従って、ネットワーク2を介してクライアント3にウェブ情報を送信すると共に、クライアント3より受信したウェブ情報の要求(要求情報)を受信する役割を有している。通信部22は、LANボードやLANカードなどの一般的なNIC(Network Interface Card)により構成されている。
制御部20は、データ記憶部21に記録されるプログラムに従って、後述する悪性ウェブコードの判別処理を行う役割を有している。従って、制御部20は、プログラムに基づいて悪性ウェブコードの判別処理を行う分類部40としての機能を有している(後述する図3参照)。
また、制御部20は、通信部22を介して受信されたクライアント3からのウェブ情報の要求(要求情報)に応じて、ウェブ情報を、通信部22を介して提供する処理を行うことが可能となっている。
制御部20は、CPU(Central Processing Unit)30と、RAM(Random Access Memory)31とを有している。CPU30は、制御部20における悪性ウェブコードの判別処理を実質的に実行する役割を有している。RAM31は、CPU30の処理に利用されるワークエリアとして用いられる。
次に、制御部20のCPU30による悪性ウェブコードの判別処理について説明する。CPU30は、データ記憶部21に記録されるプログラムに従って、悪性ウェブコードの判別処理を実行する。
悪性ウェブコードとして、SQLインジェクションとクロスサイトスクリプティングとが知られている。これらの悪性ウェブコードを防ぐ手段がいくつか存在するが、その代表的な手法がサニタイジングである。
SQLインジェクションにおけるサニタイジングでは、SQLインジェクションを行う場合に主として必要とされる一定の文字データに対して、エスケープ処理を施す方法を用いる。例えば 「’(シングルクォーテーション)」は、SQLのクエリにおいて、文字列を表現する場合に用いられる記号(文字)である。例えば、「‘テスト’」のように 「‘」「’」を「テスト」の文字の前後に付加することによって、SQLのクエリ内で文字列と判断されて文字列として扱われることになる。
エスケープ処理を施す場合には、対象となる文字の前に「¥(バックスラッシュに相当する文字)」を付加することで、SQLクエリ内で対象となる文字データを文字列として処理できるようにする。例えば、「’」を「¥’」とすることで、SQLクエリ内では文字列を表現するための文字ではなく単なる文字として扱われることになる。
クロスサイトスクリプティングにおけるサニタイジングでは、JavaScriptの生成に必要な「<」や「>」を「%lt;」や「>」のようにHTML実体参照文字列に変換する事によって、JavaScriptとして認識されないようにするための処理を行う。
また、悪性ウェブコードを防ぐ手段として、ホワイトリストやブラックリストを用いる防衛手法も知られている。ホワイトリストは、サーバ1における処理を許可する文字列を予め決めたものである。サーバ1の制御部20では、ネットワーク2を介してクライアント3より取得(受信)した文字列が、許可された文字列(ホワイトリストの対象となる文字列)であれば、受信した文字列に応じた通常の処理を行い、許可された文字列でなければ(ホワイトリストの対象とならない文字列の場合には)、取得(受信)した文字列に対する通常の処理を行わないような対処を行う。
ブラックリストは、サーバ1における処理を許可しない文字列を予め決めたものであり、クライアント3から取得(受信)された文字列が、許可しない文字列(ブラックリストの対象となる文字列)であれば、サーバ1の制御部20において、受信した文字列に対応する処理を行わないような対処を行う。
このようなサニタイジング処理を用いることによって、効果的に悪性ウェブコードの攻撃を防衛する事はできるが、ブロックされた文字列が悪意のあるものであったか否かという判別をすることはできない。この点はホワイトリストによる防衛手法にも共通することであり、ホワイトリストによってブロックされた文字列が悪意のあるものであったか否かは、ホワイトリストのリスト一覧によって判別することが不可能である。
このため、サニタイジング処理やホワイトリストによる防衛手法では、制御部20のCPU30において、受信された文字列データが悪意のあるものであるか否かを積極的に判定させ、その判定結果に応じて悪性ウェブコードの攻撃に柔軟に対応することが不可能であった。
本実施の形態に係るサーバ1の制御部20では、ネットワーク2を介してクライアント3より取得した文字列データが悪意のあるものであるか否かを判断し、その判断結果に応じて効果的に悪性ウェブコードの攻撃を防衛する方法を実現する。
図3は、悪性ウェブコードの判別処理のために制御部20において行われる処理を機能ブロックで示したものである。制御部20では、データ記憶部21に記録されるプログラムに基づいて分類部40として機能する。より詳細に説明すると、制御部20は、字句解析部(文字列分割手段、文字列抽出手段)41と、数値割当部42と、特徴ベクトル生成部(特徴ベクトル生成手段)43と、機械学習部44と、判定部(判別手段)45とを有している。
字句解析部41は、ユーザがブラウザのコメント入力欄(入力フォーム)などに入力した文字列データ(入力フォームのデータ)を分割し、分割された文字列をトークン化する役割を有している。ここで、トークンとは、プログラミング言語のソースコードを構成する単語や記号の最小単位を意味する。従って、字句解析部41は、ウェブサイト(ウェブページ)を構成するHTML言語などのソースコードを文字列データとして捉え、一定の分割パターンに従って文字列データを分割し、分割した文字列の中からソースコードを構成する単語や記号の最小単位となる文字列を求めてトークンとして文字列を抽出する役割を有している。
本実施の形態に係るサーバ1では、字句解析部41において文字列データを分割し、トークン化する処理を行うに際し、取得した文字列データがSQLインジェクションに該当する文字列か、クロスサイトスクリプティングに該当する文字列かの2種類の判断を行う。このため、字句解析部41は、SQLインジェクションに該当するか否かの判断を行うために用いられるSQLインジェクション用分割部(文字列分割手段)51とSQLインジェクション用トークン処理部(文字列抽出手段)52とを有し、さらに、クロスサイトスクリプティングに該当するか否かの判断を行うために用いられるクロスサイトスクリプティング用分割部(文字列分割手段)53とクロスサイトスクリプティング用トークン処理部(文字列抽出手段)54とを有している。
文字列データに対してSQLインジェクションの判断処理を行う場合には、SQLインジェクション用分割部51において文字列データの分割処理を行い、分割処理された文字列を、SQLインジェクション用トークン処理部52でトークン化する処理を行う。一方で、文字列データに対してクロスサイトスクリプティングの判断処理を行う場合には、クロスサイトスクリプティング用分割部53において文字列データの分割処理を行い、分割処理された文字列を、クロスサイトスクリプティング用トークン処理部54でトークン化する処理を行う。これらの分割処理およびトークン化処理については後述する。
数値割当部42は、トークン化処理された文字列に対して、トークンのカテゴリ毎に数値割り当てを行う役割を有している。さらに特徴ベクトル生成部43においては、数値割当部42において数値割り当てされた文字列について、トークンのカテゴリをベクトルの向きとし、数値割り当てされた値をベクトルの長さとして、特徴ベクトルを生成する役割を有している。この特徴ベクトルを生成することにより、取得された文字列データがSQLインジェクションに該当し得るデータであるか、あるいは、クロスサイトスクリプティングに該当し得るデータであるか否かの判断を行うことが可能となる。
機械学習部44は、SQLインジェクションおよびクロスサイトスクリプティングに該当する悪性ウェブコードの特徴ベクトルと、悪性ウェブコードに該当しない文字列(無害な文字列)の特徴ベクトルとに基づいて、悪性ウェブコードに該当するか否かの判別を行うための機械学習を行う役割を有している。
判定部45は、特徴ベクトルに基づいて悪性ウェブコードに該当するか否かの判定を行う役割を有している。判定部45では、機械学習部44における機械学習の学習結果に基づいて文字列の特徴ベクトルを分類し、悪性ウェブコードに該当するか否かの判断を行う。
次に、具体的に、入力された文字列からSQLインジェクションとクロスサイトスクリプティングとの判別を行う方法について説明を行う。
SQLインジェクションとクロスサイトスクリプティングとの判別を行うために、制御部20は、入力された文字列データを所定のルールに従って複数の文字列に分割してカテゴリ別(文字列の種類別)に分ける処理を行う。制御部20におけるこの分割処理は、SQLインジェクションとクロスサイトスクリプティングとに関してそれぞれ行われる。制御部20は、SQLインジェクション用の分割処理を行うことから、上述したSQLインジェクション用分割部51として機能し、また、クロスサイトスクリプティング用の分割処理を行うことから、上述したクロスサイトスクリプティング用分割部53として機能することになる。
さらに、分割された文字列に基づいて、トークン化処理を行うことにより、文字列のカテゴリ(種類)に応じて文字列の分類を行う。制御部20では、このトークン化処理を、SQLインジェクションとクロスサイトスクリプティングとに関してそれぞれ行う。このため、制御部20は、SQLインジェクション用のトークン化処理を行うSQLインジェクション用トークン処理部52として機能し、また、クロスサイトスクリプティング用のトークン化処理を行うクロスサイトスクリプティング用トークン処理部54として機能することになる。
(1)字句解析部による文字列の素性抽出
本実施の形態において字句解析部41とは、一般的にプログラミング言語で記述されたソースコードを構成する文字の並びを、トークンの並びに変換する処理を行うものを意味する。本実施の形態に係るサーバ1では、ウェブサイトに入力された文字列からSQLインジェクションの特徴を示す素性とクロスサイトスクリプティングの特徴を示す素性を抽出する。このため、字句解析部41は、SQLインジェクション用の字句解析機能(SQLインジェクション用分割部51およびSQLインジェクション用トークン処理部52)とクロスサイトスクリプティング用の字句解析機能(クロスサイトスクリプティング用分割部53およびクロスサイトスクリプティング用トークン処理部54)とを有している。
ここで、SQLインジェクション用に設けられるSQLインジェクション用分割部51の文字列データの文字列分割パターン(分割ルール)と、クロスサイトスクリプティング用に設けられるクロスサイトスクリプティング用分割部53の文字列分割パターン(分割ルール)とは、それぞれ異なる分割パターンとなっている。
SQLインジェクションの特徴を示す素性とクロスサイトスクリプティングの特徴を示す素性とを抽出する場合において、SQLインジェクション用分割部51やクロスサイトスクリプティング用分割部53をそのまま用いて素性の抽出に利用するのでは、悪性ウェブコードの素性を効果的に抽出することが困難である。このため、制御部20では、SQLインジェクションやクロスサイトスクリプティングを行う場合に頻繁に利用される文字列に注目し、これらの文字列に対しては、既存の字句解析により求められるものと異なるトークンを抽出する。
図4(a)に示す例1は、SQLインジェクションに該当し得る文字列データの例を示したものであり、図4(b)に示す例2は、クロスサイトスクリプティングに該当し得る文字列データの例を示したものである。また、ウェブサイトに入力される文字列には一般的な利用者が入力するような無害な文字列が含まれることが多い。図4(c)に示す例3は、このような無害な文字列のデータを示している。
SQLインジェクションやクロスサイトスクリプティングに該当し得る文字列、又は無害な文字列から素性を抽出するためには、まず、制御部20において、図5(a)に示した例4や、図5(b)に示した例5のような文字列分割パターン(分割ルール)を用いて、予め規定される文字列に適合する文字列を、該当する文字列毎に分割する処理を行う。制御部20では、例4の文字列分割パターンに基づいて文字列の分割を行うことにより、SQLインジェクションに対応する文字列の分割処理を行うことが可能となっている。また、同様に、制御部20では、例5の文字列分割パターンに基づいて文字列の分割を行うことにより、クロスサイトスクリプティングに対応する文字列の分割処理を行うことが可能となっている。
なお、図5(c)に示す例6は、「‘ or 1=1; ――」からなる文字列データを分割前の文字列データとし、この文字列データのうち空白文字(スペース)が存在する場合に、空白文字を境界として文字列データの分割を行うという分割パターンを用いて、文字列データの分割処理を行った例を示したものである。例6に示すように空白文字の存在を基準として文字列データの分割を行う方法を用いることも可能である。しかしながら、例4に示すような手法で文字列データの分割を行うことにより、SQLインジェクションの判定精度を向上させ得るような分割処理を行うことができ、また、例5に示すような手法で文字列データの分割を行うことにより、クロスサイトスクリプティングの判定精度を向上させ得るような分割処理を行うことができる。
具体的に、例4や例5に示す文字列分割パターンでは、分割対象となる規定の文字列の表現に正規表現を利用している。例4と例5とに示す正規表現は、Java(登録商標) SE6のPatternクラスにおいて定義されるものである。例4に示される正規表現の意味をわかりやすく示すと、図6(a)に示す例7のように、例4に示す文字列分割パターンによって、入力された文字列が、英数字の単語と、行末コメントと、数値と、文字列リテラルと、その他の文字列とに分割されることになる。また同様に、図6(b)に示す例8のように、例5に示す文字列分割パターンによって、入力された文字列が、英数字の単語と、数字と、タグと、文字列リテラルと、その他の文字列とに分割されることになる。
例7に示された分割後の文字列の種類と、例8に示された分割後の文字列の種類とを比較すると、互いに相異する文字列が含まれている。例7に示される分割後の文字列の種類は、SQLインジェクションの判定精度を高めるための分割パターンに基づくものであり、例8に示される分割後の文字列の種類は、クロスサイトスクリプティングの判定精度を高めるための分割パターンに基づくものであるためである。
このように、制御部20が、文字列データを例4や例5のような文字列分割パターンに基づいて所定の文字列に分割することにより、SQLインジェクションの判定精度を向上させるような分割処理、また、クロスサイトスクリプティングの判定精度を向上させるような分割処理を行うことが可能となる。
なお、図6(c)に示す例9は、例1に示した文字列データを、例4に示した文字列分割パターンに従って複数の文字列に分割した分割結果が示されている。また、図6(d)に示す例10は、例2に示した文字列データを、例5に示した文字列分割パターンに従って文字列に分割した分割結果が示されている。例9および例10に示すようにして分割された文字列の境界には、空白文字が設けられている。
次に、制御部20では、トークン化処理を行う。トークン化処理とは、分割された文字列に対して、意味を付与する処理を意味する。分割された文字列の集合は、トークン化処理によってトークンに変換される。制御部20では、トークン化を行うために、予め規定したトークンと、それぞれのトークンに対応する文字列の表現を規定しておき、データ記憶部21に記録しておく。
制御部20では、分割された文字列が、予め規定したトークンの表現文字列に適合した場合に、該当する文字列のトークン化を行う。図7の例11は、SQLインジェクションにおけるトークン化処理のトークン名とトークンの文字列表現との対応表を示している。制御部20では、分割された文字列の中に、図7の例11に示すトークンの文字列表現に該当する文字列が存在するか否かを判断し、該当する文字列が存在する場合に、該当する文字列を例11に示すトークン名にトークン化する処理を行う。具体的には、該当する文字列を、行末コメント、演算子、論理演算子、区切り子、予約語を含む複数のトークンに変換する。このように制御部20では、SQLインジェクションにおけるトークン化処理も行うことから、制御部20がSQLインジェクション用トークン処理部52として機能することになる。
また、図8に示す例12は、クロスサイトスクリプティングにおけるトークン化処理のトークン名とトークンの文字列表現との対応表を示している。制御部20では、分割された文字列の中に、図8の例12に示すトークンの文字列表現に該当する文字列が存在するか否かを判断し、該当する文字列が存在する場合に、該当する文字列を例12に示すトークン名にトークン化する処理を行う。具体的には、該当する文字列を、タグ、区切り子、FPM(JavaScriptの関数、プロパティ、メソッドを表す)、記号を含む複数のトークンに変換する。このように制御部20では、クロスサイトスクリプティングにおけるトークン化処理も行うことから、制御部20がクロスサイトスクリプティング用トークン処理部54として機能することになる。
図9および図10は、図7に示したSQLインジェクションにおけるトークン化処理の具体的な処理手順をフローチャートで示した図である。
まず制御部20は、SQLインジェクション用分割部51で分割された文字列が、「−」で始まる文字列、もしくは、「#」で始まる文字列に該当する文字列であるか否かを判断する(ステップS.1)。ウェブサイトの入力フォームにおいて、行末コメントが入力された場合には、「−」で始まる文字列、もしくは、「#」で始まる文字列として行末コメントが記録されることになる。このため、「−」で始まる文字列、もしくは、「#」で始まる文字列を抽出してトークン化することにより、行末コメントとして入力された文字列を他の文字列と区別することが可能となる。分割された文字列が、「−」で始まる文字列、もしくは、「#」で始まる文字列に該当する場合(ステップS.1に該当する文字列の場合)、制御部20は、該当する文字列(ステップS.1においてYesとなる文字列)を行末コメントとしてトークン化し、データ記憶部21あるいはRAM31に記録する(ステップS.2)。
次に、制御部20は、ステップS.1またはステップS.2による処理を経た文字列が、「/*」と「*/」とで囲まれた任意の文字列に該当する文字列であるか否かを判断する(ステップS.3)。「/*」と「*/」とで囲まれた任意の文字列に該当する場合、制御部20は、該当する文字列(ステップS.3においてYesとなる文字列)をコメントとしてトークン化し、データ記憶部21あるいはRAM31に記録する(ステップS.4)。
次に、制御部20は、ステップS.3またはステップS.4による処理を経た文字列が、「<>、<=>、>=、<=、==、=、!=、<<、>>、<、>、−、+、%、?」のいずれかの記号に該当する文字列であるか否かを判断する(ステップS.5)。「<>、<=>、>=、<=、==、=、!=、<<、>>、<、>、−、+、%、?」のいずれかの記号に該当する文字列の場合、制御部20は、該当する文字列(ステップS.5においてYesとなる文字列)を演算子としてトークン化し、データ記憶部21あるいはRAM31に記録する(ステップS.6)。
次に、制御部20は、ステップS.5またはステップS.6による処理を経た文字列が、「NOT、AND、OR、XOR、!、&&、||」のいずれかの文字または記号に該当するか否かを判断する(ステップS.7)。「NOT、AND、OR、XOR、!、&&、||」のいずれかの文字または記号に該当する場合、制御部20は、該当する文字列(ステップS.7においてYesとなる文字列)を論理演算子としてトークン化し、データ記憶部21あるいはRAM31に記録する(ステップS.8)。
次に、制御部20は、ステップS.7またはステップS.8による処理を経た文字列が、「[、]、(、)、,、;、.」のいずれかの記号に該当するか否かを判断する(ステップS.9)。「[、]、(、)、,、;、.」のいずれかの記号に該当する場合、制御部20は、該当する記号(ステップS.9においてYesとなる文字列)を区切り子としてトークン化し、データ記憶部21あるいはRAM31に記録する(ステップS.10)。
次に、制御部20は、ステップS.9またはステップS.10による処理を経た文字列が、「‘」と「’」とで囲まれた任意の文字列、もしくは、「“」と「”」とで囲まれた任意の文字列に該当するか否かを判断する(ステップS.11)。「‘」と「’」とで囲まれた任意の文字列、もしくは、「“」と「”」とで囲まれた任意の文字列に該当する場合、制御部20は、該当する文字列(ステップS.11においてYesとなる文字列)を文字リテラルとしてトークン化し、データ記憶部21あるいはRAM31に記録する(ステップS.12)。
次に、制御部20は、ステップS.11またはステップS.12による処理を経た文字列が、「SELECT、INSERT、UPDATE、DELETE、CREATE、DROP、ALTER、RENAME」のいずれかの文字列に該当する文字列であるか否かを判断する(ステップS.13)。「SELECT、INSERT、UPDATE、DELETE、CREATE、DROP、ALTER、RENAME」のいずれかの文字列に該当する文字列である場合、制御部20は、該当する文字列(ステップS.13においてYesとなる文字列)をデータ操作としてトークン化し、データ記憶部21あるいはRAM31に記録する(ステップS.14)。
次に、制御部20は、ステップS.13またはステップS.14による処理を経た文字列が、数値を表す文字列(例えば、0.1や−0.01など)に該当する文字列であるか否かを判断する(ステップS.15)。数値を表す文字列に該当する場合、制御部20は、該当する文字列(ステップS.15においてYesとなる文字列)を数値としてトークン化し、データ記憶部21あるいはRAM31に記録する(ステップS.16)。
次に、制御部20は、ステップS.15またはステップS.16による処理を経た文字列が、図11に示す予約語のいずれかの文字列に該当するか否かを判断する(ステップS.17)。図11は、データ操作にある文字列(ステップS.13においてYesに該当する文字列)を除いたMySQL(世界的に知られているオープンソースデータベース)に規定されている予約語の一覧を一例として示した表である。ここで、予約語とは、プログラミング言語において識別子(変数名、関数名、クラス名など)としてのルールを満たしているにもかかわらず、識別子として使えない字句要素を意味している。
図11に示す予約語のいずれかの文字列に該当する場合、制御部20は、該当する文字列(ステップS.17においてYesとなる文字列)を予約語としてトークン化し、データ記憶部21あるいはRAM31に記録する(ステップS.18)。
次に、制御部20は、ステップS.17またはステップS.18による処理を経た文字列が、アルファベットの大文字(A〜Z)と小文字(a〜z)と「_」とで構成された文字列に該当するか否かを判断する(ステップS.19)。アルファベットの大文字(A〜Z)と小文字(a〜z)と「_」とで構成された文字列に該当する場合、制御部20は、該当する文字列(ステップS.19においてYesとなる文字列)を予約語ではない単語を構成する文字列を示す識別子としてトークン化し、データ記憶部21あるいはRAM31に記録する(ステップS.20)。
そして、制御部20は、ステップS.19またはステップS.20による処理を経た文字列であって、ステップS.1、ステップS.3、ステップS.5、ステップS.7、ステップS.9、ステップS.11、ステップS.13、ステップS.15、ステップS.17、ステップS.19の全ての処理においてNoであった文字列(これらの全てのステップにおける条件を満たさない文字列)に該当するか否かを判断する(ステップS.21)。そして、全ての処理においてNoであった文字列(全ての条件を満たさない文字列)に該当する場合(ステップS.21においてYesの場合)に、制御部20は、該当する文字列(ステップS.21においてYesに該当する文字列)を記号としてトークン化し、データ記憶部21あるいはRAM31に記録して(ステップS.22)、トークン化処理を終了する。一方で、全ての処理においてNoであった文字列に該当しなかった場合(ステップS.21においてNoの場合)、つまり、いずれかの処理においてYesと判断されてトークン化された文字列に対しては、そのままトークン化処理を終了する。
SQLインジェクションでは、本来のSQL文から悪性ウェブコードを挿入するにあたり、行末コメントを用いて、不必要な部分をコメントアウトする手口が多く用いられる。この手口はSQLインジェクション特有のものである。このため、本実施の形態に係る制御部20は、図9および図10に示すように、行末コメントのトークン化処理を、演算子や区切り子のトークン化処理から独立して行っている。このように、演算子や区切り子よりも優先して独立した形で、行末コメントをトークン化処理することによって、SQLインジェクションで用いられる可能性が高い行末コメントの文字列を精度良く抽出することが可能になり、結果として効果的なトークン化処理を行うことが可能となる。
一方で、図12は、図8に示したクロスサイトスクリプティングにおけるトークン化処理の具体的な処理手順をフローチャートで示した図である。
まず制御部20は、クロスサイトスクリプティング用分割部53で分割された文字列が、「<」と「>」とで囲まれた任意の文字列、もしくは、「</」と「>」とで囲まれた任意の文字列に該当するか否かを判断する(ステップS.31)。「<」と「>」とで囲まれた任意の文字列、もしくは、「</」と「>」とで囲まれた任意の文字列に該当する場合、制御部20は、該当する文字列(ステップS.31においてYesとなる文字列)をタグとしてトークン化し、データ記憶部21あるいはRAM31に記録する(ステップS.32)。
次に、制御部20は、ステップS.31またはステップS.32による処理を経た文字列が、図13に示す区切り子のいずれかの文字列に該当するか否かを判断する(ステップS.33)。図13に示す区切り子のいずれかの文字列に該当する場合、制御部20は、該当する文字列(ステップS.33においてYesとなる文字列)を区切り子としてトークン化し、データ記憶部21あるいはRAM31に記録する(ステップS.34)。
次に、制御部20は、ステップS.33またはステップS.34による処理を経た文字列が、「‘」と「’」とで囲まれた任意の文字列、もしくは、「“」と「”」とで囲まれた任意の文字列に該当する文字列であるか否かを判断する(ステップS.35)。「‘」と「’」とで囲まれた任意の文字列、もしくは、「“」と「”」とで囲まれた任意の文字列に該当する場合、制御部20は、該当する文字列(ステップS.35においてYesとなる文字列)を文字列リテラルとしてトークン化し、データ記憶部21あるいはRAM31に記録する(ステップS.36)。
次に、制御部20は、ステップS.35またはステップS.36による処理を経た文字列が、数値を表す文字列(例えば、0.1や−0.01など)に該当する文字列であるか否かを判断する(ステップS.37)。数値を表す文字列に該当する場合、制御部20は、該当する文字列(ステップS.37においてYesとなる文字列)を数値としてトークン化し、データ記憶部21あるいはRAM31に記録する(ステップS.38)。
次に、制御部20は、ステップS.37またはステップS.38による処理を経た文字列が、図14に示すオブジェクトのいずれかの文字列に該当するか否かを判断する(ステップS.39)。図14は、JavaScriptのオブジェクト名を表した文字列の一覧を一例として示したものである。図14に示すオブジェクトのいずれかの文字列に該当する場合、制御部20は、該当する文字列(ステップS.39においてYesとなる文字列)をオブジェクトとしてトークン化し、データ記憶部21あるいはRAM31に記録する(ステップS.40)。
次に、制御部20は、ステップS.39またはステップS.40による処理を経た文字列が、図15に示すFPMのいずれかの文字列に該当するか否かを判断する(ステップS.41)。図15は、JavaScriptの関数、プロパティ、メソッドを表した文字列の一覧を一例として示したものである。図15に示すFPMのいずれかの文字列に該当する場合、制御部20は、該当する文字列(ステップS.41においてYesとなる文字列)をFPMとしてトークン化し、データ記憶部21あるいはRAM31に記録する(ステップS.42)。
次に、制御部20は、ステップS.41またはステップS.42による処理を経た文字列が、図16に示す予約語のいずれかの文字列に該当するか否かを判断する(ステップS.43)。図16は、JavaScriptに規定されている予約語を表した文字列の一覧を一例として示したものである。図16に示す予約語のいずれかの文字列に該当する場合、制御部20は、該当する文字列(ステップS.43においてYesとなる文字列)を予約語としてトークン化し、データ記憶部21あるいはRAM31に記録する(ステップS.44)。
次に、制御部20は、ステップS.43またはステップS.44による処理を経た文字列が、アルファベットの大文字(A〜Z)と小文字(a〜z)と「_」とで構成された文字列に該当するか否かを判断する(ステップS.45)。アルファベットの大文字(A〜Z)と小文字(a〜z)と「_」とで構成された文字列に該当する場合、制御部20は、該当する文字列(ステップS.45においてYesとなる文字列)を予約語ではない単語を構成する文字列を示す識別子としてトークン化し、データ記憶部21あるいはRAM31に記録する(ステップS.46)。
そして、制御部20は、ステップS.45またはステップS.46による処理を経た文字列であって、ステップS.31、ステップS.33、ステップS.35、ステップS.37、ステップS.39、ステップS.41、ステップS.43、ステップS.45の全ての処理においてNoであった文字列(これらの全てのステップにおける条件を満たさない文字列)に該当するか否かを判断する(ステップS.47)。そして、全ての処理においてNoであった文字列(全ての条件を満たさない文字列)に該当する場合(ステップS.47においてYesの場合)に、制御部20は、該当する文字列(ステップS.47においてYesに該当する文字列)を記号としてトークン化し、データ記憶部21あるいはRAM31に記録して(ステップS.48)、トークン化処理を終了する。一方で、全ての処理においてNoであった文字列に該当しなかった場合(ステップS.47においてNoの場合)、つまり、いずれかの処理においてYesと判断されてトークン化された文字列に対しては、そのままトークン化処理を終了する。
クロスサイトスクリプティングにおいては、タグを含んだ悪性ウェブコードが多く用いられる傾向があるため、タグに該当する文字列を他の要素から独立してトークン化している。このように、タグに該当する文字列を他の要素よりも優先して独立にトークン化することによって、クロスサイトスクリプティングで用いられる可能性が高いタグの文字列を精度良く抽出することが可能になり、結果として効果的なトークン化処理を行うことが可能となる。なお、ウェブページにタグを含まない悪性ウェブコードを挿入しても、ただの文字列として認識されて、悪性ウェブコードが実行されない。
また、SQLインジェクションにおいては、上述した行末コメントの他に、演算子、論理演算子、区切り子、予約語などの文字列は他の文字列と比較して悪性ウェブコードに含まれる可能性が高い。このため、これらの文字列を独立してトークンに変換することにより、SQLインジェクションにおける悪性ウェブコードの検出精度を高めることが可能なトークン化処理を行うことが可能となる。また、同様に、クロスサイトスクリプティングにおいても、上述したタグの他に、区切り子、FPM、記号などの文字列は、他の文字列に比較して悪性ウェブコードに含まれる可能性が高い。このため、これらの文字列を独立してトークンに変換することにより、クロスサイトスクリプティングにおける悪性ウェブコードの検出精度を高めることが可能なトークン化処理を行うことが可能となる。
例えば、図17(a)に示す例13は、例1の文字列を例4に示す文字列分割パターンに従って、制御部20で文字列に分割し、その後に、例11および図9・図10に示すフローチャートに従って、分割された文字列をトークン化することで得られた結果を示している。
また、図17(b)に示す例14は、例2の文字列を例5に示す文字列分割パターンに従って、制御部20で文字列に分割し、その後に、例12および図12に示すフローチャートに従って、分割された文字列をトークン化することで得られた結果を示している。
なお、図17(c)に示す例15は、例3に示した無害な文字列をトークン化した結果を示している。このような無害な文字列は、悪性ウェブコードに該当する可能性が低い。このため、例3に示す無害な文字列を、例4に示す文字列分割パターンに従って文字列に分割し、その後に、例11および図9・図10に示すフローチャートに従って、分割された文字列をトークン化すると、無害な文字列が、図9・図10のフローチャートにおけるステップS.1、ステップS.3、ステップS.5、ステップS.7、ステップS.9、ステップS.11、ステップS.13、ステップS.15、ステップS.17、ステップS.19の全ての処理において該当しない文字列(これらの全てのステップにおける条件を満たさない文字列)として判断されて、記号としてトークン化されることになる。
上述したように、図9・図10および図12に示したような処理を行うことによって、与えられた文字列は最終的にトークンの集合として表されることになる。集合として表されたトークンを素性と見なすことにより、文字列から悪性ウェブコードの特徴を捉える素性を、機械学習を用いて抽出することが可能となる。ここで、機械学習とは、教師データにあるデータのパターンとそのデータのクラスの関連性を学習することによって、悪性ウェブデータに該当するか否かの分類手法を求め、教師データにはない新たに与えられたデータを分類手法に基づいて解析し、教師データで規定されたクラスのいずれかに分類する処理を行う。
機械学習を用いて悪性ウェブコードの特徴を捉える素性を抽出するためには、各データの素性に対して数値の割当を行う必要がある。最も代表的な数値の割当計算法として、例えば、用語出現頻度(Term Frequency:以下、TFと称する)や、Term Frequency Inverse Document Frequency(以下、TF−IDFと称する)などが知られている。
どの割当計算法が良いかは、事前に交差検定等の評価を行って、一番良い割当計算法を選ぶことが好ましい。例えば、図17(a)に示す例13によって抽出されたトークンに対して、TFの割当計算法によって数値の割当計算を行うと、図18(a)に示す例16のような計算結果となり、図17(b)に示す例14によって抽出されたトークンに対して、TFの割当計算法によって数値の割当計算を行うと、図18(b)に示す例17のような計算結果となり、図17(c)に示す例15によって抽出されたトークンに対して、TFの割当計算法によって数値の割当計算を行うと、図18(c)に示す例18のような計算結果となる。
図18に示すように、TFによる割当計算法などを用いて数値計算を行うことによって、文字列データから機械学習に必要となる素性の生成処理を行うことが可能となる。本実施の形態に係るサーバ1では、制御部20が、データ記憶部21またはRAM31に記録されているトークン化された文字列を読み出し、トークン化された文字列の数値割り当て処理を行う。このため、本実施の形態に係る制御部20は、数値割当部42として機能することになる。
図18に示した抽出手法ではユニグラムを用いており、ユニグラムとして抽出されるトークンの一つ一つを素性として扱う方法を用いている。しかしながら、連続して出現した二つないしは、三つのトークンを一つの素性として抽出するバイグラム、トライグラムと呼ばれる手法を用いることも、抽出されたトークンの出現順序を考慮すると、素性の生成処理として有効であると考えられる。
ユニグラム、バイグラム、またはトライグラムのどの抽出方法が良いかは、トークンに割り当てる数値の計算方法と同じように、交差検定等による評価で一番良い結果が得られるものから判断すれば良い。図19(a)に示す例19は、例1の文字列に対してバイグラムにより生成された素性とその素性に対してTFの割当計算法による数値の割当を行った結果を例示している。
さらに、制御部20では、数値割り当て処理が行われた文字列について、トークン化されたカテゴリ(トークンの種類)をベクトルの方向として、割り当てられた数値をベクトルの長さとして、文字列の特徴ベクトルを生成する。このように特徴ベクトルを生成することにより、文字列の素性を機械学習によって判断するために必要なデータを得ることが可能となる。本実施の形態に係るサーバ1では、制御部20が、トークンのカテゴリと割り当てられた数値とに基づいて特徴ベクトルの生成を行うため、特徴ベクトル生成部43として機能することになる。次に、生成された特徴ベクトルを用いて、悪性ウェブコードを判定する手法について説明する。
(2)機械学習による悪性ウェブコードの判定
本実施の形態に係る制御部20では、予め用意した悪性ウェブコードの文字列と無害な文字列とを、トークンを素性としたデータとして表現することにより、機械学習に必要な教師データを生成することができる。機械学習により、上述したように、教師データにあるデータのパターンとそのデータのクラスの関連性を学習することによって分類手法を求め(この分類手法により分類を行うことが可能な分類器を生成し)、教師データにない新たなデータを、求められた分類手法に基づいて(制御部20が分類器として機能して)解析することにより、教師データで規定されたクラスのいずれかに分類する処理を行う。
つまり、本実施の形態に係るサーバ1では、悪性ウェブコードの文字列における特徴ベクトルの特性と無害な文字列における特徴ベクトルの特性とに基づいて、悪性ウェブコードに対応する教師データを生成し、この教師データに基づいて機械学習を行うことによって求められる分類手法を用いて(生成される分類器を用いて)、悪性ウェブコードであるか否かを制御部20で自動的に判別させることが可能となる。
機械学習には様々な手法があるが、SVM(T. Joachims, Text Categorization with Support Vector Machines: Learning with Many Relevant Features. Proceedings of the European Conference on Machine Learning, Springer, 1998)やAdaBoost(Robert E. Schapire and Yoram Singer. BoosTexter: A boosting-based system for text categorization, Machine Learning, 39(2/3):135-168, 2000)などが、これまで提案されてきた手法の中で比較的良い性能を得られる手法として確認されている。制御部20は、上述したように、悪性ウェブコードの文字列と無害な文字列とに基づいて教師データを生成し、教師データに基づいて機械学習を行うことによって分類手法を求める役割を有している。このため、制御部20は、機械学習部44として機能することになる。
図20は、制御部20において、予め用意した悪性ウェブコードの文字列データと無害な文字列データとに基づいて機械学習に必要な教師データを生成して、悪性ウェブコードであるか否か判断するための分類手法を求める処理を示したフローチャートである。図20に示すフローチャートによる処理を行う前提として、悪性ウェブコードの文字列と無害な文字列のデータとが予め用意されて、データ記憶部21に一時的に記録されているものとする。
まず、制御部20は、悪性ウェブコードの文字列データと無害な文字列データとの両方のデータを、データ記憶部21より読み出す(ステップS.51)。次に、制御部20は、用意した文字列データを文字列に分割し(ステップS.52)、分割された文字列をトークン化する(ステップS.53)、それぞれのトークンに対してTFによる割当計算法などを用いて数値の割り当てを行い(ステップS.54)、悪性ウェブコードの文字列と無害な文字列との両方の特徴ベクトルを求めて教師データを生成する(ステップS.55)。
その後、制御部20は、生成された全ての教師データについて、文字列データの悪性か無害かを示すクラスとその文字列のデータにおけるトークンの数値とを、機械学習によって学習させることにより、分類手法を求める(分類器を生成する)(ステップS.56)。このようにして分類手法を求めることにより、その後にクライアントより取得した文字列データにおける悪性ウェブコード判定を行うことが可能となる。
なお、本実施の形態に係る制御部20では、分類手法を用いて(分類器として機能することによって)SQLインジェクションであるか否かの判定と、クロスサイトスクリプティングであるか否かの判定とを行う。このため、SQLインジェクションの判定を行う場合には、SQLインジェクション用の分類手法(分類器)を用意し、また、クロスサイトスクリプティングの判定を行う場合には、クロスサイトスクリプティング用の分類手法(分類器)を用意する必要がある。
従って、SQLインジェクションの分類手法を求める(分類器を生成する)場合には、教師データとして、SQLインジェクションを示す文字列(悪性ウェブコード)データと無害な文字列データ(ノーマルデータ)との2種類のデータを用意して、SQLインジェクション用の分類手法を求める(分類器を生成する)必要が生ずる。一方で、クロスサイトスクリプティングの分類手法を求める(分類器を生成する)場合には、クロスサイトスクリプティングを示す文字列データ(悪性ウェブコード)と無害な文字列データ(ノーマルデータ)との2種類のデータを用意して、クロスサイトスクリプティング用の分類手法を求める(分類器を生成する)必要が生ずる。
図21は、機械学習により求められた分類手法を用いて、クライアントより取得した文字列データが悪性ウェブコードに該当するか否かの判別を、制御部20で行う処理を示したフローチャートである。
まず、制御部20は、クライアントより取得した文字列データを、文字列に分割し(ステップS.61)、分割された文字列をトークン化する(ステップS.62)。この場合、制御部20は、SQLインジェクション用分割部51を用いた分割処理およびSQLインジェクション用トークン処理部52を用いたトークン化処理だけでなく、クロスサイトスクリプティング用分割部53を用いた分割処理およびクロスサイトスクリプティング用トークン処理部54を用いたトークン化処理も行う。このように、SQLインジェクションおよびクロスサイトスクリプティングの両方を考慮した処理を行うことによって、SQLインジェクションおよびクロスサイトスクリプティングの両方に対する判別を行うことが可能となる。
次に、制御部20は、トークンに対してTFによる割当計算法などを用いて数値の割り当てを行い(ステップS.63)、トークンのカテゴリと割り当てられた数値とにより特徴ベクトルを求めて、判別用データを生成する(ステップS.64)。なお、判別用データを生成する場合において、教師データに存在しないトークンは削除される。
そして、制御部20は、生成された判別用データを、図20に示した処理により求められた分類手法に基づいて(制御部20が分類器として機能して)分類することにより、得られたクラスを判別用データの分類クラスとしていずれかに分類する処理を行う(ステップS.65)。この分類処理により、取得された文字列データが、悪性ウェブコードであるか否かを制御部20において自動的に判別することが可能となる。そして、制御部20は分類結果を出力し(ステップS.66)、文字列データにおける悪性ウェブコード判別処理を終了する。
図19(b)に示す例20、図19(c)に示す例21、および図19(d)に示す例22は、SQLインジェクションに対する文字列の分類例を示している。例20には、分類対象となる文字列データが示されている。例21には、例20に示す2つの文字列のデータに基づいて、制御部20がSQLインジェクション用分割部51およびSQLインジェクション用トークン処理部52として機能することによって、文字列データの分割およびトークン化処理を行い、各トークンに対する数値を、TFによる割当計算法などを用いて割り当てた結果を示している。そして、図20に示したフローチャートに従って作成された分類手法(分類器)を用いて、制御部20で、例21に示した文字列の分類処理を行うと、図19(d)の例22のように、例20に示した文字列データが悪性ウェブコードに該当するか否かの分類結果が得られる。
機械学習にSVMを用い、数値の割り当てにTF−IDFを用いた場合に、例6に示したような空白文字による分割処理を行って悪性ウェブコードの判別処理を行うと、求められる分類結果は、SQLインジェクションにおける分類精度が98.3%、クロスサイトスクリプティングにおける分類精度が87.4%となった。しかしながら、同じSVMとTF−IDFを用いた場合において、本実施の形態で説明した例4と例5との手法を用いて分割処理を行うと、SQLインジェクションにおける分類精度は99.1%、クロスサイトスクリプティングにおける分類精度は98.8%まで高めることができた。
また、本実施の形態に係る制御部20では、機械学習を利用することより効果的に悪性ウェブコードの分類を行うことができ、また未知の悪性コードを分類手法を用いて動的に適用することによって、悪性ウェブコードであるか否かの分類精度を大幅に改善することが可能となる。
なお、悪性ウェブコードとノーマルデータとを効果的に分類するためには、悪性ウェブコードの文字列データを分割してトークン化する場合において、悪性ウェブコードを特徴づけるトークンが多く含まれるよう処理を行うことが好ましく、また、ノーマルデータを分割してトークン化する場合においても、ノーマルデータを特徴づけるトークンが多く含まれるよう処理を行うことが好ましい。
本実施の形態に係る制御部20では、図9・図10および図12に示したように、行末コメント、演算子、論理演算子、区切り子、予約語のようなプログラミング言語の基本要素が悪性ウェブコードの特徴を良く表すことに着目し、文字列をこれらのトークン毎に分割することで分類精度を高める方法を採用している。このように、文字列において、行末コメントなどに該当する文字列を独立してトークン化することにより、分解精度を最大99.1%まで向上させることが可能となる。
また、制御部20では、機械学習を利用して効果的に悪性ウェブコードの分類を行うことができるので、文字列が悪性ウェブコードであるか、そうでないかの判別を自動的に行うことが可能となる。このように、悪性ウェブコードに該当するか否かの判断を制御部20において自動的に行うことができるので、サイトの安全性を従来よりも大きく向上させることが可能となる。
例えば、あるIPアドレスの端末から、ネットワークを介して幾度となく特定の文字列が送信されている場合には、その文字列に基づく悪性ウェブコード判別を行うことにより、該当する文字列が悪性ウェブコードに該当するものであるか、つまり、攻撃と見なされる悪質な文字列であるかを判断することが可能となる。このような場合に、サーバ1の管理者が該当するIPアドレスの端末のアクセスを遮断することにより、素早い対応処置を取ることができ、サイトの安全性を維持し、さらに高めることが可能となる。
以上、本発明に係る悪性ウェブコード判別システムについて、サーバ1を一例として示すことにより詳細に説明を行ったが、本発明に係る悪性ウェブコード判別システムは、上述した実施の形態に示す事例のみには限定されない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到しうることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
例えば、本実施の形態に係るサーバ1では、サーバの制御部20がデータ記憶部21に記録されるプログラムに従って悪性ウェブコードの判別処理を行うことにより、ネットワークを介して受信されたクライアントからの情報(文字列データ)が、悪性のウェブコードであるか否かの判断を行う構成となっている。このような構成を採用することにより、ウェブサイトを提供するサーバが、クライアントからサーバに対して送信され得る悪性ウェブコードによって被る被害を、未然に防ぐことが可能となる。
しかしながら、本発明に係る悪性ウェブコード判別システムとしての機能は、必ずしもサーバにだけ設けられる例には限定されず、クライアント側に設けられるものであっても良い。クライアントも、図2に示したようなディスプレイ部、入力操作部、本体部(制御部、通信部、データ記録部など)などが一般的に設けられていることが多い。このような構成からなるクライアントにおいて、クライアントの制御部がデータ記録部に記録されたプログラムに従って、ブラウザのコメント入力欄に入力されたコメント等を含む文字列を検出し、検出された文字列に悪性ウェブコードが含まれているか否かの判別を行う構成とすることも可能である。
このようにクライアントにおいて悪性ウェブコード判別機能を実行させることによって、ブラウザを用いてウェブサイトを利用するクライアントにおける悪性ウェブコードの被害を未然防ぐことが可能となる。