2

少数の人々 (内部のみ) によって使用される Web アプリがあり、ユーザー レコードの下に保存され、さまざまなリンクに配置されるランダム化されたセッション ID を使用しています。

ユーザーが相互にリンクを送信し、送信者のセッションをハイジャックできるという問題がありました。

ユーザーが相互にリンクを送信できるようにしながら、これを防ぐにはどのような方法がありますか?

編集: リンク内のセッション ID ($username も含む) は、User テーブルに格納されているものと比較されます。&incorrectLogin は、エラーの後に die; を出力するだけです。

if ($sid) {

    $sth = $dbh->prepare("SELECT * FROM tbl_User WHERE UserID = '$username'");
    $sth->execute();

    $ref         = $sth->fetchrow_hashref();
    $session_chk = $ref->{'usr_sessionID'};

    unless ($sid eq $session_chk) {

        &incorrectLogin;
    }
}

問題は、誰かが他の人によって作成されたリンクを使用すると、ページがそれらとして読み込まれることです。私は Cookie を使用していません。以前、CGI perl Cookie の処理が非常に貧弱であると言われたことを思い出します。

4

3 に答える 3

4

クエリ文字列に、セッション認証に使用しているすべての情報が含まれている場合は、設計上問題があります。ユーザー名またはセッション ID、またはできれば両方を Cookie に入れる何らかの方法を見つける必要があります。そうしないと、ただの SOL になってしまいます。ユーザーから送信されたリンクに、コードがどのユーザーと話しているかを伝えるために使用するすべてのものが含まれないようにする方法がないからです。

もし私があなたなら、CGI.pm が言われたほど Cookie をうまく処理できないかどうかを調べることから始めます。私が見ることができる他の唯一の代替手段は、アプリケーション内のすべてのリンクを POST 要求に変換することですが、これはさらに壊れており、考えるには恐ろしいものです。

于 2012-10-02T04:10:35.143 に答える
3

私は、Cookieに切り替える前は、現在と同じようにセッション管理を処理していました。今、私はCGI :: Sessionを使用していて、とても満足しています。

ただし、少し早くハックして問題を短期的に解決したい場合は、各セッションのIPアドレスをセッションIDとともに保存することができます。次に、着信IPアドレス/セッションIDのペアが保存したものと一致しない場合は、ログインページにリダイレクトできます。

このアプローチにはいくつかの落とし穴があり、完璧ではありませんが、現在の大きなセキュリティホールを埋めることができます。

于 2012-10-02T20:18:11.563 に答える
3

まず、クエリ文字列 (またはセッション ID) にユーザー ID を含めないでください。セッション ID を受け取ったら、サーバー側に保存されているセッション情報を調べて、そのセッション ID に関連付けられているユーザー ID を取得します。

第二に、一定の非アクティブ状態が続くと、セッションを期限切れにする必要があります。

第 3 に、サーバー側のセッションに 2 つの追加アイテムを保存して、Cookie を使用しない場合でもこれに対処することができます。解決策は完全ではありません。つまり、セッションをハイジャックする可能性はまだありますが、より困難になります。

サーバー側では、ユーザーがログオンした IP アドレスを保存します。別の IP から同じセッションの後続の要求を受け取った場合は、資格情報を再度要求します。クエリ文字列に IP アドレスを含めないでください。

さらに、すべての応答で、 を生成しnext_request_idます。これをサーバー側のセッションに保存し、クライアントにも送り返します。返すページのすべてのリンクにも、これを含める必要がありますnext_request_id。

リクエストを受信したら、受信したnext_request_idがそのセッション用に保存したものと同じかどうかを確認します。そうでない場合は、再認証します。

現在、これはユーザーが複数のタブでサイトを使用したり、再読み込み/更新を使用したりする機能を妨げますが、特定のユースケースでは適切な解決策でした.

ただし、一般的には、Cookie を使用した方がよいでしょう。

プレーンな HTTP で Cookie を使用すると、セッションがハイジャックされる可能性がありますが、少なくとも、この特定の失敗を防ぐことができます。

于 2012-10-02T15:24:15.187 に答える