昨日のＳＱＬインジェクションの話、結局、どういうふうに設計すべき、修正すべきとウィリアムのいたずらの方針を書いていなかったんで、わたしは、こう考える！というのを、書いておきます。
入力データで、入力チェックをしたとしても、ＳＱＬインジェクションをはじくには、アポストロフィーをはじいてしまうか、これをエスケープするしかない。
でも、アポストロフィーをはじいていいのか？という問題がある。
たとえば、ログイン名に、メリーチョコレートだいすき！な人がいて、mary'sにしちゃったら？とか。。。
また、ＳＱＬインジェクションとして、不正アクセスであれば、ログイン名だけの話だけど、それ以外で行うことも考えると（検索でＳＱＬインジェクションをやって、大量の検索をさせて、システムをとまらせる）、本の名前の検索などでは、アポストロフィーが入ることはある。
=でチェックを書けた場合？でも、たしか、モーニング娘。の本になかったっけ？自信ない。
（あ、ぜんぜん関係ないけど、さっき、地震あったねえ、いま、自信ないと打って気付いた）
なんで、入力ではじくというのは無理がある。
ということで、入力チェックで、このＳＱＬインジェクションをやるのは、きつい。
じゃあ、入力の時点で、エスケープしちゃったら？っていうことになるけど、そうすると、こんど、mary'sは、mary\'sになって、文字数が変わってしまう。文字数によって、なにか処理を分けているとかいう場合、後段の処理で問題。
っていうことで、結果として、
・入力チェックは、ＳＱＬインジェクションとかを意識せず、適切に行う
・処理中の内部データはエスケープしないで、文字をそのまま処理する
・ＤＢアクセスのところで、エスケープの変換をかけ、ＳＱＬインジェクションをはじく
→結果として、ここではずく＝サニタイズしてるのとおなじ。
で、ＤＢアクセスのところで、エスケープするのっていうのは、至極あたりまえの話だと思う。
ふつう、入出力のところは、その入出力デバイスにあった形で文字などの情報が変換されるはず。で、その入出力データを他のモジュールが利用するときは、内部表現に変換しておくる。
エスケープというのは、いわば、ＤＢ用のために文字を変えるものなので、入出力モジュールであるＤＢアクセスのところで、エスケープをいれる。それ以前は、内部表現として、エスケープしない、ふつうの文字の形で扱う。
これって、あたりまえの話っすよねえ。
と考えると、設計・修正は、こんなところに落ち着くんじゃないだろうか。
設計は、ＤＢアクセスを共通化し、そのＤＢアクセスの中で、エスケープする。
修正するときも、ＤＢアクセス部分に対して、エスケープ処理をいれる。
ＤＢアクセス部分が、モジュール化（別クラス化）されていなければ、時間があれば、モジュール化する。
つまり、Ｏ／Ｒマッピングとか世間で入ってるけど、ＲＤＢアクセスだけでなく、入出力部分には、そもそも、インピーダンスミスマッチがあるんだから、その入出力部分をモジュール（クラス）として独立させ、それぞれ、利用可能な形に変換して（＝エスケープなどを送って）対応するべきであると思う。
そうすると、ＳＱＬインジェクションは、はじけるので、べつに、入力のところで、エラーチェックをするかどうかというのは、（したほうがいいけど）今回の話にあまり関係するところでは、ないかと思う。逆に入力のところでエスケープすると、エスケープした形が内部コード表現となるので、あとの処理がそれに影響されてしまい、得策ではないと思う。
てなことを考えてます。
アクセス
トータル
ランキング
