槻ノ木隆の「BBっとWORDS」

バックナンバー

■	その116「DLNAの仕組み」 [2007/03/26]
■	その115「ドメインとActive Directory」 [2007/03/19]
■	その114「ワークグループができること」 [2007/03/12]
■	その113「WPSの仕組み」 [2007/03/05]
■	その112「Gopherの生い立ちと現在」 [2007/02/26]
■	その111「Wikiの使われ方」 [2007/02/19]
■	その110「文字コードとは」 [2007/02/05]
■	その109「IISの生い立ち」 [2007/01/29]
■	その108「NASの登場と一般への普及」 [2007/01/22]
■	その107「HomePNAのいろいろ」 [2007/01/15]
■	その106「Ogg Vorbisの成り立ち」 [2006/12/25]
■	その105「MIDIの原理とSMFの構造」 [2006/12/18]
■	その104「AIFFの構造」 [2006/12/11]
■	その103「WAVの構造と現状」 [2006/12/04]
■	その102「WMAの歴史」 [2006/11/27]
■	その101「AACの特徴」 [2006/11/20]
■	その100「MP3/MPEG Audioの仕組み」 [2006/11/13]
■	その99「HSDPAの仕組み」 [2006/11/06]
■	その98「H.264・MPEG-4 AVCの特徴」 [2006/10/30]
■	その97「IEEE 802.16e（モバイルWiMAX）の特徴」 [2006/10/23]
■	その96「TIFFの特徴」 [2006/10/16]
■	その95「PNGの現状と今後」 [2006/10/02]
■	その94「GIFの構造」 [2006/09/25]
■	その93「10GBASEの種類（2）」 [2006/09/11]
■	その92「10GBASEの種類」 [2006/09/04]
■	その91「GbEのいろいろ」 [2006/08/28]
■	その90「JPEGの特徴」 [2006/08/21]
■	その89「DivXの広がり」 [2006/08/07]
■	その88「MPEGの仕組み」 [2006/07/31]
■	その87「WMVのこれまで」 [2006/07/24]
■	その86「AVIの生い立ちとそのコーデック」 [2006/07/10]
■	その85「QuickTimeの変遷」 [2006/07/03]
■	その84「Realのこれまでと今後」 [2006/06/26]
■	その83「ShareとWinny」 [2006/06/19]
■	その82「DOCSISの仕組み」 [2006/06/12]
■	その81「SQLインジェクションの流れ」 [2006/06/05]
■	その80「RSSの動作」 [2006/05/29]
■	その79「Skypeの仕組み」 [2006/05/22]
■	その78「BitTorrentの特徴と今後」 [2006/05/15]
■	その77「Winnyの仕組みと現状」 [2006/05/08]
■	その76「WinMXの特徴」 [2006/04/24]
■	その75「Gnutellaの歴史と構造」 [2006/04/17]
■	その74「Napsterの歴史」 [2006/04/10]
■	その73「P2Pのいろいろ」 [2006/04/03]
■	その72「IEEE 802.11nの動向」 [2006/03/27]
■	その71「ActiveX Scriptingの動作」 [2006/03/20]
■	その70「Ajaxの仕組み」 [2006/03/13]
■	その69「DHTMLの動作」 [2006/03/06]
■	その68「Scriptの定義」 [2006/02/27]
■	その67「JavaScriptの仕組み」 [2006/02/20]
■	その66「Javaの動作」 [2006/02/13]
■	その65「RFCのプロセス」 [2006/02/06]
■	その64「ActiveX DocumentとActiveX Controlの違いと共通点」 [2006/01/30]
■	その63「ActiveX Controlの機能」 [2006/01/23]
■	その62「ActiveXを構成するもの」 [2006/01/16]
■	その61「Cookieの仕組みと用途」 [2005/12/26]
■	その60「malwareとその分類」 [2005/12/19]
■	その59「rootkitの動作」 [2005/12/12]
■	その58「CSSの役割」 [2005/12/05]
■	その57「HTMLの変遷」 [2005/11/28]
■	その56「PONとその種類」 [2005/11/21]
■	その55「FWAの仕組み」 [2005/11/14]
■	その54「DoSとDDoS」 [2005/11/07]
■	その53「SNMPとMIBの動作」 [2005/10/03]
■	その52「Jumbo Frameとフレームサイズ」 [2005/09/12]
■	その51「WPA2の仕組み」 [2005/09/05]
■	その50「WPAとWPA-PSKの違い」 [2005/08/29]
■	その49「WPAの仕組み」 [2005/08/22]
■	その48「WebDAVの動作」 [2005/08/08]
■	その47「OFDMAの仕組みとOFDMとの違い」 [2005/08/01]
■	その46「OFDMの仕組み」 [2005/07/25]
■	その45「WiMAXの特徴」 [2005/07/11]
■	その44「Wi-Fiの役割」 [2005/07/04]
■	その43「FTPの目的と動作」 [2005/06/27]
■	その42「UPnPの動作」 [2005/06/20]
■	その41「ネットマスクの仕組み」 [2005/06/13]
■	その40「ARPの機能」 [2005/06/06]
■	その39「DNSの原理」 [2005/05/30]
■	その38「デフォルトゲートウェイの役割」 [2005/05/23]
■	その37「MACアドレスの仕組み」 [2005/05/16]
■	その36「スイッチとその進化」 [2005/05/09]
■	その35「ルータによるメリット」 [2005/04/25]
■	その34「ブリッジの原理」 [2005/04/18]
■	その33「リピータの機能」 [2005/04/11]
■	その32「IPアドレスのクラス」 [2005/04/04]
■	その31「ブロードキャスト/マルチキャスト/ユニキャスト」 [2005/03/28]
■	その30「SMTP AUTHと認証の種類」 [2005/03/14]
■	その29「Submissionポートとスパムメール対策」 [2005/03/07]
■	その28「Outbound Port25 Blockingとは」 [2005/02/28]
■	その27「PGPの仕組み」 [2005/02/21]
■	その26「PKIと認証局」 [2005/02/14]
■	その25「公開鍵暗号方式とは」 [2005/02/07]
■	その24「共通鍵暗号とは」 [2005/01/31]
■	その23「SSHの仕組みと応用」 [2005/01/24]
■	その22「SSLの役割」 [2005/01/17]
■	その21「POP3とIMAP4の違い」 [2004/12/27]
■	その20「POP3の役割と機能」 [2004/12/20]
■	その19「SMTPの機能と問題点」 [2004/12/13]
■	その18「SPIとパケットフィルタリング」 [2004/12/06]
■	その17「LANの概念とその広がり」 [2004/11/29]
■	その16「SIPの役割」 [2004/11/15]
■	その15「プロキシの利用」 [2004/11/08]
■	その14「VoIPの仕組み」 [2004/11/01]
■	その13「イーサネットとは」 [2004/10/25]
■	その12「IP/TCP/UDP/ICMPとは」 [2004/10/18]
■	その11「DHCPの役割」 [2004/10/04]
■	その10「MIMOとは」 [2004/09/27]
■	その9「DMZとその効果」 [2004/09/13]
■	その8「ファイアウォールとは」 [2004/09/06]
■	その7「NATとNAPTの違いとIPマスカレード」 [2004/08/30]
■	その6「VPNとVPNパススルーの仕組み」 [2004/08/23]
■	その5「無線LANの問題とWEP」 [2004/08/09]
■	その4「IEEE 802.11a/b/gって何を意味しているの？」 [2004/08/02]
■	その3「ダイナミックDNSって？」 [2004/07/26]
■	その2「グローバルIPアドレスとプライベートIPアドレス」 [2004/07/12]
■	その1「PPPoEって何だろう？」 [2004/07/05]

その81「SQLインジェクションの流れ」

■ SQLインジェクションって何？

　最近はやや下火になりましたが、2005年に随分猛威をふるったのがSQLインジェクション（SQL Injection）を使った不正アクセスでしょう。実際、情報処理推進機構（IPA）の「情報セキュリティ白書2006年版」によると、2005年のセキュリティの10大脅威の第1位が「事件化するSQLインジェクション」でした（関連記事）。では、そもそもSQLインジェクションというのは何でしょう？

　Injectionを辞書で引くと、投入や噴射、注入といった訳語が出てきますが、「SQLを投入」といっても意味がわかりません。あえてこれを訳すと「データベースに外部から不正なSQLを投入・実行する方法」ということになるでしょうか。ただ、これでも理解しにくいかもかもしれませんので、順を追ってもう少し説明していくことにしましょう。

■ SQLインジェクションが起き得るケースの前提

図1：CGIとDBの関係

　まず、SQLインジェクションの話の前に、一般的なCGIとデータベースの関係について、説明しておきます。例えば、「http://www.hogehoge.hoge/」という架空の通販サイトがあるとします。ここで商品一覧を見たい場合、「http://www.hogehoge.hoge/list.cgi」をアクセスすることで実現します。この内部を示したのが図1です。

　図1ではクライアントからWebサーバーに、まずリクエストが飛びます（1）。Webサーバーはこれに合わせ、list.cgiを開いて実行します（2）。このlist.cgi、大抵はPerlやPHPで記述されているわけですが、図の中にあるのはPerlの場合の記述です。“Select Name From SomeTable”という文言がSQLの命令で、Perlはこの文字列をそのままSQLサーバーに渡します（3）。

　SQLサーバーはこれを受け取って解釈し、「SomeTableという名前のテーブル」から、「Name」というカラムに入っているデータをすべて抜き出します（4）。抜き出したデータは、そのままWebサーバー（上で動くPerlのプログラム）に送り返されます（5）。Webサーバーはこれを受け取り、整形（htmlの構文に変換するなど）をしたあとにクライアントに送り返します（6）。こうして、Webブラウザに無事商品名の一覧が表示される、というわけです。

　最初から少し難しい話になってしまいましたが、ここでポイントになるのは、クライアントは自分がデータベースにアクセスしているのを意識せずに済むようになっている点です。データベースは専用言語（上でちょっと出てきたSQL：Structured Query Language）でアクセスするのが一般的です。そこで、実際にデータベースに値を入れたり、逆に値を引き出したりするためにはSQLを使って命令を実行する必要があるのですが、こうしたSQL命令はCGIの形でWebサーバー側に集約してあります。これにより、以下のようなメリットがあります。

・ユーザーはSQLを直接発行する必要がない
・サーバー側はデータベースサーバーを直接アクセスされる心配がない

■ SQLインジェクションの実際

図2：SQLインジェクションが起こりやすい例

　さて、図1の場合はそれほど問題はないのですが（細かく言えばあるのですが、それは後述）、実際はCGIの作りがもう少し変わってきます。例えば自分が誰か、というIDを付加してcgiを発行することにしたりすると、cgiへのパラメータという形でオプション項目がつきます。

　図2がその例ですが、赤く示したのが実際にWebサーバーからデータベースサーバーに送られるSQL文です。これは「SomeTableという名前のテーブル」から、「Name」というカラムに入っているデータをすべて抜き出しますが、その際に「id」というカラムが「hoge」のものに限る、というものです。例えば自動車用品全部などでは件数が多すぎるので、運転席のアクセサリやタイヤなどと絞り込ませたい場合に、こうしたオプションが付加されるのはごく一般的です。

　さて、こうしたlist.cgiが存在する場合に、Webブラウザから“http://www.hogehoge.hoge/list.cgi?ID=hoge;Delete * from SomeTable”というURLを送るとどうなるかというと、list.cgiはこれを律儀に解釈して“Select Name From SomeTable where id=hoge;Delete * from SomeTable”というURLをデータベースサーバーに発行します。データベースサーバーはこれを受け取り、まず“;”の前のSelect文を実行したあと、“;”のあとに従ってSomeTableの内容を全部削除します。

　このように、本来SQL文を入れるべきでないところ（この場合で言えばIDの指定フィールド）にSQL文を無理矢理突っ込み、実行させてしまうというのがSQLインジェクションです。

■ SQLインジェクションの対処

　上に挙げた例は単に愉快犯的にデータを削除する例ですが、なにしろどんなSQLでも実行できてしまうので、データベースに格納されているすべてのテーブル一覧を表示したり、個々のテーブルの内容を全部取得したりということが簡単に行なえてしまいます。例えば静岡新聞社の個人情報が流出した事件では、SQLインジェクションを使ってデータベースに格納されていた顧客情報を引き出されています。この場合、たとえば顧客情報以外にも決済や発注のデータベースを操作されるようなことがあれば、さらに被害は大きくなるでしょう。

　これに対してどう対処するかですが、基本は「細かいことをこつこつと」に尽きます。上の例でいえば、IDのフィールドにSQL文をそのまま入れても、cgiがノーチェックでデータベースに渡してしまっているから問題が生じるのであって、クライアントから送られてきたパラメータをきちんとチェックして問題のないようにする（これをサニタイズと呼びます）ことで、不正なSQL文を弾くのは効果的です。同様に入力値チェック（例えばIDであれば、想定したIDのものが来ているか否かをチェックする）も効果的でしょう。

　また、Webサーバーと連動するデータベースサーバーに、不要なデータを置かないというのも予防策としては効果的です。図1であれば、SomeTableの中にNameと隣り合わせで“HiddenData”というカラムがありますが、直接ユーザーには見せたくない、あるいは流出すると問題のあるデータはWebサーバーと連動しているデータベースサーバーに置かず、別のデータベースサーバーで管理することで、万一、サニタイズ／入力値チェックを潜り抜けてSQLインジェクションが発生しても、被害が最小に抑えられます。

　もっともこうした対応は、面倒な点が多いのも事実です。入力項目が多かったり、しばしばWebのレイアウトが変わったり、提供する項目が変化したりという場合に、それに合わせてサニタイズ／入力値チェックの処理をcgi側に入れてやらなければなりません。すでに大量のcgiが存在しているというケースで、あとからこうした処理を入れるのは非常に困難なケースが少なくありません。

　また予防策としてデータベースを分ける、ということも考えられますが、実装にはかなり手間がかかります。例えば、オンラインでユーザー登録を行ない、顧客情報を入力させるケースで、そのデータをWebサーバーと連動していないデータベースに格納するというのは、原理的に無理があります。こうしたケースでは、顧客情報登録用のWebサーバー／データベースと、普通にアクセスするWebサーバー／データベースを分離する形で実装するのが一般的ですが、手間が非常にかかるのは間違いありません。

　要するに、ウィルス対策としてのファイアウォールのような特効薬がないため、対策はどうしても遅れがちです。ちなみにSQLインジェクションの親戚（？）にOSインジェクションと呼ばれるモノもあります。こちらもやはりCGIのパラメータの中にOSへの操作命令を忍ばせ、CGIの中から直接OSを操作するというものです。こちらへの対策も、今のところサニタイズ／入力値チェック程度しか有効な手段がありません。

2006/06/05 10:58

槻ノ木隆
　国内某メーカーのネットワーク関係「エンジニア」から「元エンジニア」に限りなく近いところに流れてきてしまった。ここ２年ほどは、企画とか教育、営業に近いことばかりやっており、まもなく肩書きは「退役エンジニア」になると思われる。（イラスト：Mikebow）

Broadband Watch ホームページ