"';";sql_qeury($sql);}//通常のログアウト処理まとめ自動ログイン機能は基本的にセキュリティ上のリスクを増加させるので安全性が重要なサービスでは実装しない。自動ログインの実装にはセッション管理と同様にランダムなクッキーの値を使用する。自動ログイン用のクッキーはログインの度に新しい値に更新する。(古い鍵の削除も忘れない)ログイン時に自動ログインオプションが無効かつ自動ログイン用のクッキーが設定されている場合は自動ログインテーブルの該当レコードと自動ログインクッキーも削除する。自動ログイン用のクッキーは自動ログイン処理を行う場合にのみ必要なので自動ログイン専用のディレクトリを設定し、そのディレクトリのURLがリクエストされた場合にのみ送信する。(XSSリスクの低減)ログアウトした場合、自動ログインクッキーが設定されている場合、自動ログインテーブルの該当レコードと自動ログインクッキーも削除する。実際の運用では古い自動ログイン用のレコードが溜まるので定期的に不要なレコードを削除する。自動ログイン用のクッキーを送信しているにも関わらず、自動ログインが成功しない場合は第三者に自動ログイン用のクッキーを利用された可能性がある。(JavaScriptでPCの時間を送ってもらう必要あり。時間設定の誤差と時差に注意。)ユーザに注意を喚起するのも良い。/dev/urandomなどエントロピーファイルが利用できる場合は自動ログインキーの作成に利用する方がよい。(PHPの乱数関数でrandより良いとされているmt_randの実装も今ひとつと評価している人も多い)ユーザ名、パスワード等、ユーザ情報をクッキーに保存するのは非常に大きな問題です。多くのユーザは複数のWebサイトのアカウントに同じユーザ名とパスワードを使用しています。自分のサイトのみでなく他のサイトにも迷惑をかける可能性が非常に大きいです。ハッシュ化、暗号化の有無を問わずクッキーにいかなるパスワード情報でも保存するのは間違いです。ところで、データベースにパスワードを保存する場合は必ず”salt”付きでハッシュ関数を使った値をパスワード情報として保存するべきです。‘some-random-string’);追記:現在のPHPではpassword_hash()を利用すべきです。する事によって万が一、SQLインジェクション、DBバックアップの流出等によってパスワード情報が漏洩した場合でも”salt”が分からない場合はパスワードを推測できません。(slatが無いと弱いパスワードは辞書攻撃で簡単に判別できます)自動ログインコードに問題があったブログでもパスワードはMD5でハッシュ化されています。saltは利用されていないのでこの点は改善の余地があります。saltとパスワードを一緒にハッシュ化すれば辞書攻撃が難しくなるので問題のブログアプリも「パスワードをsaltと一緒にハッシュ化したパスワードをクッキーに保存すれば良いのでは?」と考えられるかも知れません。確かにセキュリティ上のリスクは比較にならないほど改善しますが、この方法だと「攻撃可能領域の最小化の原則」に適合しません。(正しい設計では元々ユーザ情報をクッキーとして保存する必要はない。salt付きでハッシュ化したパスードでも解読される可能性はある。これらの理由から「攻撃可能な領域」を増やす結果となる)さらに「パスワードをsaltと一緒にハッシュ化した値」はパスワードかslatを変更しない限り変化しません。したがってこの方法は再生攻撃に非常に脆弱になります。認証コメントは受け付けていません。紹介エレクトロニック・サービス・イニシアチブのWebシステムのコンサルタントのブログです。PHPの開発、PHP4.x/5.xレガシーPHPセキュリティパッチサービスなどを行っています。ブログのサブタイトルを「書かない日記」としているのは、ブログを始めた時にあまり書かないつもりで始めたのでこのサブタイトルになっています。yohgaki@ohgaki.net私が記述したブログ中のコードは記載が無い場合はMITライセンスです。その他のコードは参考リンクなどのライセンス情報を参照ください。