- ベストアンサー
SQLインジェクション事件について
私は一介の事務ユーザーにすぎませんが、職場で他にパソコンのことがわかる人がいないので、あれこれ頼られてしまい少々重荷の毎日です。 先般大きなニュースで一般市民にもすっかり有名？になってしまったSQLインジェクションのことについて、ちょっと教えて下さい。 他の掲示板サイトで、事件の原因はマイクロソフト製ウインドウズOSと、マイクロソフト製SQLサーバーの欠陥が相乗的に生み出したセキュリティホールだから、他社製品で組まれたシステムなら大丈夫だ、と教わりました。 私はSQLのことをよく知らないのですが、調べてみると言語としてSQLは標準化されていると解説されているので、どこのメーカーのシステムでもSQLサーバーは普遍的に対策が必要ではないかな？と思ってしまったのですが、本当にマイクロソフト製品だけの問題でしょうか？ （それとも、価格.comと静岡新聞サイトで犯人が使った「あの手口」に限ってマイクロソフトの欠陥責任だったのでしょうか？） 自分なりにIT関連のWEB記事バックナンバーを色々当ってみましたが、これについてweb上で報道されている物はちょっとみつかりませんでした。 どなたかどうぞよろしくおねがいします。
- みんなの回答 （4）
- 専門家の回答
質問者が選んだベストアンサー
#2で言うフロントエンドとは、SQL文をデータベースに送り込むことのできるシステム（プログラム）の全体です。ですので、IISを使って構築したサーバアプリケーションであれば、「IIS＋サーバアプリケーション」を指します。 そして、現在公開されている情報からは、この「IIS＋Webサイトアプリケーション」のうちどの部分に瑕疵があったのかは不明のままです。IISに瑕疵があったのかもしれないし、Webサイトアプリケーションに瑕疵があったのかもしれません。両方かもしれませんが、事実がどうなのかは公開されていません。 以下は個人的な推測です。 IIS自体に、IIS単体でSQL Injectionを可能とするような瑕疵があったとは考えにくいと思っています。その理由は (1) IIS自体の管理はSQLベースではない。 (2) IISに付属のサンプルスクリプトやサンプルテンプレートは、だいぶ昔にセキュリティホールとなる欠陥（改修済み）があり、その事実は広く公開されている。（過去に多くの関心を集めたため、その時点で他の欠陥が存在すれば見つかっているに違いない。） (3) IISに付属のサンプルスクリプトやサンプルテンプレートにSQL Injectionが可能だとしても、それらが実際に稼動しているサーバアプリケーションのデータベースに接続できるようWebサイトアプリケーションやデータベースシステムが設定されていることは考えにくい。 の3点です。 (1)は文字通りです。(2)と(3)はもう少し説明が必要かと思います。 IISの付属サンプルには、過去にセキュリティ上の大きな欠陥がありました。これは大きく報じられたため、研究者・クラッカー両方の関心を集めたはずです。SQL Injectionが可能となる欠陥は発見が比較的容易なので、その時点で何か問題があれば既に見つかっているはずです。これが(2)です。 とはいえ、その後新たに追加されたサンプルやユーティリティでSQL Injectionが可能なものが現在存在しないと断言はできません。しかし仮にSQL Injectionが可能なものが現在存在したとしても、それがWebサイトアプリケーションが発行するSQL文を扱うわけではありません。 Webサイトアプリケーションに対してSQL Injectionを実行するには、そのWebサイトアプリケーションが実行するSQL文を相手にする必要があります。（そうしなければ、Webサイトアプリケーションに関する情報を（不正に）取得することができません。） つまり、SQLをInjectしたいシステム（＝Webサイトアプリケーション）と同じWebサーバ（IIS）の上にあっても、独立した別のアプリケーションなので、SQL Injectionを受けてもWebサイトアプリケーション側の情報が取得できることはおよそ考えにくいということになります。これが(3)です。 同じく個人的に、どこに瑕疵があったと考えているかというと、それは上で言うところの「Webサイトアプリケーション」の側です。多分、ユーザが入力した文字列をそのままSQL文の中に組み入れて発行するような箇所があったのでしょう。これは非常によく見る、ありがちなミスです。
その他の回答 (3)
- hoihence
- ベストアンサー率20% (438/2093)
こんにちは。 あのですね、SQLに関しては、ほとんど素人なんですが、今回の件というのは、WEBアプリないしはCGIが動的に生成するSQL文構築の段階での問題だと認識してます。 例えばなんですが、 1 マルチプルステートメントの扱いに問題があった。 2 単純に、サニタイジングされてない特殊文字があった。 3 入力データチェックがされない箇所が残ってた。 4 hiddenフィールドでチェックされてない箇所があった。 5 タグの属性値としてのイベントハンドラが機能できるようになっていた。 等々いろいろありますが、実際に、「何がどうだったのか」というのは知らないです。 まあ、今回の事で個人的に思ったのは、「サイト運営者」、「検挙された攻撃者」双方ともに「情けないなァ」と感じました。 まず、攻撃者の方なんですが、検挙された中国籍の学生は自宅から行ってたんでしょ。それじゃあ、簡単に足が付いちゃうに決まってるじゃないですか。ツールは強力だったけど、使用者がアホだったという、典型的なスクリプトキディーだったということです。 次に、サイト運営者の方なんですが、ちゃんとAUDITINGやってたんですかねぇ。実用に耐えうるかどうかを真摯に精査するということであれば、PENETRATION TESTとかやるはずなんですが。コンサルにソースコードレビューを依頼したりとか。 まあ、上記はあくまで個人的な雑感に過ぎません。
お礼
どうもありがとうございます！ 専門用語が私にはまだまだ敷居が高いのですが、かなめはマルチステートメントなどにもともとSQL言語の不備というか、制定時点ではそこまで考えて無かった脆弱性があった、 けれど、もうSQLは標準言語として「制定」されてしまっているから、そう安易に改訂するわけにも行かない、 だからカスタムでアプリを作る技術者はSQLの弱点を補う工夫が必要なのが今の技術者に求められる常識的鉄則だ、 ∴Windowsに立脚した基本システムの問題とは別物 ということですね＾＾？ ＞検挙された中国籍の学生は自宅から行ってたんでしょ。 なあんと、そうだったんですか＾＾； こんどの終戦記念日には中国じゅうのネットカフェから総攻撃の注意、などとニュースに出ているのを先ほど見ました。 自分でパソコンがなかなか買えない人もまだいるでしょうけど、身元を隠すための中国ネットカフェ繁昌かと思っていました＾＾； マック系の先輩が「これはWindowsの問題が露呈した」と言ったのは、もしかすると中国で出回った「SQL注入工具」がWindows版のツールだ、ということを言いたかったのかな？ですね。 ＞運営者の方なんですが、ちゃんとAUDITINGやってたんですかねぇ 運営者は基本的に物品販売業だったり新聞社だったりですから、監査関係のことは門外漢で外注技術者の能力にゆだねられてしまわざるを得なかったのかと私は新聞を見て思いました。 価格.comの社長さんの記者会見では「現在時点で最高の安全策を導入しているにも関わらず・・・」と冒頭に言ってたのが印象的でした。 大金を外注システム業者に払って安全を任せたつもりが騙された、という悔しい気持ちを感じました。 システム業者側の言い分は、「もっと払ってくれないとそこまでは出来ません」なんだろうなあ、と・・・ その後の顛末が非公開のままですので勝手な憶測ですが、非公開を貫かざるを得ない理由としてはこういう線も濃厚だろうなと薄々感じています。 どうもありがとうございました！
- xcrOSgS2wY
- ベストアンサー率50% (1006/1985)
No.1回答者さんの指摘のとおり、"SQL Injection"という手口自体はどのデータベースシステムを使っていても起こり得るものです。実際に、SQL Server以外でも過去に何度も発生しています。 SQL Injectionを行うには「SQL文を処理（実行）するデータベースシステム」のほかに「SQL文をデータベースに送り込むフロントエンド」が必要で、このフロントエンドに脆弱性があると実行可能となります。 （参考: http://www.ipa.go.jp/security/awareness/vendor/programming/a02_01.html） ですから「Windows／SQL Server／IISでなければSQL Injectionに対して安全だ」などということはありません。
補足
大変お世話になります！ ＞ほかに「SQL文をデータベースに送り込むフロントエンド」が必要で、このフロントエンドに脆弱性があると実行可能となります。 なるほど！ あながち私が聞いた話は100％嘘ではなさそうですね。 ちょっと＃１の回答者さんへのお礼で早合点してしまい、不適切なことを書いてしまったかと反省しました。 「Windows／SQL Server／IISでなければSQL Injectionに対して安全だ」 ということではないけれど、連続した発生したインジェクション事件については、 噛ませてあるマイクロソフト製のフロントエンドに瑕疵があった、という結論になりますでしょうか？ （この事件に関して、マイクロソフトが修正パッチを出したというニュースも無い様子ですが、フロントエンドの瑕疵、という意味では、他社製システム（フロントエンド）なら被害を受けずに済んだ可能性はやはり否定し切れない、と思ってよいでしょうか？）
- 春原 なの（@ymda）
- ベストアンサー率37% (668/1777)
実は、SQLで組まれているものであれば、どのようなのでも同じ事になりえることがあるはずです。 例えば・・・・（あくまでも例です） select * from a b c where c=$FORM{query} とか、文字列で入力します。(perlを仮定しています） もし、この$FORM{query}の中身が・・・ abc; select * from password とか abc(\x0d\x\a =いわゆる改行)select * from password とか、なっていたら、どうでしょう？ このような場合は、個人情報抜き出しの場合ですが、ウィルスを配布するようなのであれば もっと複雑な工程がとられることでしょう。 あくまで、ご参考までに・・・
お礼
どうもまた大変お世話になります！ SQLの構文を仕様どおりに正しく処理するシステムだったら、全部が該当してしまう訳ですよね。 この話しを聞いた時に最初から懸念していたのですが、やはり困り者の宗教学者たちに私が騙されていたことがはっきりわかってすっきりしました！ どうもありがとうございました。
お礼
いつも親身に御解説いただき、本当にありがとうございます！ ＞どこに瑕疵があったと考えているかというと、それは上で言うところの「Webサイトアプリケーション」の側です。 なるほど、「Webサイトアプリケーション」だとカスタムで作られることが多いでしょうから、それを請け負ったシステム会社の瑕疵、という線が確率的には濃厚、ということになりそうですね。 質問投稿の動機となったのは、MacOSXserverを採用していればこういう被害に遭う事は皆無である、という事を教わったからなのですが、もしそうであれば無傷で済むシステムというものはSQL言語の処理を仕様通りに正直に遂行しないで、どこかに標準仕様から外れたトリックを設けていることになりますものね。 （もしかしたら、本当にそういう特殊仕様なのかもしれないので、今度又聞いてみたいと思います） 参考サイトにご紹介くださった情報処理推進機構はとても助かりました。 今の私のレベルではなかなか理解しきれない所が大半ですが、このサイト解説がわかることを目標に他の参考書や、またこちらでの質問等で助けて頂きながら正しい理解を深めていきたいと思います！！