2009年4月24日(金曜日)

公開: 2009年4月29日13時55分頃

この記述には度肝を抜かれました。

SQLインジェクションは、予期しない変数や命令文に対処できないアプリケーションの脆弱性です。根本的な対策としては、アプリケーションに渡す変数をすべて文字列に変換すれば、SQLインジェクションを100%防ぐことができます。

文字列に変換すれば100%防げる!?

SQLインジェクションはそもそも、「1 OR 1=1--」とか「foo' OR 1=1--」とかいった文字列を渡して攻撃するのです。文字列を文字列に変換しても何も起きないわけでして、全く意味のない話だと思うのですが……。よく見ると、続きにはこう書いてあったりします。

これをエスケープ処理と言いますが、現実問題としてすでに稼動しているWebアプリケーションに対して、このような対策を行うことは容易ではありません。

……いや、文字列に変換することを「エスケープ処理」と言ったりはしないですよ……。

というわけで何のことを言っているのか全く分からなかったのですが、徳丸さん (www.tokumaru.org)のブックマークコメントで理解しました。

これは大垣メソッドのコピペでは? 参考 http://gihyo.jp/dev/serial/01/php-security/0005?page=2 (gihyo.jp)

ここで言う「大垣メソッド」とは、「なぜPHPアプリにセキュリティホールが多いのか? 第5回　まだまだ残っているSQLインジェクション (gihyo.jp)」の「すべての変数をエスケープする対策」の項で述べられている手法です。単純に、SQL文に連結するすべての変数に対して、「エスケープして引用符で括る」という処理を行います。

この手法はSQLインジェクションの対策としては有効です。ただし、数値型の値も引用符で括ると文字列として扱われてしまいますので、本来必要ないはずの型変換が発生します。そのような型変換は望ましくないのではないか、という議論があります (「変数に型のない言語におけるSQLインジェクション対策に対する考察(5) 数値項目に対するSQLインジェクション対策のまとめ (www.tokumaru.org)」)。

※このあたりは以前、徳丸さん・大垣さん交えて直接議論させていただいたことがありますが、楽しかったですね。

ともあれ、いわゆる大垣メソッドのポイントは「エスケープする」ということです。すべての変数を文字列として扱うのは、一律に同じエスケープ処理を適用できるようにするためです。文字列として扱うという点は、対策の要ではないのです。

要は、大垣さんが「文字列として扱い、かつエスケープ処理を行う」と言っているのに、それが「文字列に変換する。これをエスケープ処理と言う」に翻訳されてしまったという話なのですね。SQLインジェクションの仕組みを理解していないと、こういう誤解もあり得るということなのでしょう。

※昔、別件で「他人のセキュリティ解説を理解しないままコピペする人がいて怖いよね」という話をしたことがありますが、まあ、なかなか難しいですよね。

関連する話題: Web / セキュリティ