0

この atricle
http://shiflett.org/articles/session-fixation
からセッション固定攻撃を学習したばかり ですが、この攻撃を防御するために、session_regenerate_id() の使用法がわかりませんか?
攻撃者が URL にセッション ID を含め、サーバーにこのセッションを使用したいと言った場合、このセッションに関連するすべてのセッション変数は攻撃者用であるのに、ID の再生成が役立つのはなぜですか?
ありがとう

4

3 に答える 3

2

Web サイトの存続期間中、多くの「セッション」が発生します。これらの各セッションは ID によって識別され、Web サイトが誰であるかを認識し、異なる要求間で状態を維持できる方法です。

セッション固定攻撃は、セッション ID を把握できる場合にのみ可能です。一部のサイトでは、異なる実際のブラウジング セッション (「Remember Me」機能とも呼ばれる) の間でセッションを持続させることができますが、同じセッション ID が使用されると、この攻撃に対してより脆弱になります。

私があなたのセッション ID を入手した場合、そのセッション ID が有効である限り、あなたになりすますことができます。を使用するsession_regenerate_idと、古い ID は無効になり、傍受された可能性のある人にとっては役に立たなくなります。ユーザーが自分自身を正常に認証した後に新しい ID を生成すると、セッション ID を取得しようとしても、認証されたユーザーの有効な ID が得られなくなります (ユーザーが自分自身を認証する前に持っていた「匿名」セッションのみ)。つまり、攻撃者は匿名ユーザーの「なりすまし」しかできません。

一部のよりセキュリティ意識の高いフレームワークは、ユーザーがログインするたびにではなく、ブラウジング セッション内で実際にセッション ID を再生成します (2 ～ 3 分のタイムアウトを使用)。ネットワーク上でパケット スニッフィングを介してセッション ID を取得することから保護するのに役立ちます。セッション ID は、リクエストに応じてのみ再生成できます。

于 2013-11-14T12:06:34.627 に答える
2

留意すべき重要な点は、セッション状態を維持するために、リクエストごとにクライアントが現在のセッション ID をサーバーに報告することです。レポート メカニズム自体 (Cookie や URL パラメーターなど) は、ここでは重要ではありません。

サーバーの観点からは、高度な予防措置が講じられている¹を除いて、クライアントによって報告されたセッションIDは信頼できます。サーバーは、特定のクライアントの「正しい」または「実際の」セッションIDの概念を持っていません。クライアントは、彼らが言う人です。

もちろん、これは疑問を投げかけます: では、私があなたのアプリケーションで何かを行う権限を持つサイト管理者であると宣言するのを妨げているのは何ですか? 本当の管理者のセッションIDがわからないという事実だけです（本当の管理者がセッションを持っていると仮定して）。もしそうなら、私は管理者になりすまして、彼らができることは何でもすることができました.

では、攻撃者の観点から、管理者のセッション ID を知るにはどうすればよいでしょうか? 管理者をだまして、自分で選択した特定のセッション ID をサーバーに報告させるとうまくいきます! これがセッション固定攻撃の本質です。

この攻撃の影響を防止または緩和する方法はいくつかあります。そのうちの 1 つは、サーバーにクライアントに「セッション ID を変更しました。今後はこれを使用してください」と通知させることです。もちろん、クライアントは強制的に従う必要はありませんが、フレンドリーなクライアントはもちろんそうします (そして、サーバーはクライアントが敵対的であってもクライアントの認識を拒否できます)。そのため、攻撃者が管理者をだまして攻撃者が知っている特定のセッション ID を使用させたとしても、サーバーがクライアントに別のセッション ID に切り替えるように指示しない限り、攻撃は機能しません。

そして、それはまさにそれsession_regenerate_idです。

¹ 高度な予防措置: たとえば、サーバーは、各セッション ID に対してクライアントが最後に使用した IP アドレスを追跡する場合があります。特定のセッション ID を持つリクエストが別の IP アドレスから送信されていることをサーバーが確認した場合、それは疑わしいと見なされる可能性があります。もちろん、この単純化された例では、最新のインターネット インフラストラクチャの高度化を説明することはできませんが、考え方は明らかです。高度なセキュリティ サービス (Gmail など) は、同じタイプの洗練された技術を使用して、疑わしいアクティビティを検出および防止します。

于 2013-11-14T12:52:42.107 に答える
1

セッション ID が URL に含まれていて、攻撃者が何らかの方法で別のユーザーをこの URL にアクセスさせた場合、攻撃者はセッション ID を知ることができます。

たとえば、攻撃者がこのコード スニペットを自分の Web サイト " evil.com" (簡潔にするためにセッション ID を省略) に配置したとします。

<a href="https://www.example.com/login.php?PHPSESSID=a123">Login to site to continue</a>

次に、被害者にそのサイトを訪問するよう誘導します (たとえば、「evil.com」へのリンクを含む電子メールを被害者に送信します)。ユーザーが攻撃者の Web サイトにアクセスし、「example.com」へのリンクをたどってログインすると、攻撃者は同じリンクをたどり、現在ログインしているセッションをハイジャックする可能性があります (ID が一致するため)。たとえば、Facebook の面白いビデオへのリンクである可能性がありますが、単なるログイン ページではなく、URL にセッション ID が含まれます。

ただし、ログイン プロセスの一部として session_regenerate_id() が呼び出された場合 (ユーザー名とパスワードが確認された直後)、セッション ID は新しくなり、攻撃者はこの方法を使用してセッションをハイジャックできなくなります。

これは、URL のセッション ID に限定された脆弱性ではありません。Web サイトの残りの部分が HTTP であり、ログイン後にセッションが HTTPS に移行された場合、セッション ID を再生成することも賢明です。これは、トラフィックが HTTP 上にあったときに既存のセッション ID が傍受された可能性があるためです。

于 2013-11-14T13:42:35.310 に答える