web-dev-qa-db-ja.com

ウェブサイトからログアウトする場合、セッションを破棄するために他に必要なものはありますか？

PHPでは、ユーザーがログアウトしたいときにセッションを破棄する前にセッションを開始する必要があるかどうかわかりません。

_session_start();
session_destroy();
_

他に必要なことはありますか？

編集： Stackoverflow に再投稿しましたが、まだ完全には理解していません。

基本的に、ログアウト時に何をする必要があるかを尋ねています。ログイン時にsession_start()を使用してセッションを作成しているので、session_destroy()を呼び出す必要があることはわかっています。いくつかのSO=ページがsession_regenerate_id(true)およびsession_unset()を呼び出すように言っていますが、その理由がわかりません。

web-applicationauthenticationappsecphpsession-management
2
Celeritas

いいえ、これを行うべきではありません。パフォーマンスの向上を最小限にするためだけではありません。良い習慣だと思ったきっかけはわかっていますが、PHPマニュアルのこれら2つの引用符をもう少し詳しく分析してみましょう。

session_start() GETまたはPOSTリクエストを介して渡された、またはCookieを介して渡されたセッション識別子に基づいて、セッションを作成または現在のセッションを再開します。

session_destroy()現在のセッションに関連付けられているすべてのデータを破棄します。セッションに関連付けられているグローバル変数の設定を解除したり、セッションCookieの設定を解除したりすることはありません。セッション変数を再び使用するには、session_start（）を呼び出す必要があります。

わかりました。また、SOの投稿で、ユーザーがこのコードを実行するこのURIに直接移動できる可能性があることも述べています。これを行うべきではなく、セッションを開始する前に、少なくともユーザーのログインデータとリファラー文字列を確認し、ユーザーの状態が変化するたびにセッションを削除する必要があります。ただし、コードを変更しておらず、問題のURIに移動できるとします。次に、このシナリオ：

  • 正当なユーザーのコンピューターの1つであるネットワークにアクセスでき、同じIPを介してWebアプリケーションにアクセスでき、クライアント側のセッションデータを収集できます
  • POSTまたはこのコードを実行しているURIへのセッションデータなしのGETリクエストを作成します
  • 変更したブラウザーでアクセスできるこれらのセッションフラグメント（セッションCookie、ユーザーエージェント文字列）を手動で追加します

Voila！

これらはすべて簡単に実行でき、対象となるユーザーのコンピューターに直接アクセスできる多くの人々は、知識さえあれば、そのようなことを実行するための手段と理由があります。そして、あなたはそのバーを少し下げています。

何が起こるか見てみましょう。

session_start()は、Webサーバーでセッションが無効になる前に呼び出され（session_destroy()で発生）、新しいユーザーセッションを効率的に作成します。次に、新しいセッションデータを古い（盗まれた）データに置き換えることができます。Webアプリケーションには、ユーザーエンドセッションデータに基づいて、最初にセッションが作成されたユーザーではないことを疑う理由がありません。場所。セッションデータを盗んだ前のユーザーであるかのように再開します。

意図した順序でセッション処理ルーチンを使用する場合、これはセッションハイジャックとどう違うのですか？

@Xanderを分析する長い議論でPHPセッション処理ルーチンは、それがその意味でほとんど何も変更しないという結論に達しました。しかし、それを実行しても何も得られません。 PHPアプリケーションが依存している場合、サードパーティのユーザーセッションフレームワークの機能が損なわれる可能性があります。関連するSO質問「ユーザーがこのページに直接移動した場合、セッションを破棄するときにエラーが発生する可能性があるのではないかと心配しています」は、本質的に有効になっているという別の懸念を明らかにしています作成する前にユーザー認証なしで無料でユーザーエンドセッションデータ構造を調べます。発言「しかし、すぐに削除します！」は、この意味では実際には適用されません。session_destroy() "...は、セッションに関連付けられたグローバル変数の設定を解除したり、セッションCookieの設定を解除したりしないためです。 "別の言い方：

セッションのハイジャックが少し簡単になりましたが、逆ではありません！

TL; DR-つまり、簡単に言えば、それを行う必要があります '退屈で標準的な方法'これら2つのセッション変更ルーチンが実行されるように設計された順序。

2
TildalWave

それはあなたの特定のアプリケーションが実際に何をするかに完全に依存していますが、私が提案する1つの一般的な追加のガイドラインはあなたが作成したCookieを破壊することです。

1
Xander

OWASPを使用している場合、接続をセキュリティで保護し、セッションを安全に維持する方法についてはたくさんあります state。 新しい接続を安全に開始する方法についての素晴らしい説明を提供します。 一部は

  1. 暗号化されていないページからログインプロセスを開始しないでください。認証プロセスやセッションの盗用、フィッシング攻撃、セッション固定攻撃を防ぐために、常に新しいまたは新しいセッショントークンを使用して、2番目の暗号化されたページからログインプロセスを開始してください。

  2. 認証または特権レベルの変更が成功したら、新しいセッションを再生成することを検討してください。

  3. 「remember me」タイプの機能や自社開発のシングルサインオン機能など、認証またはセッション管理の目的でカスタムCookieのコードを制限または削除します。これは、堅牢で実績のあるSSOまたはフェデレーション認証ソリューションには適用されません。

これが test クッキーの再利用/修正です

1
Saladin

Acadion Securityは、Webアプリケーションにユーザーセッションを安全に実装する方法に関するホワイトペーパーを公開しています。ログアウト時にセッションが破棄されるだけでなく、次の場合にもセッションが破棄されます。

  1. タイムアウト
  2. ログアウト
  3. 暗号化されていない転送
  4. 間違った起源
  5. 二重ログイン
  6. パスワードのリセット
  7. ユーザーエージェントの変更
  8. 時折セッションの再生

詳細は論文 here にあります。

1
void_in