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

なぜSQLインジェクションはなくならないのか

　SQLインジェクションの対策を紹介する前に、SQLインジェクションがなくならない訳について考えてみよう。そのほかの脆弱（ぜいじゃく）性とも共通するが、図1-1の理由が考えられる。

　つまり「セキュリティーに対する認識の低さ」「セキュリティーに対する技術・知識の低さ」「経済的理由」が大きな理由のようだ。このような現状を踏まえ、どのような対策が可能かを紹介する。

SQLインジェクションの技術的対策は難しくない！

　SQLインジェクションの脆弱性をなくすには、「バインド機構（バインドメカニズム）」や「エスケープ処理」を適切に使用し、正しく実装すればよい。

　しかし、バインド機構は一部のデータベースサーバーでは利用できない。その場合は、エスケープ処理を利用して対策することが有効だ。それぞれを利用した実装方法を説明しよう。

　バインド機構とは、あらかじめSQL文のひな型を用意し、後から変動個所（プレースホルダ）に実際の値（バインド値）を割り当ててSQL文を生成するデータベースの機能だ。SQL文のひな型とバインド値は個別にデータベースに送られ、構文解析されるので、バインド値に悪意あるSQL文が挿入されても、その実行を阻止することができる（図1-2）。

　　SQLステートメントを書く時に必ずバインド機構を使用すれば、バインド機構に不具合がない限り、SQLインジェクションは不可能だと考えられる。

　ただし、データベースの種類によっては、バインド機構を使用した場合、LIKE句やユーザー定義関数などの引数にバインド値を指定すると、開発者の思惑どおりの動きをしない場合がある。そのため「%」や「_」といったワイルドカード文字がバインド値として送られないように値検証処理でエラーにしたり、エスケープしたりする必要がある。

　有効な対策方法はデータベースの種類によって異なるのでベンダからの情報を参照していただきたい。

　続いてエスケープ処理を説明する。ここでは、SQLインジェクションのために挿入された文字列を攻撃が成功しないように文字列の置き換えを行う処理を指す。例えば、「’」を「’’」に変換し、「\」を「\\」に変換するなどの処理である。

　エスケープ処理は、SQL文を生成する直前に実施するのが定石である。入力直後にエスケープ処理を行うと、SQL文を生成する直前に別の文字列操作が行われた場合、SQLインジェクションが成功する文字列が完成してしまう可能性があるからだ。

　また、エスケープ処理を行う際には日本語などのマルチバイト文字に対する処理がきちんと行われている必要がある。詳しくは次ページで紹介する。

　なお、エスケープ処理の必要がある文字列はデータベースサーバーによって異なるので、利用環境に合わせて実施しなければならない。エスケープ処理は、自作で実装するよりも、データベースサーバーの開発元やプログラム言語で用意されているもの、あるいは言語を利用している開発者コミュニティーで広く利用されているものを利用するとよい。自作の実装では漏れが起きやすく、機能の仕様が適切に引き継がれていない場合、データベースサーバーの仕様変更や、新たな脆弱性への対応が適切になされない危険性があるからだ。