とりあえず今持っている知識で以下の対応をしました。
ユーザーからの入力データをextract($_POST)で受け取らない。
ユーザーからの入力データをSQLに渡す場合は全てmysql_real_escape_string処理をする。
ユーザーからの入力データを画面に表示する場合はhtmlspecialchars処理をする。
この3点のみ対処しました。
ただ、もちろん他にも様々な穴があると思います。そこで「こんな対処もしないとダメだよ」といったアドバイスをお願いします。
私の作っているサイト情報を実際に見ないと難しいのは重々承知しておりますが、「一般論」で構いません。総合的に技術を理解している方からのご意見をお待ちしております。
Zend社が指針として出しているレベルは最低限おさえておくと良いのではないかなと思います。
http://www.zend.co.jp/tech/index.php?%A5%BB%A5%AD%A5%E5%A5%EA%A5...
(Zendの認定試験にはこの程度の内容が出題されてましたし)
範囲チェックを行う。
例えば、1ページの表示数で10~50等のリストフォームがあって、これを元に項目を表示する場合、リスト値を書き換えられてマイナスであるとか、大きい数値を送られた場合に、膨大な処理を行うことでシステムの応答速度が低下する恐れがあります(DoS攻撃)
ですので、範囲が10~50などと決まっているのならば、
if($val<1 or 50<$val) die();
等のようにして、想定外の範囲を除去します。
DoS攻撃ってよく見かけますがそういう事なんですね。検索結果をPear Pagerで制御しようと思っていたのですが、アドバイスを頭に入れて作ります。
もう古い話になるかもしれませんが、WEB2.0の基本的な概念として「ユーザーを信頼する」ってあると思います。とことん性善説ですよね。
でもサイトのバックエンドは全く逆の考え方で作らないといけないんだと認識してきました。アドバイスありがとうございます。
PHPの界隈でセキュリティといえばこの人(と勝手に思ってます)
Pear::Auth使っているとの事ですが、
そしたらついでに(?)DB関連もPEAR::DBにしてみたらどうですか?
PEAR::DBのmysqlのクラスでは、内部的にこんな処理が入ってます。
明示的にescapeしなくても、ここを自然に通るようになっています。
function escapeSimple($str) { if (function_exists('mysql_real_escape_string')) { return @mysql_real_escape_string($str, $this->connection); } else { return @mysql_escape_string($str); } }
(というわけで回答二回終わり~)
なるほど、PEAR::DBはそんなに親切な事をやってくれるんですね。イマイチPEAR::DBを使うメリットというか意味がよくわかってなかったのですが、色々と便利な機能があるのでしょうか。ちょっと探ってみようと思います。
ありがとうございます。とりあえず3までは自分で意識しているつもりです。(もちろん穴はあると思いますが)
それより下はほとんど初めてみますね。これから勉強したいと思います。