ログインが成功するとセッションにユーザー名を記録し、ログインしているかどうかは各ページでsession_is_registered()を用いてユーザー名があるかどうか判断するphpをincludeして調べています。
が、何だか頼りない気がします。
セキュリティ面では大丈夫なのでしょうか?
色々調べてみるとセッションIDを管理するDBがあったほうが良いとか・・・。
一般的に(例えば、"はてな"とか)はログイン処理はどのように行っているのでしょうか?
また、session_set_cookie_params()はすべてのsession_start()の前に記述しなければならないのですか?
情報をお願いします。
HTTPでセッションIDを利用したシステムで、セキュリティ上の不安で真っ先に思いつくのは、セッションIDが盗まれることでしょうか?
もし、セッションIDが盗まれたとしたら、サーバ側でやれることはない気がします。
セッションIDはブラウザとWEBサーバとの間でやり取りされるものです。
対策としては、HTTPSを使う(暗号化)。セッションIDを毎回変える。などでしょうか。
こちらのサイトが非常に参考になります。
大丈夫ではありません。
生のユーザー名をsessionに登録するということは、簡単に“なりすまし”ができてしまうためです。最悪の場合、セッションハイジャックされます。
「はてな」がどうなっているか知りませんが、一般的には下記のような方法をとります。
セッションIDを管理するDBがあったほうが良いとか
上記のように、セッションIDからユーザー名を類推されないようにされていないと、ファイルで管理しようがDBで管理しようが、リスクは同じです。むしろ、SQLインジェクション対策が行われていないDBではリスクが高まってしまいます。
session_set_cookie_params()はすべてのsession_start()の前に記述しなければならないのですか?
sessionを cookie で管理しているのであれば、その通りです。
回答ありがとうございます。
参考にさせて頂きます。
>ログインが成功するとセッションにユーザー名を記録し、ログインしているかどうかは各ページで
>session_is_registered()を用いてユーザー名があるかどうか判断するphpをincludeして調べています。
>が、何だか頼りない気がします。
>セキュリティ面では大丈夫なのでしょうか?
SSLがかかってるのなら大丈夫でしょう。
あと、重要な処理の局面では、再度、ユーザー名とパスワードを入力させます。
回答ありがとうございます。
私の場合はログインしているかどうかのセッション情報のほかに
HTTP_USER_AGENT などのブラウザ情報やホスト情報が一致するかどうかの判別をしています。
HTTP_USER_AGENT なども偽装できるそうなのでセキュリティは万全ではないですが、
ログインしているかどうかの情報だけよりは良いと思います。
pahoo さんの「サーバ側でユニークな文字列を発生し、sessionに登録する」というのは
ユニークな文字列の作成方法が分からなければ偽装しようがないので
もっといいと思います。(私も勉強になりました。)
回答ありがとうございます。
ブラウザ情報やホスト情報を使うアイディアは面白いと思います。
参考にさせて頂きます。
回答ありがとうございます。
質問が曖昧でしたね。申し訳御座いませんでした。
どちらかと言えば、セッションに変数を定義しているかどうかでログインを判断するということが心配でした。
後は、ユーザー名を直接代入している点とか・・・。