3

私は、誰かがセッション Cookie を盗み、それを使用してシステムにアクセスするセッション ハイジャックを防ぐ方法を検討してきました。

http://codebutler.com/firesheepなどのプログラムを使用すると、オープン ワイヤレス ネットワーク上のセッションを簡単に傍受できます。また、セッションを取得する他の方法には、クロスサイト スクリプティング攻撃や、被害者のコンピューターからセッションを物理的に持ち上げることが含まれます。

SSL を使用してすべてのセッション Cookie/サーバー通信を保護することは、Firesheep スニフを防ぐために重要です。Cookie に HTTPOnly を設定すると、JavaScript が XSS 攻撃でセッション Cookie を読み取ることができなくなりますが、AJAX ベースの攻撃に対しては依然として脆弱です。

もう 1 つのレイヤーは、リクエストごとに更新されるセッション cookie にセキュリティ トークンまたは nonce を含めることです。トークンをサーバー側のデータストアと Cookie に保存し、リクエストごとに、Cookie のトークンがデータストアのトークンと一致するかどうかを比較します。

トークンが一致しない場合は、誰かがセッションを盗んで使用しようとしている可能性があるため、リクエストを無視するか、セッションを無効にしてユーザーに再認証を要求することができます。ただし、トークンの不一致は、接続が遅い/不安定な場合にも発生する可能性があります。

たとえば、サーバーが実際のユーザーからリクエストを受信し、サーバー データストア内のセッション トークンを更新し、更新されたトークンを含むセッション Cookie でユーザーに応答する場合があります。ただし、接続が遅い/不安定なため、ユーザーは応答を受信しないため、新しいセッショントークンがサーバーに保存されている間、ユーザーは古いセッショントークンを保持しています。ユーザーがリクエストを再試行すると、トークンが一致しなくなります。

この問題を軽減する1つの方法は、サーバーが最後のいくつかのトークンの履歴を保持し、それらが一致するかどうかを確認することですが、保持するトークンの数の状況になり、接続がどれほど不安定であるかによって異なりますユーザーがどれだけクリックに満足しているかに関係なく、接続が戻ってユーザーのセッションがブラウザによって更新される前に、サーバーが履歴を循環する可能性があります。

トークンの履歴を保持する代わりに、各セッションにタイムスタンプを付けて、タイムスタンプが指定された短い範囲 (たとえば 30 秒) 内にあるかどうかを確認します。ユーザーのセッション Cookie タイムスタンプが、サーバーに保存されているセッション タイムスタンプから 30 秒以内の場合、そのセッションは認証済みと見なされます。

疑似コードの例

def authenticate_request():

    if (stored_session.timestamp - session.timestamp > 30 seconds):
        return False
    return True

これにより、トークンの履歴を保持する必要がなくなります (タイムスタンプがトークンになります) が、攻撃者はセッションが盗まれた後、30 秒間ハイジャックする機会があります。これは事実ですが、トークン履歴の代替手段は、攻撃者により長い機会を与える可能性があるため、それほど優れているわけではありません.

IP アドレスと User-Agent の変更をチェックする他の方法にも問題があります。ユーザー エージェントは簡単にスプーフィングされます。攻撃者がユーザーのセッションを取得できた場合、同じ XSS コードまたはその他の手段を使用して、ユーザー エージェントを簡単に特定できます。

ユーザーがモバイル デバイスを使用している場合、IP アドレスが頻繁に変更される可能性があるため、多くの誤検知が発生する可能性があります。さらに、攻撃者は同じ会社のファイアウォールの背後にいる可能性があるため、ユーザーと攻撃者の IP は外部 Web サーバーに対して同じになります。

タイムスタンプトークンを使用するのは正しいアプローチですか、それともより良い方法がありますか? 30 秒のバッファーは適切ですか? 私が見逃しているエッジケースは何ですか?

4

1 に答える 1

2

タイムスタンプがどのように機能するかわかりません。ユーザーは、サーバーに別のリクエストを送信する前に、ページに30秒以上費やさないようにする必要があります。「投稿」を押す前に、このページを読んでこの応答を入力するのに30秒以上費やしたと確信しています。

回線を介して送信するデータが傍受されて複製される可能性があるという固有の問題があるように思われます。ハッカーが暗号化された値を傍受してその暗号化された値を送信する可能性があるため、パスワードを暗号化しても問題は解決しません。彼は、暗号化されていない値が何であるかを必ずしも気にしません。

送信するトークンについても同じことが言えます。ハッカーはトークンを傍受して複製する可能性があります。

問題を解決するように思われる唯一のアイデアは、公開鍵と秘密鍵を使用するチャレンジアンドレスポンスシステムです。Aはランダムな文字列を作成し、Bの公開鍵を使用して暗号化し、Bに送信します。Bはそれを復号化します。彼の秘密鍵を使用して文字列を作成し、復号化された値をアプリケーションデータとともに送り返します。次に、Aは、復号化された値が元の値と一致することを検証します。検証されない場合、彼は関連するデータを拒否します。

ハッカーは、Bの秘密鍵を知らない場合、Aからのメッセージを傍受して、応答をスプーフィングすることはできません。ランダムな文字列は毎回異なるため、ハッカーはBからの以前に傍受された応答を使用できません。

于 2011-06-16T21:16:36.860 に答える