4

私は、ユーザーが自分のアカウントを持つことができるPHPを使用してWebアプリケーションを開発しており、ユーザーを追跡するセッションはMySQLデータベースに保存されます。さて、これを実装する方法についての答えを探した後、私は多くの人々がsession_destroy()クッキーを使用することと設定を解除することの両方を好むことがわかりました。なぜ-session_destroy（）だけでは十分ではないのでしょうか？PHPのマニュアルでさえ、 「ユーザーをログアウトするなど、セッションを完全に強制終了するには、セッションIDも設定解除する必要があります」と記載されています。

私の推論：ユーザーがログアウトした後、サイトを離れる前にたまたまサイトのもう1つのページにアクセスすると、ユーザーがログインしているかどうかを確認するPHPスクリプトがsession_start（）を呼び出し、ユーザーの新しいセッションCookieを設定します。とりあえず。次のようになります。

// here we include some scripts and make some instances we'll need
require_once("database.php");
require_once("session.php");
$database_connection = new DB_Connection();
$session = new Session($database_connection);

// here a session cookie is sent to a user, even if he or she isn't logged in
session_start();

// finally we check if the user is logged in
$log_isLogged = false;
if(isset($_SESSION['member_id'], $_SESSION['username'])){
    $log_member_id = $_SESSION['member_id'];
    $log_username = $_SESSION['username'];
    $log_isLogged = true;
}

確かに、ユーザーがこの事実を知っていて、新しいCookieが設定される前にサイトを離れる場合に便利です。ただし、一部のサイトでは、ログアウト直後に新しいページにリダイレクトされ、新しいセッションCookieが生成されます。これにより、実行した内容が元に戻されます。

私の推論には何らかの欠陥がありますか、それともセッションCookieの設定を解除しても問題ありませんか？たぶん、ほとんどの開発者は、少なくともそれを設定解除することは害にはならないだろうと考えていますか？

私はネイティブスピーカーではありませんので、タイプミスや文法上の誤りについて事前にお詫び申し上げます。

4

1 に答える 1

9

（名前が不適切な）session_destroy()関数は、セッションからデータを削除するだけです。ブラウザからセッションCookieを削除せず、session_idをセッションに関連付けたままにします。session_start()クライアントの要求でまだ提供されていない場合にのみ、新しいsession_idをクライアントに発行します。コードは、セッション固定と呼ばれる攻撃に対して脆弱です。、悪意のある攻撃者がサイトでセッションを開始して有効なsession_idを取得し、サイトの疑いを持たないユーザーをだまして攻撃者の既知のsession_idでログインさせます。これは、被害者にURLにsession_idを含むリンクを送信するか（サイトがそのように受け入れる場合）、または他のさまざまな方法で実行できます。被害者がログインすると、攻撃者も同じユーザーとして効果的にログインします。

セッション固定攻撃を防ぐには、次のことを行う必要があります。

  1. ログインに成功したら、を呼び出してクライアントに新しいsession_idを発行しますsession_regenerate_id()。

  2. ログアウト時に、サーバーとクライアントの両方でセッションのすべてのアーティファクトを完全に破棄します。これは、を使用してクライアントCookieを呼び出して設定を解除することを意味します。session_destroy() setcookie()

  3. サイトがURLでsession_idを公開したり、URLで提供されたsession_idを受け入れたりしないようにしてください。

  4. session_idsが十分に長くランダムであるため、攻撃者が実際に推測することはできません。

  5. サイトがクロスサイトスクリプティング攻撃に対して脆弱でないことを確認してください。これにより、攻撃者はすでにログインしているユーザーから有効なsession_idを盗むことができます。

  6. ログインがhttps経由で行われ、セッションCookieが安全であるとマークされていることを確認してください。セッションに関連するすべての通信は、httpsを介して行う必要があります。クライアントのsession_idは、転送中に公開されるため、http経由で送信しないでください。

詳細参照： セッション管理に関するOWASPトップ10ページ

于 2011-08-03T15:17:07.583 に答える