前回はSQLインジェクション攻撃について解説しました。冒頭にSQLインジェクション対策に関するクイズを5問出しました。

1. SQLインジェクションはエスケープ処理を確実にしていれば大丈夫？
2. プリペアードクエリを利用していれば大丈夫？
3. SQLインジェクションはデータベース構造を知らないと攻撃が難しい？
4. SQLインジェクションはWebアプリケーションファイアーウォールで防御できる？
5. 文字エンコーディングベースのSQLインジェクションは文字エンコーディングが正しければ行えない？

SQLインジェクションクイズの答え

前回の記事で出題したSQLインジェクションクイズの答え編です。前回の記事の解説には答えとなる解説を行っています。もし、答えと解説に疑問を持たれた方は前回の記事をご覧ください。

SQLインジェクションはエスケープ処理を行うだけでは不十分です。「⁠文字列」としてエスケープ処理しないと意味がありません。

杓子定規に「プリペアードクエリ＝安全」と考えていると落とし穴があります。

この答えの解説は前回の記事にはありません。詳しい解説は省略しますが、ブラインドSQLインジェクションと呼ばれるテクニックが利用可能な場合、データベースサーバの種類やテーブル構造をまったく知らなくても、内部構造を分かってしまうようなエラーメッセージがまったく無くても、構造を解析できます。

この答えの解説も前回の記事にはありません。詳しい解説は省略しますが、Webアプリケーションファイアーウォール（WAF）ですべてのSQLインジェクションを防ぐことはできません。国連はWAFを過信したため、SQLインジェクション攻撃によって改竄されたり、マルウェア配布に利用されたりしました（参考：筆者の個人ブログ⁠）⁠。

もし、SQLインジェクション脆弱性がアプリケーションに見つかった場合、WAFで対策を行ったとしても必ずアプリケーションを修正しなければなりません。

文字エンコーディングが正しくても、エスケープにデータベース専用の関数を利用していても、文字エンコーディングベースのSQLインジェクションが可能となる場合があります。

減らないSQLインジェクション攻撃

2年ほど前のSQLインジェクション攻撃は、顧客リスト等の流出が主な被害として報道されることが多かったですが、最近の傾向は変わっています。最近はSQLインジェクションを利用したHTMLインジェクション（JavaScriptインジェクション、IFRAMEインジェクション等）被害が主流になっています。

HTMLインジェクション被害が増えているのには理由があります。PCにルートキットなどを不正にインストールし、ボット化することには経済的なメリットがありあす。PCをボット化する動機が金銭目的であるため、攻撃には効率性が求められます。SQLインジェクションによりコンテンツの改竄（HTMLインジェクション）が成功した場合、クロスサイトスクリプティングのように踏み台となるWebサーバを経由しなくても、常にHTMLインジェクション攻撃が可能になります。IFRAMEを利用し攻撃用サイトへ自動的にアクセスさせる等の手法も確立されています。ユーザエージェントを識別した攻撃は当たり前になってきています。

SQLインジェクションは対策も簡単ですが、脆弱性の検出も簡単です。人海戦術に頼った攻撃のみでなく、最近ではSQLインジェクション攻撃を行うためのボットも増えてきています。SQLインジェクションを脆弱性を検出するツールも増えています。

SQLインジェクション攻撃対策

技術的な対策は既に解説済みです。SQLインジェクション攻撃の対策は非常に簡単です。最も重要な対策はソースコードに脆弱性を入れないことです。システム開発を行う際にはコーディング規約を定めますが、セキュリティ対策規約も必ず定めるべきです。経験豊富な開発者にとってはSQLインジェクション対策は当たり前ですが、脆弱性は一か所だけでも攻撃される可能性があります。すべての開発者が正しくセキュリティ上のリスクと対策を理解するよう開発前にブリーフィングします。そして、コード監査プロセスを必ず取り入れるようにすべきです。可能な限りコード監査は第三者により行うほうがよいでしょう。

防御する側は、攻撃者に比べ、圧倒的に不利な立場にあります。被害に遭わないようにするためには効率的かつ効果的なセキュリティ対策が不可欠です。できる限り上流から適切なセキュリティ対策を施すほうがより高いセキュリティレベルを達成できる可能性が高くなります。