O/Rマッピングとバインドメカニズム

なんでO/Rマッピングとバインドメカニズム(PreparedStatement)がSQLインジェクション対策に有効化というと、どちらも、扱うデータの型を自動的に判断してくれるからだと思う。

O/Rマッピングの場合は、設定ファイルで、テーブルの項目の型を指定する。また、バインドメカニズムの場合は、コードの中で、プレースホルダ「?」に自動若しくは、プログラマが型を意識して代入する。
その結果、これらの仕組みが自動的にエスケープ処理を行ってくれて、SQLインジェクション耐性が強い。

一方、文字列としてSQL文を扱って、検索条件などをプログラム外部由来のデータから作っている場合、O/Rマッピングや、バインドメカニズムが自動的にやってくれる型の判断及び制御をプログラマが意識して行わなければならない。
結果としてエスケープ処理が漏れ、SQLインジェクション耐性が弱い。

というわけで、O/Rマッピングやバインドメカニズムを使えば万々歳というわけには行かないのが、ちと困ったところ。とはいえ、ここからは検証が必要なんだけど、DBが扱う文字コードと、アプリ側(若しくはフレームワーク、言語側)が扱う文字コードが異なる場合、困ったことが発生することがある。特にフレームワーク側の文字コードがUnicodeでDB側がSJISやらJIS、EUCの場合は適切に処理してくれない。とりあえず、JavaとMySQLの場合のバインドメカニズムは試したけど、他も要検証。多分、他も同じだと思う。

結論としては、DBアクセスが必要な場合、O/Rマッピングか、バインドメカニズムを作った上で、アプリ側とDB側の文字コードは全て統一しようと言うことで。