今夜こそわかる安全なSQLの呼び出し方　～高木浩光氏に聞いてみた：Security&Trust ウォッチ（60）

» 2010年06月25日 10時00分公開

　「安全なSQLの呼び出し方」というSQLのセキュリティに焦点を当てたドキュメントが、2010年3月にIPA（独立行政法人情報処理推進機構）から公開された。

　これは2006年1月から提供されている、Webサイト開発者や運営者向けのセキュアWebサイト構築のための資料「安全なウェブサイトの作り方」の別冊として書かれたものである。「安全なウェブサイトの作り方」が92ページなのに対して、SQLインジェクションについてだけで40ページもの分量がある。なぜこんなに分厚いのだろうか。

【参考】

情報処理推進機構：情報セキュリティ：脆弱性対策：安全なウェブサイトの作り方

http://www.ipa.go.jp/security/vuln/websecurity.html

　このドキュメント作成に協力したという、独立行政法人産業技術総合研究所情報セキュリティ研究センターの高木浩光氏にお話を伺うことができた。高木氏は個人ブログ「高木浩光＠自宅の日記」で、セキュリティ関連の問題を追求する論客としても知られている。筆者も以前、この連載の「今夜わかるSQLインジェクション対策」の回（2006年11月公開）で「また上野宣か。」と間違いを厳しく指摘された苦い思い出がある。

　今回は取材というかたちで、3年半ぶりに「今夜わかるSQLインジェクション対策」の訂正記事をお届けする。

まず結論として、SQLインジェクションを防ぐための対策とは？

「SQLのprepared statement（プリペアド・ステートメント、準備された文）を使うことです」（高木氏）

独立行政法人産業技術総合研究所情報セキュリティ研究センター
高木浩光氏

　SQLの実行は、SQL文を構文解析する作業と、それを解釈する作業に分かれる。プリペアド・ステートメントというのは、この構文解析をDBMS側で先に済ませておき、そこにパラメータを当てはめて繰り返し使うことで、処理効率を高めるために活用されるものだ。

　プリペアド・ステートメントを使用していれば、どんなパラメータが与えられても構文解析は変わらないので、結果的にSQLインジェクションによってSQL文の構文が破壊されることは起きない。

　「安全なSQLの呼び出し方」では、プリペアド・ステートメントのことを「静的プレースホルダ」と呼んでいる。「プレースホルダ」に関連する機能は呼び名がさまざまで、「バインド機構」と呼ばれることもある。また、一部の言語環境では、事前の構文解析を行わないもの、つまり、見かけだけの「なんちゃってプリペアド・ステートメント」が「プリペア」と呼ばれていることもあって、混乱が生じているという。

　SQLインジェクション対策として考える場合、バインドすることが本質ではなく、バインドする場所「プレースホルダ」を用意することが本質であることから、「プレースホルダ」の用語で統一することにした。そして、真のプリペアド・ステートメントのことを「静的プレースホルダ」と呼び、なんちゃってプリペアド・ステートメントのことを「動的プレースホルダ」と呼んで整理している。

　静的プレースホルダは原理的にSQLインジェクションが発生しないものであるのに対し、動的プレースホルダでは、構文が壊れる脆弱性があるものもあるので注意が必要だという。この脆弱性については「安全なSQLの呼び出し方」に詳細が記されている。

本コラム第42回「今夜わかるSQLインジェクション対策」について

「最初に書いてあったことはヒドかった」（高木氏）

　筆者は当初、SQLインジェクション対策として、文字列連結によるSQL文の組み立てでエスケープ処理する方法を書いていたが、プレースホルダについて書いていなかった。これは当時の筆者の理解不足によるものだ。

　文字列連結でのエスケープ処理もSQLインジェクション対策にはなるが、使用するDBMSによってエスケープが必要な文字が異なるなど、ひと言でいえるほど簡単なことではない。仮に、最初に開発したときに、使用するDBMSに合わせてちゃんと実装したとしても、後にDBMSが別のものに変更されたときに、エスケープ処理が正しくないものとなって、SQLインジェクション脆弱性になるという悲劇も起こりえる。

「いまでも、数値パラメータの扱いは間違ったまま」（高木氏）

　筆者は、数値パラメータもシングルクオートでくくるという対策を書いていたが、この対策も正しくないそうだ。

　「エスケープ処理の説明は、SQLインジェクションの原理を説明するのには必要だが、解決策の説明には別の視点が必要。攻撃のパターンからそれを回避する方法を考えるのではなくて、そもそも本来あるべき正しい実装はどういうものかを考えてもらいたい」と高木氏は言う。

「安全なSQLの呼び出し方」は指導者必読のドキュメント

「セキュリティの専門家として指導的な立場の方に読んでいただききたい」（高木氏）

　指導的な立場とは、Webシステムの開発に関連した教育やコンサルティングに携わっている方や、社内向けにセキュリティについて指導する人などを指す。もちろん筆者のようなセキュリティの記事や書籍を書く人も、ということだ。

　「自前のエスケープ処理ではなぜダメなのか、それを理解していただくために書かれている」と高木氏。

　「安全なSQLの呼び出し方」の全40ページの半分は、Webアプリケーションで使用されることの多いDBMSと、プログラミング言語の組み合わせを対象にした、以下の実態調査の結果が載せられている。これは、筆頭著者の徳丸浩氏による調査結果だという。

プレースホルダの実装は静的プレースホルダ（準備された文）か、動的プレースホルダか
動的プレースホルダのエスケープ処理は正しく処理されるか
quoteメソッドは正しく処理されるか
文字エンコーディングの扱い

　調査された組み合わせは以下のものである。Webアプリケーション開発の際の参考になるだろう。

Java ＋ Oracle
PHP ＋ PostgreSQL
Perl ＋ MySQL
Java ＋ MySQL
ASP.NET ＋ Microsoft SQL Server

セキュリティ専門家の根性論？

「根性だけでセキュリティ専門家になれてしまう」（高木氏）

　セキュリティ専門家は、根性さえあればある程度のレベルに到達できると高木氏は言う。どこかに書いてあったことを暗記して、それを話しているだけでも、セキュリティ専門家になれる。しかし、セキュリティ専門家に真に求められるのは、その対策が本当に対策になっているのかを考え、どういう前提条件で適用できるのかといった切り分けをする能力だという。

　また、マネジメント系のセキュリティとエンジニア系のセキュリティは異なる。開発に携わるエンジニア系のセキュリティ専門家は、原理から物事を考えてみるべきだろう。

間違った対策を普及させないために

「“サニタイズ言うな。”は広まった」（高木氏）

　SQLインジェクションやクロスサイトスクリプティングの対策では、「サニタイズ手法」などと呼ばれる、入力値に着目して有害な文字を処置するという考え方が流行した。しかし、どう処置するかは、文字を使用する場所で決まるもので、入力段階では決まらない。入力で処置すると、過剰なエスケープ文字が現れたり、記号を入力できないアプリケーションになってしまうなど、不都合が生じる。

　筆者の記事も当初、入力値を処置するように書いていたが、指摘を受けて、SQL文に埋め込むところで処置するように修正している。

　しかし、「サニタイズ」という言葉は人によってとらえ方が違っていたりして、なかなか正しい考え方が普及しなかった。そこで高木氏が始めたのが「サニタイズ言うなキャンペーン」だった。対策方法を「サニタイズ」という言葉を使わずに説明しようとすれば、間違った対策と正しい対策の違いに気付かされるはずと考えたという。それから5年近くたったいまでは、少なくとも日本では「サニタイズ」的発想はかなり排除することができたと感じていると氏は言う。

【参考】

高木浩光＠自宅の日記 - 「サニタイズ言うなキャンペーン」とは何か

http://takagi-hiromitsu.jp/diary/20051227.html#p02

高木浩光＠自宅の日記 - WASF Times版「サニタイズ言うな！」

http://takagi-hiromitsu.jp/diary/20070203.html#p01

　今回の取材では仲良く握手する写真は撮らせてもらえなかったが、「間違った対策を普及させるな」という高木氏の思いには触れることができた。筆者はこれからも高木氏の舌鋒（ぜっぽう）を恐れつつも、正しいセキュリティ対策を世に広めていきたい。