https 接続でのセッション ハイジャックの問題

ご覧のページは、お客様の利便性のために一部機械翻訳されています。また、ドキュメントは頻繁に更新が加えられており、翻訳は未完成の部分が含まれることをご了承ください。最新情報は都度公開されておりますため、必ず英語版をご参照ください。翻訳に問題がある場合は、こちらまでご連絡ください。

問題

• ログインしたユーザーの sessionId を置き換えることにより、別のブラウザーからのユーザーのセッションが複製されます。
• 再現する手順
  • u1、u2などの2人のユーザーを作成します
  • u1 のロールを「パワー ユーザー」として、u2 を「ポータル コンテンツ レビュー担当者」として割り当てます。
  • Page1、Page2 のように 2 つのページを作成します。
  • Page1 の権限をクリックし、パワー ユーザー ロールの表示オプションを有効にし、ゲスト ユーザー ロールの表示権限を無効にします。
  • Page2 の権限をクリックして、Portal Content Reviewer ロールの表示オプションを有効にし、ゲスト ユーザー ロールの表示権限を無効にします。
    • 観察された動作: User1 は、ホームページと Page1 を表示できます。 User2 は、ホームページと Page2 を表示できます。
  • Burp Suite ツールを使用して、以下のようにリクエストをインターセプトします。
    • Chrome ブラウザーの場合:
      • u1 ユーザーとしてログインしています。
      • burp スイートの Intercept をオンにして、Chrome ブラウザを更新します。 SessionId の u1 がこのツールでキャプチャされます。
    • IE や Firefox ブラウザーなどの別のブラウザーで:
      • 「https://IP:8443/」のようにサインインせずに URL にヒットするインターセプトをオンにします。
      • リクエスト内の u1 のコピーしたセッション ID を置き換えて、[進む] をクリックします。
  • 観察された動作: u1 ログイン詳細を使用してログインしています。 Page1 が表示されるようになりました。

Environment

• ライフレイDXP 7.2 FP2
• ライフレイDXP 7.2 FP5

解決策

• 報告されたシナリオは、ポータルが単一のセッション ID (JSESSIONID) を使用してリクエストの背後にあるユーザーを識別することをよく示しています。 もちろん、これは、盗まれたセッション ID を使用して不正アクセスを取得できることを意味します。 一方、露出の問題やセキュリティの脆弱性はありません。
• 上記の場合、基本的に https リクエストのデバッグに適した環境をセットアップしてください。 その結果、暗号化されていないリクエストが表示され、 JSESSIONID Cookie を含め、その中のすべてにアクセスできます。 BurpSuite独自の証明書をブラウザーにインポートし、それを信頼できるものとして設定してWebサイトを識別しないと、https通信の傍受はできません。
• 実稼働環境 [HTTPS]化使用することにより (者攻撃) によって保護されます。まったく。

追加情報

• LPS-116195