- 【PHP】下らねぇ質問はここに書き込みやがれ [転載禁止]©2ch.net
824 ：デフォルトの名無しさん[sage]：2015/06/16(火) 22:44:11.83 ID:+xig3h/n - >>822
横から口挟むけど、インジェクション対策をしようとしてのバリデーションて話なら、その発想がどこかナナメだということじゃないの？
例えばHTMLエディタを作りましょうって場合に、悪用可能な文字は全部除外してしまえ！とか無理でしょ。
インジェクション対策は、例えどんな文字列が来ようとSQLとか外部コマンド、ユーザーサイドへ出力するHTML、JS、CSS、etc. を混乱させない処理を施すこと(適切なエスケープ、サニタイジング)が基本でしょ。
もちろん目的に敵わない入力を予め除外するというのは前処理として決して的外れではないんだけど、それは本質じゃないってことだ。
そんな当たり前のところで食い下がるって、もしかして本人？
|
- 【PHP】下らねぇ質問はここに書き込みやがれ [転載禁止]©2ch.net
829 ：デフォルトの名無しさん[sage]：2015/06/16(火) 23:07:32.75 ID:+xig3h/n - >>826
バリデーションですり抜ける直接的な文字でインジェクションできなくても、その文字列が直接使われない場所でなら悪用できるかもよ。
メジャーな処理として挙げるわけじゃないが、何かのキーをBASE64で変換してフォームとやりとりしてて、SQLにはそれをデコードしたものを含めてるとか。
だいたい悪用しようとする側からすれば、サーバサイドへ何かを入力する経路はGETやPOSTだけじゃなくCOOKIEだってあるわけで、フォームの項目だけバリデーションすればいいような話はひいき目に見てもミスリード。
対策はそのデータの利用場面に合わせてしか行えない。
だから基本だと言ってるし、それが本質。
|
- 【PHP】下らねぇ質問はここに書き込みやがれ [転載禁止]©2ch.net
831 ：デフォルトの名無しさん[sage]：2015/06/16(火) 23:41:57.96 ID:+xig3h/n - >>830
ほぼ全て云々はおれの主張することじゃないんで見解だけ言えば、バリデーションで全てのケースに対応できるわけないんだからバリデーションでインジェクション対策をするという発想そのものが誤り、かな。
そもそも何故それをバリデーションでやりたいの？って話だよ。
それだけやっとけば後は特別なことをする必要がない包括的な手段として目を付けたということなんだろうけど、それが成立するのは全てのケースに対応できる場合だけ。
それができないというんだから、その方法には特別な価値は無いということだよ。
|