予約語の変更によるＳＱＬインジェクション対策
【課題】急増するＳＱＬインジェクション攻撃は、セキュリティを考慮したプログラム開発設計を怠ったＷｅｂアプリケーションが原因である。しかし、Ｗｅｂアプリケーション開発に特化したコンピュータ言語で、データベース問い合わせＳＱＬ言語を其の侭記述するのは仕方の無いことである。ＳＱＬインジェクション攻撃の対策方法を入手することも可能になってきたが、データベースマネージメントシステム（ＤＢＭＳ）が解釈する文字コード問題を迂回することによって、未知の問題等に対して１００％安全な対策方法が見出せない。
【解決手段】ＳＱＬという問い合わせ方法は其の侭とし、ＳＱＬの予約語をシステム毎に変更すれば、攻撃ツールとして出回っているＳＱＬインジェクション攻撃プログラムは無力化できる。セキュリティ対策の手法をデータベースマネージメントシステム側で提供するのである。
【解決手段】ＳＱＬという問い合わせ方法は其の侭とし、ＳＱＬの予約語をシステム毎に変更すれば、攻撃ツールとして出回っているＳＱＬインジェクション攻撃プログラムは無力化できる。セキュリティ対策の手法をデータベースマネージメントシステム側で提供するのである。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば、インターネット等を利用したＷｅｂアプリケーション等の高度なサービスに於いて望まれるセキュリティを簡素化するものであり、特に、ＳＱＬインジェクションのクラック対策に効果的に作用する技術である。
【背景技術】
【０００２】
今日、Ｗｅｂサーバを利用したインターネットのサービスは爆発的に膨れ上がり、静的なＷｅｂコンテンツからより管理しやすいデータベース等を利用した動的なＷｅｂコンテンツに切り換ってきている。これに伴って、これに対応したＷｅｂアプリケーション（ＣＧＩ）も増えてきておりそこに内在するバグやセキュリティホールによる情報漏えい問題が深刻になっている。さらに、Ｗｅｂアプリケーションの作成に使われるプログラム言語の普及により人気のある言語には沢山の書籍が出版されているが、セキュリティを全く無視した入門書が多く、セキュリティに特化して詳しく書かれている書籍にいたっては皆無といった状態に陥っている。この書籍を参考にしたプログラマによって作り出されたＷｅｂアプリケーションが蔓延し、ソースコードが公開されているものに於いては、セキュリティ対策が後手に回ってしまうが、人気のプログラムはまだ対策されるだけましで、商用のプログラムや個別の物に於いては、プログラマがセキュリティ対策に於けるチェック等の工数が見積もれずにプログラムを完成させ顧客にソフトウエアを納品してしまう現状がある。
これらの現状でＷｅｂアプリケーションとデータベースを組合せた、Ｗｅｂサービスは特に深刻なＳＱＬインジェクション攻撃が蔓延している状態となり、攻撃が成功したときの情報漏えい被害がデータベースを乗っ取られるのと同じ現状になってしまう為、静的なＷｅｂコンテンツやデータベースを使わない動的Ｗｅｂコンテンツと比べて被害が大きい。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
本発明は、上記の課題ＳＱＬインジェクション攻撃に対して、その根本的な問題を解決しセキュリティを確保するもので、また、既存のプログラム修正を最小限に抑えることを目的としている。ＳＱＬインジェクション攻撃の最大問題は、ＳＱＬの予約語が標準ＳＱＬ規格として秘匿できない公の物であると共に、その利便性の良さの為Ｗｅｂアプリケーションに利用されるプログラミング言語から、直接ＳＱＬ文をそのままデータベースサーバに投入してプログラム開発をしまうことである。
これらの問題において、一般にある解決策は、Ｗｅｂアプリケーションに対してブラウザからの入力（注入される文字列）をチェックして対策する方法か若しくは、Ｐｒｅｐａｒｅｄ Ｓｔａｔｅｍｅｎｔ（プリペアードステートメント：準備済みＳＱＬ）と呼ばれる、ＳＱＬを予め準備させておいてブラウザの入力部分を全て文字列として強制的に注入させる事で対策するのが一般的である。
この対策は最初からプログラムを作成する場合には有効であるが必ずしも完璧とは呼べないし、既存の物を修正するには出回っているアプリケーションが多すぎて現実的ではない。
【実施例】
【０００４】
図１は、本発明を示す概要図であり、本特許を採用したデータベースマネージメントシステム（ＤＢＭＳ）上で動作するようＳＱＬ構文を変更した例である。コードの一部が未対策１であると、通常ケース３では問題ないが、ＳＱＬインジェクション攻撃４を受けると、ＯＲの後が常に真となりパスワードが異なっても認証されてしまう。しかし、対策後２の場合本来ＳＱＬの予約語であるＯＲが、データベースマネージメントシステム側でＳＱＬの予約語として解釈できない５ため、攻撃が成功しない。
（図１の中では、変更例１で上げていない
ＦＲＯＭ → ＦＲＯＭ＿ｐｇｉ２９４８５
ＡＮＤ → ＡＮＤ＿ｕｉｆｇｋｈｉ３８５９３２
を追加記述している。）
図２は、本発明の背景となるＳＱＬインジェクション攻撃例の要因となるシステム構成を示す概要図である。図２に図示の如く、本発明の方法に係わるシステムは、Ｗｅｂサーバ６とそのＷｅｂサーバ６が利用するデータベース７とＷｅｂサーバ６にアクセスするクライアントＰＣ８と、場合によってはＷｅｂサービスのレスポンス向上の為にＷｅｂサーバ６以外にＷｅｂアプリケーションのプログラムを実行するアプリケーションサーバ９が有る場合がある。また、Ｗｅｂサーバ６内にデータベース７を内蔵する場合もある。ＳＱＬインジェクションの攻撃は、主にインターネット上のクライアントＰＣ８側から図１の用に行われる。
【０００５】
データベースマネージメントシステムＤＢＭＳは、標準ＳＱＬのある程度の規格をサーポートしておりその予約語は共通である。ＳＱＬインジェクションはこの予約語を元に攻撃してくるので、この予約語を下記のパターンで変更し、攻撃する為の予約語が外部から推測できない事でセキュリティ耐性を上げることを目的としている。この時Ｗｅｂアプリケーションで利用され、クライアントＰＣ８のブラウザから入力される文字に、当てはまる恐れのない（例、名前や固有名詞若しくは、自動で作成されるアカウントＩＤ）予約語として定義する。以下にＳＱＬで使用される予約語の一部を例として上げる。
変更例１ ＳＱＬ予約語にアンダーバーを設け意味不明の文字列を、
ＳＥＬＥＣＴ → ＳＥＬＥＣＴ＿ｋｇｔ２４９５ｋａｌｓｉ
ＷＨＥＲＥ → ＷＨＥＲＥ＿ｋｔｒｏａｋｔｕｉｋｘｇｕｆ
ＯＲ → ＯＲ＿ｌｋｇｊｐａｒｅｌｉｇ２３
の様に全てのＳＱＬ予約語にアンダーバーを入力しハッシュ化した
文字を追加して、コマンドの推測ができない様にする。
可読性がある程度存在し、デバッグも比較的容易である。
変更例２ 予約語の一部ないし全てを、
ＳＥＬＥＣＴ → ＳＱＬ＿ｋｇｔ２４９５ｋａｌｓｉ
ＷＨＥＲＥ → ＳＱＬ＿ｋｔｒｏａｋｔｕｉｋｘｇｕｆ
ＯＲ → ＳＱＬ＿ｌｋｇｊｐａｒｅｌｉ３
の様にＳＱＬ予約語をＳＱＬという文字 から始まる予約語に置換しアンダーバー以降の文字をハッシュ化した文字で定義する。可読性は低いがプログラムソースが入手されたとしても攻撃時解析に時間が掛かる。
変更例３ 予約語の一部ないし全てを、
ＳＥＬＥＣＴ → ＳＥＬＥＣＴ＿ｋｇｔ２４９５ｋａｌｓｉ
ＷＨＥＲＥ → ＷＨＥＲＥ＿ｋｇｔ２４９５ｋａｌｓｉ
ＯＲ → ＯＲ＿ｋｇｔ２４９５ｋａｌｓｉ
或いは
ＳＥＬＥＣＴ → ｋｇｔ２４９５ｋａｌｓｉ＿ＳＥＬＥＣＴ
ＷＨＥＲＥ → ｋｇｔ２４９５ｋａｌｓｉ＿ＷＨＥＲＥ
ＯＲ → ｋｇｔ２４９５ｋａｌｓｉ＿ＯＲ
の様に全てのＳＱＬ予約語にアンダーバーを入力しハッシュ化した
共通の文字を追加して、コマンドの推測が出来ない様にする。また、
Ｗｅｂアプリケーションで利用するときには、このハッシュ化された
文字部分を最初に受け取るＷｅｂサーバ６プログラムで検索して削除する
ことで、安全性を更に高める。
例１，例２でも同様にハッシュ部分を検索し削除することは有効である。
【特許文献１】特開２００６−１２０１３０号公報
【０００６】
この実現には、既存のデータベースマネージメントシステム（ＤＢＭＳ）プログラムのソースコードの修正とリコンパイルが必要であり以下の方法が考えられる。
修正箇所はＳＱＬ予約語の部分と限定されており、データベースサーバ毎に独自に直接自動ないし手動で修正してリコンパイルを行う。
以下の方法はデータベースメーカが一度プログラムを修正してしまえばリコンパイルの必要が無い。
プログラムソースコードにデータベースを動作させるマシンの固有値を取り出してハッシュ値を作成しそれを予約語に追加する若しくは変更する。
データベースマネージメントシステム起動時に読み込む初期設定ファイル内に、予約語を独自の名前に切替えるように定義する。
【０００７】
データベースマネージメントシステムプログラムの修正以外に、Ｗｅｂアプリケーションプログラムの修正も定義した予約語に合わせる必要がある。既に通常の予約語と修正前のデータベースで検証や稼動確認が済んでいるプログラムであれば、定義した予約語に合わせてＷｅｂアプリケーションプログラムのデータベースアクセス部分を修正するだけで、殆どのプログラムが動作するようになる。修正に関しては修正プログラムを作ることで一括変換も可能である。
１回の問い合わせでＳＱＬ文が解釈できる文字数は制限されている場合があるので、この点について予約語を予測不可能な物に修正すると文字数が増えてしまうので注意する必要が有る。
【０００８】
データベースマネージメントシステムプログラムの修正後にも、修正前のＳＱＬ予約語も同じ実行環境で使用したい時がある。この時は、マルチユーザに対応したオペレーティングシステムのユーザ管理システムの支援を利用する。特定のユーザ権限でＷｅｂアプリケーションを起動後、個別ＳＱＬ予約語でのみデータベースにアクセスさせる方法を設ける。これにより、システム開発ユーザは既存の予約語をそのまま利用でき、Ｗｅｂアプリケーションではセキュリティを考え独自のＳＱＬ予約語でプログラムが実行される様にする。
【特許文献２】特開２００６−３２３６１４号公報
【０００９】
万が一、Ｗｅｂアプリケーションプログラムが流出し解析されたとしても、データベースマネージメントシステムのプログラムの再コンパイル又は、初期設定ファイルの修正とＷｅｂアプリケーションのＳＱＬ部分の一括編集により直ぐに対策を打てる。
（Ｗｅｂアプリケーションプログラムの流出対策は別途必要である。）
【００１０】
本特許を活用する目的でＷｅｂアプリケーションプログラムを新規に構築する場合、プログラムコード内のＳＱＬ部分に於いて変換ミスを無くす為に、変換予定文字列を予め取り決めて、開発することによりプログラムの再配布や修正に効率よく対応できるようにする。
【００１１】
例として、ＳＱＬインジェクション対策がされたデータベースマネージメントシステム（ＤＢＭＳ）上でＷｅｂアプリケーションが正しく動作する為に、図１のＳＱＬ部分を簡単で確実に変換可能なようにする、プログラムコード記述方法として以下の考え方がある。
Ｗｅｂアプリケーション構築時のプログラムコードにＳＱＬ予約語を拡張子付きで記述していくことで、ＳＱＬの予約語であることをＳＱＬ予約語変換プログラムで容易に検索できるようにする。
通常のプログラムコードは、例えば以下の様になる。
ｑｕｅｒｙ（“ＳＥＬＥＣＴ ＊ ＦＲＯＭ ｕｓｅｒ ＷＨＥＲＥ ＵｓｅｒＩＤ＝‘＄ｕｉｄ’ ＡＮＤ Ｐａｓｓｗｏｒｄ＝‘＄Ｐａｓｓｗｄ’“）
これを、プログラムコードからデータベース問い合わせコードと類推される部分のＳＱＬ予約語を変更するＳＱＬ予約語変換プログラム（支援ツール）で変換する方法と、そのＳＱＬ予約語変換プログラムの変換ミスを無くし実コードのメンテナンスを簡略化するために例として、
ｑｕｅｒｙ（“ＳＥＬＥＣＴ％Ｓｕｆｆｉx％ ＊ ＦＲＯＭ％Ｓｕｆｆｉx％ ｕｓｅｒ ＷＨＥＲＥ％Ｓｕｆｆｉx％ ＵｓｅｒＩＤ＝‘＄ｕｉｄ’ ＡＮＤ％Ｓｕｆｆｉx％ Ｐａｓｓｗｏｒｄ＝‘＄Ｐａｓｓｗｄ’“）
という記述にしておけば、
ｑｕｅｒｙ（“ＳＥＬＥＣＴ＿ｋｇｔ２４９５ｋａｌｓｉ ＊ ＦＲＯＭ＿ｐｇｉ２９４８５ ｕｓｅｒ
ＷＨＥＲＥ＿ｋｔｒｏａｋｔｕｉｋｘｇｕｆ ＵｓｅｒＩＤ＝‘＄ｕｉｄ’ ＡＮＤ＿ｕｉｆｇｋｈｉ３８５９３２ Ｐａｓｓｗｏｒｄ＝‘＄Ｐａｓｓｗｄ’“）
というような変換が容易に行える。ブラウザからの入力値とＷｅｂアプリケーションのプログラムコードを完全に区別できれば、％Ｓｕｆｆｉx％部分の変換をプログラム実行時に行うことも可能であるが性能面と、セキュリティ面を考慮する必要がある。
【図面の簡単な説明】
【００１２】
【図１】本発明の概念（動作）図である。
【図２】本発明の背景を示す概念図である。
【符号の説明】
【００１３】
１ アプリケーションのプログラムコードの一部対策前
２ アプリケーションプログラムコードの一部ＳＱＬインジェクション対策後
３ 正常ケースユーザ名とパスワードの入力値
４ ＳＱＬインジェクション攻撃パターン例
５ ＳＱＬ予約語を変更した対策済み
６ Ｗｅｂサーバ
７ データベースサーバ
８ クライアントＰＣ
９ アプリケーションサーバ
【技術分野】
【０００１】
本発明は、例えば、インターネット等を利用したＷｅｂアプリケーション等の高度なサービスに於いて望まれるセキュリティを簡素化するものであり、特に、ＳＱＬインジェクションのクラック対策に効果的に作用する技術である。
【背景技術】
【０００２】
今日、Ｗｅｂサーバを利用したインターネットのサービスは爆発的に膨れ上がり、静的なＷｅｂコンテンツからより管理しやすいデータベース等を利用した動的なＷｅｂコンテンツに切り換ってきている。これに伴って、これに対応したＷｅｂアプリケーション（ＣＧＩ）も増えてきておりそこに内在するバグやセキュリティホールによる情報漏えい問題が深刻になっている。さらに、Ｗｅｂアプリケーションの作成に使われるプログラム言語の普及により人気のある言語には沢山の書籍が出版されているが、セキュリティを全く無視した入門書が多く、セキュリティに特化して詳しく書かれている書籍にいたっては皆無といった状態に陥っている。この書籍を参考にしたプログラマによって作り出されたＷｅｂアプリケーションが蔓延し、ソースコードが公開されているものに於いては、セキュリティ対策が後手に回ってしまうが、人気のプログラムはまだ対策されるだけましで、商用のプログラムや個別の物に於いては、プログラマがセキュリティ対策に於けるチェック等の工数が見積もれずにプログラムを完成させ顧客にソフトウエアを納品してしまう現状がある。
これらの現状でＷｅｂアプリケーションとデータベースを組合せた、Ｗｅｂサービスは特に深刻なＳＱＬインジェクション攻撃が蔓延している状態となり、攻撃が成功したときの情報漏えい被害がデータベースを乗っ取られるのと同じ現状になってしまう為、静的なＷｅｂコンテンツやデータベースを使わない動的Ｗｅｂコンテンツと比べて被害が大きい。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
本発明は、上記の課題ＳＱＬインジェクション攻撃に対して、その根本的な問題を解決しセキュリティを確保するもので、また、既存のプログラム修正を最小限に抑えることを目的としている。ＳＱＬインジェクション攻撃の最大問題は、ＳＱＬの予約語が標準ＳＱＬ規格として秘匿できない公の物であると共に、その利便性の良さの為Ｗｅｂアプリケーションに利用されるプログラミング言語から、直接ＳＱＬ文をそのままデータベースサーバに投入してプログラム開発をしまうことである。
これらの問題において、一般にある解決策は、Ｗｅｂアプリケーションに対してブラウザからの入力（注入される文字列）をチェックして対策する方法か若しくは、Ｐｒｅｐａｒｅｄ Ｓｔａｔｅｍｅｎｔ（プリペアードステートメント：準備済みＳＱＬ）と呼ばれる、ＳＱＬを予め準備させておいてブラウザの入力部分を全て文字列として強制的に注入させる事で対策するのが一般的である。
この対策は最初からプログラムを作成する場合には有効であるが必ずしも完璧とは呼べないし、既存の物を修正するには出回っているアプリケーションが多すぎて現実的ではない。
【実施例】
【０００４】
図１は、本発明を示す概要図であり、本特許を採用したデータベースマネージメントシステム（ＤＢＭＳ）上で動作するようＳＱＬ構文を変更した例である。コードの一部が未対策１であると、通常ケース３では問題ないが、ＳＱＬインジェクション攻撃４を受けると、ＯＲの後が常に真となりパスワードが異なっても認証されてしまう。しかし、対策後２の場合本来ＳＱＬの予約語であるＯＲが、データベースマネージメントシステム側でＳＱＬの予約語として解釈できない５ため、攻撃が成功しない。
（図１の中では、変更例１で上げていない
ＦＲＯＭ → ＦＲＯＭ＿ｐｇｉ２９４８５
ＡＮＤ → ＡＮＤ＿ｕｉｆｇｋｈｉ３８５９３２
を追加記述している。）
図２は、本発明の背景となるＳＱＬインジェクション攻撃例の要因となるシステム構成を示す概要図である。図２に図示の如く、本発明の方法に係わるシステムは、Ｗｅｂサーバ６とそのＷｅｂサーバ６が利用するデータベース７とＷｅｂサーバ６にアクセスするクライアントＰＣ８と、場合によってはＷｅｂサービスのレスポンス向上の為にＷｅｂサーバ６以外にＷｅｂアプリケーションのプログラムを実行するアプリケーションサーバ９が有る場合がある。また、Ｗｅｂサーバ６内にデータベース７を内蔵する場合もある。ＳＱＬインジェクションの攻撃は、主にインターネット上のクライアントＰＣ８側から図１の用に行われる。
【０００５】
データベースマネージメントシステムＤＢＭＳは、標準ＳＱＬのある程度の規格をサーポートしておりその予約語は共通である。ＳＱＬインジェクションはこの予約語を元に攻撃してくるので、この予約語を下記のパターンで変更し、攻撃する為の予約語が外部から推測できない事でセキュリティ耐性を上げることを目的としている。この時Ｗｅｂアプリケーションで利用され、クライアントＰＣ８のブラウザから入力される文字に、当てはまる恐れのない（例、名前や固有名詞若しくは、自動で作成されるアカウントＩＤ）予約語として定義する。以下にＳＱＬで使用される予約語の一部を例として上げる。
変更例１ ＳＱＬ予約語にアンダーバーを設け意味不明の文字列を、
ＳＥＬＥＣＴ → ＳＥＬＥＣＴ＿ｋｇｔ２４９５ｋａｌｓｉ
ＷＨＥＲＥ → ＷＨＥＲＥ＿ｋｔｒｏａｋｔｕｉｋｘｇｕｆ
ＯＲ → ＯＲ＿ｌｋｇｊｐａｒｅｌｉｇ２３
の様に全てのＳＱＬ予約語にアンダーバーを入力しハッシュ化した
文字を追加して、コマンドの推測ができない様にする。
可読性がある程度存在し、デバッグも比較的容易である。
変更例２ 予約語の一部ないし全てを、
ＳＥＬＥＣＴ → ＳＱＬ＿ｋｇｔ２４９５ｋａｌｓｉ
ＷＨＥＲＥ → ＳＱＬ＿ｋｔｒｏａｋｔｕｉｋｘｇｕｆ
ＯＲ → ＳＱＬ＿ｌｋｇｊｐａｒｅｌｉ３
の様にＳＱＬ予約語をＳＱＬという文字 から始まる予約語に置換しアンダーバー以降の文字をハッシュ化した文字で定義する。可読性は低いがプログラムソースが入手されたとしても攻撃時解析に時間が掛かる。
変更例３ 予約語の一部ないし全てを、
ＳＥＬＥＣＴ → ＳＥＬＥＣＴ＿ｋｇｔ２４９５ｋａｌｓｉ
ＷＨＥＲＥ → ＷＨＥＲＥ＿ｋｇｔ２４９５ｋａｌｓｉ
ＯＲ → ＯＲ＿ｋｇｔ２４９５ｋａｌｓｉ
或いは
ＳＥＬＥＣＴ → ｋｇｔ２４９５ｋａｌｓｉ＿ＳＥＬＥＣＴ
ＷＨＥＲＥ → ｋｇｔ２４９５ｋａｌｓｉ＿ＷＨＥＲＥ
ＯＲ → ｋｇｔ２４９５ｋａｌｓｉ＿ＯＲ
の様に全てのＳＱＬ予約語にアンダーバーを入力しハッシュ化した
共通の文字を追加して、コマンドの推測が出来ない様にする。また、
Ｗｅｂアプリケーションで利用するときには、このハッシュ化された
文字部分を最初に受け取るＷｅｂサーバ６プログラムで検索して削除する
ことで、安全性を更に高める。
例１，例２でも同様にハッシュ部分を検索し削除することは有効である。
【特許文献１】特開２００６−１２０１３０号公報
【０００６】
この実現には、既存のデータベースマネージメントシステム（ＤＢＭＳ）プログラムのソースコードの修正とリコンパイルが必要であり以下の方法が考えられる。
修正箇所はＳＱＬ予約語の部分と限定されており、データベースサーバ毎に独自に直接自動ないし手動で修正してリコンパイルを行う。
以下の方法はデータベースメーカが一度プログラムを修正してしまえばリコンパイルの必要が無い。
プログラムソースコードにデータベースを動作させるマシンの固有値を取り出してハッシュ値を作成しそれを予約語に追加する若しくは変更する。
データベースマネージメントシステム起動時に読み込む初期設定ファイル内に、予約語を独自の名前に切替えるように定義する。
【０００７】
データベースマネージメントシステムプログラムの修正以外に、Ｗｅｂアプリケーションプログラムの修正も定義した予約語に合わせる必要がある。既に通常の予約語と修正前のデータベースで検証や稼動確認が済んでいるプログラムであれば、定義した予約語に合わせてＷｅｂアプリケーションプログラムのデータベースアクセス部分を修正するだけで、殆どのプログラムが動作するようになる。修正に関しては修正プログラムを作ることで一括変換も可能である。
１回の問い合わせでＳＱＬ文が解釈できる文字数は制限されている場合があるので、この点について予約語を予測不可能な物に修正すると文字数が増えてしまうので注意する必要が有る。
【０００８】
データベースマネージメントシステムプログラムの修正後にも、修正前のＳＱＬ予約語も同じ実行環境で使用したい時がある。この時は、マルチユーザに対応したオペレーティングシステムのユーザ管理システムの支援を利用する。特定のユーザ権限でＷｅｂアプリケーションを起動後、個別ＳＱＬ予約語でのみデータベースにアクセスさせる方法を設ける。これにより、システム開発ユーザは既存の予約語をそのまま利用でき、Ｗｅｂアプリケーションではセキュリティを考え独自のＳＱＬ予約語でプログラムが実行される様にする。
【特許文献２】特開２００６−３２３６１４号公報
【０００９】
万が一、Ｗｅｂアプリケーションプログラムが流出し解析されたとしても、データベースマネージメントシステムのプログラムの再コンパイル又は、初期設定ファイルの修正とＷｅｂアプリケーションのＳＱＬ部分の一括編集により直ぐに対策を打てる。
（Ｗｅｂアプリケーションプログラムの流出対策は別途必要である。）
【００１０】
本特許を活用する目的でＷｅｂアプリケーションプログラムを新規に構築する場合、プログラムコード内のＳＱＬ部分に於いて変換ミスを無くす為に、変換予定文字列を予め取り決めて、開発することによりプログラムの再配布や修正に効率よく対応できるようにする。
【００１１】
例として、ＳＱＬインジェクション対策がされたデータベースマネージメントシステム（ＤＢＭＳ）上でＷｅｂアプリケーションが正しく動作する為に、図１のＳＱＬ部分を簡単で確実に変換可能なようにする、プログラムコード記述方法として以下の考え方がある。
Ｗｅｂアプリケーション構築時のプログラムコードにＳＱＬ予約語を拡張子付きで記述していくことで、ＳＱＬの予約語であることをＳＱＬ予約語変換プログラムで容易に検索できるようにする。
通常のプログラムコードは、例えば以下の様になる。
ｑｕｅｒｙ（“ＳＥＬＥＣＴ ＊ ＦＲＯＭ ｕｓｅｒ ＷＨＥＲＥ ＵｓｅｒＩＤ＝‘＄ｕｉｄ’ ＡＮＤ Ｐａｓｓｗｏｒｄ＝‘＄Ｐａｓｓｗｄ’“）
これを、プログラムコードからデータベース問い合わせコードと類推される部分のＳＱＬ予約語を変更するＳＱＬ予約語変換プログラム（支援ツール）で変換する方法と、そのＳＱＬ予約語変換プログラムの変換ミスを無くし実コードのメンテナンスを簡略化するために例として、
ｑｕｅｒｙ（“ＳＥＬＥＣＴ％Ｓｕｆｆｉx％ ＊ ＦＲＯＭ％Ｓｕｆｆｉx％ ｕｓｅｒ ＷＨＥＲＥ％Ｓｕｆｆｉx％ ＵｓｅｒＩＤ＝‘＄ｕｉｄ’ ＡＮＤ％Ｓｕｆｆｉx％ Ｐａｓｓｗｏｒｄ＝‘＄Ｐａｓｓｗｄ’“）
という記述にしておけば、
ｑｕｅｒｙ（“ＳＥＬＥＣＴ＿ｋｇｔ２４９５ｋａｌｓｉ ＊ ＦＲＯＭ＿ｐｇｉ２９４８５ ｕｓｅｒ
ＷＨＥＲＥ＿ｋｔｒｏａｋｔｕｉｋｘｇｕｆ ＵｓｅｒＩＤ＝‘＄ｕｉｄ’ ＡＮＤ＿ｕｉｆｇｋｈｉ３８５９３２ Ｐａｓｓｗｏｒｄ＝‘＄Ｐａｓｓｗｄ’“）
というような変換が容易に行える。ブラウザからの入力値とＷｅｂアプリケーションのプログラムコードを完全に区別できれば、％Ｓｕｆｆｉx％部分の変換をプログラム実行時に行うことも可能であるが性能面と、セキュリティ面を考慮する必要がある。
【図面の簡単な説明】
【００１２】
【図１】本発明の概念（動作）図である。
【図２】本発明の背景を示す概念図である。
【符号の説明】
【００１３】
１ アプリケーションのプログラムコードの一部対策前
２ アプリケーションプログラムコードの一部ＳＱＬインジェクション対策後
３ 正常ケースユーザ名とパスワードの入力値
４ ＳＱＬインジェクション攻撃パターン例
５ ＳＱＬ予約語を変更した対策済み
６ Ｗｅｂサーバ
７ データベースサーバ
８ クライアントＰＣ
９ アプリケーションサーバ
【特許請求の範囲】
【請求項１】
データベースまたは、データベースマネージメントシステム（ＤＢＭＳ）においてサーバとクライアント間でデータの操作や定義を行うためのデータベース言語（ＳＱＬ Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ：構造化問合せ言語）で使用される予約語の一部ないし全てをデータベースマネージメントシステム毎に変更することによって、Ｗｅｂアプリケーション等ネットワークでＤＢＭＳを使用するときに攻撃を受けるＳＱＬインジェクション対策をおこなう解決方法。
【請求項２】
既存のＳＱＬは標準化されており、そのＳＱＬの歴史は長くプログラマやデータベースエンジニアも共通で解釈できる基盤ともなっている。しかし、攻撃方法もＷｅｂアプリケーションで利用されるデータベースに依存する事無く共通に使用できてしまうため、最近問題になっているＳＱＬインジェクション対策が急務となっている。そこで、ＳＱＬの文法や構文を変えることなく、その予約語を個々のデータベースマネージメントシステム毎にデータベースマネージメントシステムプログラムの予約語部分を一部ないし全て変更して、コンパイルや起動時に読み込まれる初期設定ファイルのパラメータや、マシンの固有値を使って生成されるハッシュ値を追加して外部から予測不可能にしてしまう技術。
【請求項３】
Ｗｅｂアプリケーションで使用するプログラム関連ファイルに於いて、ＳＱＬ文をそのまま記述している部分を、個々のシステムの個別予約語に自動変換するプログラムと今後開発されるＷｅｂアプリケーションに於いては、自動変換を更に容易にして変換ミスを無くし、Ｗｅｂアプリケーションで利用するプログラムの再配布を可能にする技術。また、本技術を応用し、Ｗｅｂアプリケーションのセキュリティホールやその他のシステムの脆弱性を使って攻撃される等、何ら可能方法で個別予約語情報が流出したとき、直ぐに変更し再設定を可能にする技術。
【請求項１】
データベースまたは、データベースマネージメントシステム（ＤＢＭＳ）においてサーバとクライアント間でデータの操作や定義を行うためのデータベース言語（ＳＱＬ Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ：構造化問合せ言語）で使用される予約語の一部ないし全てをデータベースマネージメントシステム毎に変更することによって、Ｗｅｂアプリケーション等ネットワークでＤＢＭＳを使用するときに攻撃を受けるＳＱＬインジェクション対策をおこなう解決方法。
【請求項２】
既存のＳＱＬは標準化されており、そのＳＱＬの歴史は長くプログラマやデータベースエンジニアも共通で解釈できる基盤ともなっている。しかし、攻撃方法もＷｅｂアプリケーションで利用されるデータベースに依存する事無く共通に使用できてしまうため、最近問題になっているＳＱＬインジェクション対策が急務となっている。そこで、ＳＱＬの文法や構文を変えることなく、その予約語を個々のデータベースマネージメントシステム毎にデータベースマネージメントシステムプログラムの予約語部分を一部ないし全て変更して、コンパイルや起動時に読み込まれる初期設定ファイルのパラメータや、マシンの固有値を使って生成されるハッシュ値を追加して外部から予測不可能にしてしまう技術。
【請求項３】
Ｗｅｂアプリケーションで使用するプログラム関連ファイルに於いて、ＳＱＬ文をそのまま記述している部分を、個々のシステムの個別予約語に自動変換するプログラムと今後開発されるＷｅｂアプリケーションに於いては、自動変換を更に容易にして変換ミスを無くし、Ｗｅｂアプリケーションで利用するプログラムの再配布を可能にする技術。また、本技術を応用し、Ｗｅｂアプリケーションのセキュリティホールやその他のシステムの脆弱性を使って攻撃される等、何ら可能方法で個別予約語情報が流出したとき、直ぐに変更し再設定を可能にする技術。
【図１】
【図２】
【図２】
【公開番号】特開２０１０−３９６１３（Ｐ２０１０−３９６１３Ａ）
【公開日】平成２２年２月１８日（２０１０．２．１８）
【国際特許分類】
【出願番号】特願２００８−１９９４５０（Ｐ２００８−１９９４５０）
【出願日】平成２０年８月１日（２００８．８．１）
【出願人】（７０８００３３２９）
【Ｆターム（参考）】
【公開日】平成２２年２月１８日（２０１０．２．１８）
【国際特許分類】
【出願日】平成２０年８月１日（２００８．８．１）
【出願人】（７０８００３３２９）
【Ｆターム（参考）】
[ Back to top ]