また失敗したの?と言われる前に セキュリティ登龍門50

SQLインジェクションで情報がダダ漏れ!?

2009/02/03


 近ごろ急増している不正行為がSQLインジェクション。いたずらや嫌がらせにとどまらず、金銭的な利益をもくろむ攻撃者が、社内データベースと連携するWebアプリケーションを狙い、個人情報や機密情報を盗みだそうと狙っている。不正の手口は自動化され、無差別にWebサーバに襲いかかり、たまたま見つけた脆弱性のあるアプリケーションが餌食になる。SQLインジェクション攻撃はどのように行われるのか、またその対策はどうすればよいのか、SQLインジェクションの現状と対策について考える。

SQLインジェクション

#001

仕込まれたバックドアから個人情報が漏洩!SQLインジェクションの恐怖

  「あなたの会社の顧客のクレジットカードが不正利用されている」……2008年3月、ショッピングサイトを運営するA社はクレジット会社から突然こんな指摘を受けた。寝耳に水の事態に驚いたA社は、クレジットカードを利用した購買を即座にストップし、警察およびクレジット会社と連携しながら事態の把握と原因の調査に動いた。その結果、明らかになったのは、驚くべき不正アクセスとサイト改ざんの手口だった。
 セキュリティの専門会社に依頼した調査で明らかになったのは、Webサーバに悪性のプログラムがいつの間にか仕込まれていたことだった。このプログラムは、顧客データベースからデータを20件ずつ抽出する機能を持ち、3月中の約10日間にわたり、合計4875回もの頻度でプログラムが起動されていた。
 いったいなぜそれが可能だったのか?あくまで推測の域を出ないが、A社は攻撃の種子は2006年に仕込まれたとみている。その頃にSQLインジェクションによりデータベースサーバを外部から直接操作できるバックドアが仕込まれた。そのバックドアを利用して社内の他のサーバにさらにバックドアを仕込み、その上でWebサーバに攻撃用のプログラムを埋め込む手段がとられた可能性があるという。A社は2006年12月にデータベースサーバをアップグレードしており、不用意なコマンドをSQLインジェクションでは実行できなくしていたことと、2006年6月にA社サイトを名指しした不正アクセス手法が中国のとあるブログに掲載されていたことがわかったのが、この推測の根拠である。
 2008年3月に集中攻撃が起こったのは、Webサーバに埋め込まれた攻撃用プログラムを利用する攻撃法が2月18日に中国のホームページ改ざんをテーマにするサイトに掲載されたことによる。その結果、実際のデータ抽出に利用された悪性プログラムが生成されたと見られる。このプログラムは、「select * from ○○○○ where ○○○○ like ' %2008%'」といったSQLクエリ(実際には難読化されていた)を送信していた。
 この集中攻撃によって流出した顧客データは最大9万7500件にのぼると推定されたが、実際の流出件数は定かでない。同社はある程度の流出範囲と原因がわかった時点(4月初め)で事実を公表、個人情報が流出した可能性のある顧客すべてに向け、同社製品購入に利用できる1000円相当のクレジットを提供する対応をとった。また不正アクセス監視強化やDBからのカード情報の削除、システム構成や社内管理体制の見直しまでを含む対策をただちにとり、現在ではかつてよりはるかに堅固なセキュリティ体制を構築している。

                                                                                 (以上、事例はA社発表資料によりキーマンズネット編集部作成)




1

SQLインジェクションの仕組み

 上記のケースのような危険を引き起こす「SQLインジェクション」とはなにか。SQLとはStructured Query Languageの略で、データベースに問い合わせするときの標準的な書式であり、その書式で書いた問い合わせをSQL文という。SQL文では、例えば「SELECT * FROM user WHERE id='keyman'」と書けば、keymanさんというユーザに関する情報がデータベースにより検索され、SQL文を送信したユーザのもとに届く。データベースがWebシステムで利用可能になっている場合は、WebサーバがSQL文やその返答としての情報を仲介することになる。
 図1をみてみよう。書式で「keyman」を囲んでいる「'」(シングルクォート)はその囲まれている部分が文字であることを表す記号だが、「'」に続けて本来行われないはずの操作により特殊な文を追加して「'keyman' or 'a'='A'」とすると、「' or 'a'='A」の部分が「すべて」を意味するため、データベースのユーザ情報がすべて送信者のもとに送られてしまうのだ。このように、正常なSQL文に悪意ある文を差し込む(インジェクションする)のがSQLインジェクションだ。A社の場合は、この例とは違うだろうが、同じようなやり方でSQLインジェクションが当初行われたものと推定される。
 ここではSQLインジェクションの仕組みを説明するためにSQL文例を示した。しかし、こうした行為を自分の管理外に向けて行うと、不正アクセス禁止法や業務威力妨害で訴えられる可能性がある。また、自分で管理しているサーバに対して行った場合も、データが破壊してしまう可能性があるので、注意が必要だ。

図1 SQLインジェクションの仕組み
図1 SQLインジェクションの仕組み

 これは一例に過ぎず、文字入力を行ってSQL文を作るシステムの場合は、ネットワーク経路のどこかの不正プログラムにより同様の操作が行われる可能性がある。盗まれるものもユーザ情報に限らず、企業の機密に関わる情報かもしれないし、時には管理者の権限に関わる情報であるかもしれない。もしも管理者権限が不正に利用されたら、システムを乗っ取られる可能性もある。
 その主なリスクは、次の4点だ。

データベースに蓄積された非公開情報の閲覧  個人情報の漏洩など

データベースに蓄積された情報の改ざん、消去  Webページの改ざん、ウイルス配布命令の埋め込み、パスワード変更、システム停止など

認証回避による不正ログイン  ログインした利用者に許可されているすべての操作を不正に行われる

ストアドプロシージャなどを利用したOSコマンドの実行  システムの乗っ取り、他への攻撃の踏み台としての悪用 など

 このようなリスクを引き起こす書き替えが成功してしまうのは、システムがセキュリティを十分に実装していない場合に限る。悪意をもった攻撃者が攻撃を行い、その対象がSQLインジェクションを不能にする対策を講じていない、つまり脆弱性を持っている場合にだけ、危険が生じるのだ。
 多くのシステムでは、パッケージアプリケーションに備わっている対策を利用したり、自社開発したシステムでもセキュリティを実装したりしているために被害が出ることはない。しかし、脆弱性を完全に潰すことは難しく、A社の場合でもセキュリティを無視した開発を行っていたわけではないが、脆弱性の根絶はできていなかった。攻撃者はボットなどを利用し、無差別かつ自動的にWebサーバに攻撃を仕掛けている。それがたまたま成功した場合、そのサーバに向けて一斉に攻撃が行われるのが現在の攻撃傾向だ。

このページの先頭へ

2

SQLインジェクションへの対策

 それでは、SQLインジェクションに対して有効な対策とはなにか。本来、図1のような書式のSQL文はエラーとされて処理されないようにするのが正しい対応だ。しかし実際の攻撃はこのように単純ではないので、正常なSQL文かそうでないかの判別は難しい。
 対策としては、次の3つのレベルで行う必要がある。

開発時にSQLインジェクションが可能になる脆弱性を作り込まない

運用時にSQLインジェクションの発生に気がつく仕組みを組み込む

SQLインジェクションの発生に気づいたときに迅速に対応を行う

2-1

開発時の対策

 それでは、Webアプリケーションの開発に際してどのようにすればよいかを考えよう。

■根本的な対策として

SQL文の組み立てにバインド機構を使用する
実際の値がまだ割り当てられていない記号文字(プレースホルダ)を使用してあらかじめSQL文の雛形を用意し、後に実際の値(バインド値)を割り当ててSQL文を完成させる「バインド機構」を利用する。バインド値はエスケープ処理されてプレースホルダにはめ込まれるため、入力された悪意あるSQL文の実行を防ぐことができる。

バインド機構を利用できない場合、SQL文を構成するすべての変数に対しエスケープ処理を行う。エスケープ処理の対象は、SQL文にとって特別な意味を持つ記号文字(例えば「’」→「’’」など)だ。これら記号文字は、データベースエンジンによって異なる。なおデータベースエンジンによっては、専用のエスケープ処理を行うAPIを提供しているものがある。

Webアプリケーションに渡されるパラメータにSQL文を直接指定しない。もしパラメータ値が改変されたら、データベースの不正利用につながる可能性がある。

■保険的な対策として

エラーメッセージをそのままブラウザに表示しない。エラーメッセージの内容に、データベースの種類やエラーの原因、実行エラーを起こしたSQL文などの情報が含まれる場合、SQLインジェクション攻撃につながる有用な情報となりうる。また、攻撃された結果を表示する窓口として悪用される場合もある。

データベースアカウントに適切な権限を与える。データベースの多くの内容を利用できる権限がたくさんのユーザに与えられていると、攻撃による被害が深刻化する。できるだけユーザの権限を特定し、必要以上の情報にアクセスできないようにしておいたほうが安全だ。

2-2

運用時の対策

 運用時の対策としては、被害にあったらすぐにわかるようにしておくことが肝心だ。特にA社のケースで特徴的なポイントは、SQLインジェクションが誰も気づかぬうちに行われ、その結果仕組まれた不正プログラムが2年もの間ひっそりと時を待っていたと見られることである。長期間にわたって少しずつ利益を得ていく手法なら、相手を警戒させず、つまり対策をとらせないようにして継続することが不可能ではないだろう。
 このためにはWebサイトへのアクセス監視を強化することになる。利用できるツールとしてはIDS/IPSをはじめ、WAF、ログ管理ツールなどがある。

IDS/IPSによる監視:IDSは不正アクセスをネットワーク、またはサーバ上で監視し、検知したら即座に管理者に通知するツール、IPSは同じように不正アクセスを検知したら即座に対象パケットを遮断するツールだ。ファイアウォールを通り抜けてくる、正常なサービス利用を装った不正アクセスを検知または遮断できる。

WAFによる対策:WAF(Web Application Firewall )はファイアウォールがプロトコルに基づいて不正アクセスを排除するのと同じイメージで、アプリケーションに渡す入力が適正かどうかを検査し、不正なものを遮断するツールだ。ブラウザからの入力をWebサーバの直前で検査することにより、SQLインジェクションなどの不正行為を排除することができる。

ログ管理ツール:サーバのログ取得とその管理を行うツールは必須だ。予防的な対策にはなりにくいが、不正が行われた痕跡を発見し、対策をとることが可能になる。また、常時監視することによって不正の前兆となる偵察行動を発見することができるかもしれない。問題の発生後は、ログを丹念にたどって原因や攻撃者を発見するための、ほとんど唯一の手がかりとなる。

脆弱性検査ツール/サービス:侵入用ツールで疑似攻撃を行い、脆弱性の有無を検査するツールやサービス。不正侵入の手口は多数あるが、ツールやサービスでは違った手口での疑似侵入を短時間で行うことができるため、アプリケーションの脆弱性テストを効率的に行える。

 もっとも、このような対策を盛り込んだからといって、完璧な対策となるとは限らない。攻撃者は絶えず新しい攻撃を加えてくるからだ。それに対応するには、適宜Webアプリケーションをチェックし、不正が行われる可能性をできるかぎり小さくしていくよりほかにない。またチェックはアプリケーションを開発した当事者(自社の開発チームや開発委託先)が行うのでは限界があるだろう。第三者機関としてセキュリティ専門会社に依頼するなどして、適切な検査を行うことが得策だ。

2-3

問題発生時の対策

 SQLインジェクションが行われたことが発覚したら、すぐに原因箇所を特定し、修正しなければならない。もしそれに時間がかかるようなら、不正に利用される可能性のあるサービスを一時的に停止する必要がある。
 原因箇所が特定できたら、被害範囲を予測し、特にそれが顧客などの社外に影響が及ぶものであった場合には、被害の可能性がある相手先に通知を行い、個人情報等の悪用の可能性があることを認識してもらう必要がある。被害への賠償を検討し実行することがその次の段階の作業になる。
 また、脆弱性のあるアプリケーションの改修だけにとどまっていては不十分だ。その脆弱性がどのように作り込まれたか、または対策部分をなぜ作り込まなかったかを明確にし、同じことが繰り返されないように開発体制と運用体制の両面を見直す必要がある。
 さらに重要なのは事実の公表だ。不正アクセスが行われた事実はブランドイメージに表面的な傷をつけるに違いないが、それを隠蔽したことが発覚したら、致命傷に至りかねない。事実の公表は自社の被害を最小限にとどめ、顧客の不利益を防ぐために必要な行動だ。もちろんそれには企業の社会的な責任の認識が必要だろう。冒頭のケースファイルのA社はさまざまな影響を短期間で検討したうえで適切なタイミングで詳細な経緯を含めて公表し、顧客の被害を最小限に食い止めたばかりでなく、セキュリティ対策の必要性と対策に対する社会的な取り組みの必要性を多くの企業に知らしめたことで、結果として大きな社会貢献をなした。このような問題発生後の対策を、事前に検討・計画しておくことも、対策として重要な部分である。

 以上、SQLインジェクションについて、事例を鍵に原因と対策について紹介した。次回はSQLインジェクションをはじめとする不正行為の発生状況や攻撃傾向について、統計資料とともに解説する。


取材協力

独立行政法人 情報処理推進機構企業サイトへ

このページの先頭へ
セキュリティ情報局へ登録する

セキュリティ情報局へ登録するにはキーマンズネットへの会員登録が必要です。

会員登録(無料)・ログイン

この記事を読んだアナタにおすすめします。



このページの先頭へ

キーマンズネットとは

ページトップへ