2012-07-18 16 views
5

私のコードには、ログインしたユーザー名とユーザーIDへのクイックアクセスが必要な例がたくさんあります。私は現在クッキーを使っています。これは安全ではありません。ユーザー名とユーザーIDはどこに保存されますか?セッションやクッキー?

私はセッションが解決策だと思っていましたが、セッションは終了します。

別のオプションは、一意のトークンをクッキーに格納し、データベースの格納されたトークンと照合して、ログインしたユーザーデータを取得することです。これは最も安全な解決策ですが、私が見るこの問題は、ログインしたユーザー名とユーザーIDが必要なコードは何度もありますが、常に問合せするとリソースが不要になります(これは本当ですか?)

解決策は何ですか?

+3

セッションを使用し、セッションの有効期限を長くします。 – Dhruvisha

+2

[フォームベースのウェブサイト認証のための完全なガイド](http://stackoverflow.com/questions/549/the-definitive-guide-to-forms-based-website-authentication)を読むことを強くお勧めします。 – Polynomial

答えて

3

クライアント上で必要でない場合は、クライアント側で終了しないようにしてください。

userIdは特定のコンピュータではなくログインしているユーザーに固有のものなので、クッキーは行き過ぎのようには見えません。

PHPでの基本認証は、通常セッションで行われるため、セッションにuserIdを追加するだけで済みます。

セッション時間が短すぎる場合は、セッション時間を長くします。

+1

ありがとう、最後の質問。私が割り当てることができる最大のセッション時間は何ですか?私はユーザーが辞任し続けることを望んでいません。また、セッションが終了した場合(セッション時間が長くなっても)はどうなりますか?セッションが終了したら、データベースからユーザー名/ユーザーIDを取得してセッションを再設定する必要がありますか? – user892134

+1

ユーザーがサインインし続ける必要がないようにするには、ワンタイムトークンに基づくalways-remember-meシステムを使用します。セキュリティの要求に応じて、セッションのタイムアウトを比較的短く(10〜60分の間)してください。 「フォームベースのウェブサイト認証への確実なガイド」*の「第2部:ログインしたままにする方法 - 悪名高い」のチェックボックス*(http://stackoverflow.com/questions/549/the-definitive-このような機能を安全に処理する方法の詳細については、Webサイトへのアクセス(ガイドからフォームベースのWebサイト認証)を参照してください。 – Polynomial

+0

許可されている場合は、PHPのデフォルト設定を次の行で上書きすることができます。 'ini_set( 'session.gc_maxlifetime'、 '28800'); //セッション時間を4時間に設定します。 またはphp.iniファイルを編集します(実際に行う必要があります)。 セッションが終了すると、ユーザーはログイン画面に戻ります。 –

-4

私はそのような情報をデータベースに保存し、起動時にグローバルオブジェクトレジストリにユーザーオブジェクトを作成します。ユーザオブジェクトは、ユーザ名や電子メールのような情報を保持し、それらの情報の変更を可能にする。ログインステータス自体は、セッションにもCookieにも格納されます。

+3

これは、セキュリティの観点からは非常に悪い考えです。 – Polynomial

+0

@Polynomialどのように安全でないのですか?情報をデータベースに保存するか、またはクッキーを使用してユーザーを識別するには?彼があなたのサイトに戻ったとき、どのようにユーザーを認識するでしょうか? – feeela

+0

ログインし直してください。 セッション識別子のクライアント側を保持することはセキュリティ上のリスクです。 このようなクッキーは理論的に盗まれ、誰かのセッションを乗っ取るために使用される可能性があります。 –

4

私はコメントの中で言われたすべてをひとつの答えにまとめるつもりです。そのように、他の有益なユーザーに、彼らの回答/コメントをアップアップすることによっていくつかの愛を示してください!セッションの仕組みを簡単に紹介し、より多くのユーザーに役立てるための解答を行います。

ユーザーがWebサイトにログインすると、そのユーザーを識別するためのセッションが作成されます。セッションは、セッションIDを作成し、そのIDをサーバ側の変数ストアに関連付けて、PHPスクリプトで$_SESSIONスーパーグローバルを使用してアクセスすることで、PHPで処理されます。セッションIDは、クライアント側のクッキーに格納され、セッションを識別します。

セキュリティを確保するために、セッションIDは一意で、ランダムで、かつ秘密でなければなりません。攻撃者がセッションIDを推測すると、同じIDを使用して自分のコンピュータにCookieを作成し、セッションを引き継ぐことができます。彼らはあなたとしてログインします!これは明らかに悪いので、PHPは強力な乱数ジェネレータを使用してセッションIDを作成します。物事をより安全にするために、サイト全体でSSLを有効にして、HTTPS専用フラグを使用してSSL経由でCookieを送信するようにブラウザに通知することができます。しかし、これはあなたのサイトにとって過度のものかもしれません。

セッションに漏れたセッションIDが永遠に役に立たないようにするため、または店に出た後に悪質な人があなたの部屋に潜入するのを防ぐために、セッションはタイムアウトを使用します。合理的な短期間(セキュリティ要件に応じて10分から60分の間)に有効期限を切ることをお勧めします。アクティブなユーザーがログアウトしないように、ページを表示するたびにタイムアウトをリセットすることができます。

ユーザを覚えておくためには、認証トークンとして機能するCookieを提供する必要があります。このトークンは、すべての目的と目的のために、パスワードを持つことと同じであることに注意してください。つまり、悪意のある人がクッキーを盗むと、あなたのアカウントにログインできます。このオプションを安全にするために、ワンタイムトークンを使用できます。これらのトークンは、使い捨てで、ランダムで、長く、秘密でなければなりません。それらがパスワードであるかのように扱います!

は、ここでそれらを実装する方法は次のとおりです。

  1. ランダムなトークンを生成します。可能であれば/dev/urandomを使用してください。それ以外の場合は、mt_randから数百の値を取得して、「ランダム」なものを取得し、結果の文字列をSHA1でハッシュしてトークンを生成してください。
  2. 強力なパスワードハッシュアルゴリズム(PBKDF2またはbcryptなど)を使用して、トークンのハッシュを作成します。この目的のためにSHA1またはMD5を使用しないでください - パスワードをハッシュするようには設計されていません!
  3. ハッシュをデータベーステーブルに、それが所属するユーザーのIDと作成日と一緒に挿入します。
  4. ユーザー側のCookieにトークンを設定します。
  5. ユーザーがサイトにアクセスし、ログインしていないときにログイントークンクッキーが検出された場合は、手順2で使用したのと同じアルゴリズムを使用してクッキーからトークン値をハッシュし、データベースで検索します。エントリと一致する場合は、そのIDでユーザーをログインします。
  6. データベースからエントリを削除し、新しいエントリを発行します(手順1に戻る)。

非常に古いセッショントークン(3か月以上など)を探して削除するスクリプトも実行する必要があります。これにより、長期間使用しないと戻ってくると、ユーザーは再度ログインする必要があります。

これ以上の説明と安全なウェブフォームログインシステムに関する多くの重要な情報については、The Definitive Guide to Forms-Based Website Authenticationを読んでOWASP projectをご覧ください。

関連する問題