問題タブ [session-hijacking]

現在、内部ネットワークでプロキシを使用している製品のユーザーに問題が発生しています。

システム管理者によると、プロキシはポート 80 と 443 に対して開いており、Cookie などでは何もせず、一部のサイトをブロックするだけです。

問題: ユーザー X がアプリケーションにログインすると、以前はアプリケーションを使用していなかった (ただし同じプロキシの背後にある) ユーザー Y もコンピューターにログインしてしまう?! これは可能ではありません (django のデフォルトの認証アプリが使用されます)?

Apache、Nginx、Django 1.0、および Postgresql を使用しています。また、runserver で実行すると機能しますが、nginx では機能しないことに注意してください。

これは、プロキシを使用するこのユーザーでのみ発生し、他のネットワークでは機能します。

誰もこれを以前に経験しましたか？もしそうなら、どのように解決しましたか？

前もって感謝します！

ステファン

私は最近、ここでASP.NET セッションをより安全にすることに関する記事を読みましたが、最初は本当に便利に思えました。

以前は、ユーザーの IP アドレスをセッションに保存し、その後のすべてのリクエストで、リクエスト元の IP が保存されている IP と同じであることを確認していました。

この記事のコードは、ユーザーの IP を含むハッシュ化されたメッセージ認証コードをセッション Cookie の一部として保存することを除いて、IP アドレスをチェックすることによってセッションも保護します。リクエストごとにハッシュ化された MAC が 2 回作成されるため、処理が少し遅くなると思います。

私はすでに彼らのコードに潜在的な欠陥があることを確認できます.MACを生成するために使用されたキーを何らかの方法で取得した場合、独自のIPで有効なMACを生成できます.IPを偽造する必要さえありません.セッションが開始されました。

オーバーヘッドが大きくなるだけでなく、簡単な方法よりも攻撃を受けやすい単純な問題に対する非常に複雑な解決策のように思えます-要点を完全に見逃していない限り。

では、なぜこのアプローチは、私が使用していたより単純なアプローチよりも安全なのでしょうか?

余談ですが、著者は、一部のユーザーの IP は、プロキシの背後にある場合、リクエストごとに変更されるため、比較に IP アドレス全体を使用すべきではないと述べています。X_FORWARDED_FOR をチェックした場合、これはまだ当てはまりますか?

ありがとう！

Python の scapy を使用して、TCP 接続をハイジャックするスクリプトを作成しました。

いくつかの VM (サーバー - xp_sp3、クライアント - xp_sp1) 間の接続に対する攻撃をテストすると、クライアント ポートが見つかり、次にサーバーの SND.NEXT が見つかり、それを使用してクライアント SND.NEXT が見つかりました (それらすべてを Wireshark と比較しました)。そしてそれらは合法です）。

クライアントからサーバーにスプーフィングされたパケットを送信すると、クライアントの SND.NEXT を使用して、パケットがサーバーに到達するが、NetCat (宛先) には到達しないことがわかります。さらに、それを実際のクライアント パケットと比較すると、ほとんど同じように見えます (異なる mac、ttl、window-size など)。

私が行ったことのほかに、サーバーに対してパケットが正当に見えるようにするために私がしなければならないことは他にありますか?

セッションハイジャックを防ぐために、次の 3 つの関数を作成しました。彼らが働きます。スクリプトの冒頭で set_auth_token を呼び出します。次に、html フォームで get_auth_token を呼び出します。フォームが投稿された後、check_auth_token を呼び出します。ただし、ユーザーがフォームに入力した後、間違って入力した後、F5/Refresh を押す傾向がある場合があります。これにより、ページが「死にます」。フォームが入力される前には発生しません。

これらを改善して、ユーザーが更新を押すたびに終了しないようにするにはどうすればよいですか?

get_auth_token は常に set_auth_token が呼び出された後に呼び出されるため、認証トークンが見つからない場合は終了します。

ページを停止させる関数:

乾杯。

シナリオ：自分のサイトでセッションを開始すると、ユーザーに一度表示されるランドトークンを生成します。後で使用するために「保管」するとします。次に、タイムスタンプを使用してmd5（トークン）をSQLに挿入します。ユーザーがログインなどの他のページにアクセスする場合、検証プロセスの一環として、URLを介してトークンを渡す必要があります。トークンが存在するかどうかを確認し、おそらくこのトークンのユーザーIDを更新します。

それで。誰かがユーザーのPHPSESSIDCookieを盗んだとしても、トークンを知らないとこれらのページにアクセスできないため、ハッカーにとっては何の役にも立ちませんか？

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

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

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

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

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

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

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

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

疑似コードの例

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

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

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

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

IPv4 と IPv6 の両方で機能する、セッション ハイジャックに対する保護のための「緩い」IP チェックを行う最善の方法は何ですか? すべてのユーザーの IP アドレスと、ユーザーがそのアドレスから接続した回数を保存する配列を取得しました。

ここで、緩い IP チェックを行い、それを $_SERVER['REMOTE_ADDR'] と比較します。ユーザーが 1 つのアドレスからしか接続していない場合、セッション ID がハイジャックされたと想定する必要があります。同時に、ユーザーが IP アドレスを 82.34.24.* から 82.34.24.* に定期的に変更した場合、すべてが正常であると想定する必要がありますが、ユーザーが突然 82.34.33.0 または属していないアドレスから接続した場合セッションハイジャックを想定した場合、同じ IP グループアドレスまたは以前に使用されたことがない (たとえば、最後の 20 件のリクエスト)。

inet_pton/inet_nton を使用してこれを実装する最善の方法は何ですか?

PHP Session Fixation / Hijackingなどのスレッドや、Chris Shiflett などの一部の人々は$_SESSION['HTTP_USER_AGENT']、セッションの有効性を確認するためにユーザー エージェント ( ) を確認することを推奨しています。一部のリソースでは、次のようなことを推奨しています。

しかし、Chris Snyder氏は、「ブラウザー エージェントの世界は、ユーザーの世界に比べて非常に小さいため、各ユーザーが個別のユーザー エージェントを持つことは不可能です。さらに、ユーザー エージェントを偽装することは難しくありません」と述べています。したがって、セッションの有効性の証明としてこのメ​​トリックをチェックすることにはほとんど意味がありません」(第 7 章、103 ページ)。

矛盾するアドバイスに遭遇したとき、また、アドバイスの一部が古くなっている可能性がある場合 (上記の Shiflett/PHPSec の例のように、タイムスタンプが 2005 年 3 月 18 日金曜日のようです) に何をすべきかを知ることは非常に困難です。Snyder の (発行日: 2010 年 12 月 9 日) などの新しいアドバイスの方が優れているように見えますが、これは常にそうなのでしょうか? (たとえば、 の使用を推奨するのに多くの時間を費やしているにもかかわらずmysqli、Snyder は、Stack Overflow ユーザーがより良い選択であることに同意しているように見えることを完全に無視していますPDO。 .

したがって、私の質問には 2 つの部分があると思います。1 つは具体的な部分 (ユーザー エージェントを調査する必要がありますか?) であり、もう 1 つは一般的な部分 (PHP セキュリティの最新の考え方については、誰のアドバイスを信頼すべきでしょうか?) です。 Stack Overflow の人々を信頼してください!」-- あるいは、そもそも私が質問することはありません。なぜなら、最新の考え方をクラウドソーシングすることが、多くの場合、最良のアイデアであるからです。

HTTPSの質問を明確にするために、@Raduとのコメントでの有用な議論に続いて-

Snyder は次の 2 つのことを言っているようです。2.) HTTPS を使用できない状況では、ユーザー エージェントをチェックすることはまだあまり役に立ちません (これは、彼がおそらく古いアドバイスに同意しないポイントのようです)。

私はStackOverflowについて、セッションを適切に設定し、ハイジャックを防ぐ方法などについて調査していました。誰かが質問の1つに投稿した回答を見つけ、彼は次のコードを提供しました。

ユーザーがログインし、ユーザー名とパスワードが一致する場合

保護されたページについて、ユーザーがログインしているかどうかを確認します。

うまくいくようですが、私の質問は次のとおりです。これはどれほど安全か、これは良い方法ですか、それとも他の方法を試す必要がありますか？投稿には賛成票などがなかったので、それが良いかどうかはわかりません。

また、このセッションでユーザーに関する情報を取得する方法がわかりません..データベースに何かを保存する必要がありますか？

ありがとうございました！

私は Web 開発の初心者で、CSRF、XSS、およびセッション ハイジャックについて読みました。提案された解決策の 1 つは、単純に a を使用しnonceてリクエストの有効性をチェックすることです。セッションハイジャックを防ぐために、このスクリプトを PHP で作成しました。識別子、またはその組み合わせ (セッション ID とノンス) が要求ごとに変更されるという点で、セッション ID の再生成と精神的に似ていると思います。

これで十分ですか？SSL がセッション ハイジャックの良い解決策になることはわかっていますが、このアプローチについての洞察を期待しています。何か不足していますか？