プロキシとCookieの変更に関するセルフホストアプリのセッション問題解決ガイド
安全なアプローチは、直接リクエストとプロキシ経由リクエスト、レスポンスCookie、ブラウザストレージ、バックエンドのセッション状態をレイヤーごとに比較する作業を、単一のコマンドではなく、観測可能なゲートの連続として扱うことです。
リバースプロキシの背後でセルフホスト型Webアプリケーションを運用する場合、実際のリスクは、プロキシやCookieの変更後にユーザーがログアウトされたり、リダイレクトループに陥ったり、セッションを確立できなくなったりすることです。現在の識別情報と復旧ポイントを記録し、最も影響の少ない切り分けから始め、別の変数を変更する前に成功・失敗の結果を解釈し、ストレージが不安定になった場合や、復旧可能なコピーが唯一公開される状態になった場合は停止してください。以下のワークフローは、元の処理が成功するか、証拠がエスカレーション境界に達した場合にのみ終了します。
1つのセッション経路を再現し、証拠を保存する
ユーザー、ブラウザプロファイル、ホスト名、ログイン経路を1つずつ選びます。最初に失敗したリクエスト、ステータスの推移、リダイレクト先、値をマスキングしたレスポンスのSet-Cookieヘッダー、リクエストCookie、プロキシログ、アプリケーションログ、そして失敗に先立って行われた正確な設定変更を記録します。
最初からすべてのCookieを削除したり、アプリケーションシークレットをローテーションしたりしないでください。失敗しているプロファイルを比較用に残したまま、クリーンな対照としてプライベートブラウザプロファイルを使用します。バックエンドへ直接アクセスできるか確認してください。これにより、アプリケーションの認証と、プロキシに起因するURLおよびCookieの挙動を切り分けられます。
アプリケーションがログにトークンを出力している場合、プロキシが信頼されていないクライアントからの偽装転送ヘッダーを受け入れている場合、またはログインがTLSを迂回している場合は停止してください。機能面のトラブルシューティングを続ける前に、認証情報を保護し、セキュリティ境界を修正します。
スキーム、ホスト、転送元の信頼を確認する
外部URLと、アプリケーションが認識している情報（スキーム、ホスト、ポート、ベースパス、クライアントIP）を比較します。Host、X-Forwarded-Protoまたは標準化された転送ヘッダー、そしてアプリケーションの信頼済みプロキシ一覧を確認します。バックエンドがHTTPSリクエストをHTTPだと認識すると、Secure Cookieを拒否したり、HTTPSへの無限リダイレクトを生成したりすることがあります。
信頼できる1つのプロキシで転送ヘッダーを設定または置換し、アプリケーションが信頼するのはそのプロキシだけになるよう設定します。クライアントが提供した値を無条件に追加しないでください。プロキシヘッダーとアプリケーションのベースURLを同時に変更するのではなく、変更ごとにログインと1つの絶対リダイレクトをテストします。
ZimaSpaceの直接接続とプロキシ経由接続によるログイン診断ガイドでは、プロキシ再起動後に同じ直接接続とプロキシ経由接続の比較を行っています。Immichの例はより限定的ですが、証拠の確認手順は応用できます。まずバックエンドのセッションが機能することを証明し、その後に転送ヘッダー、ルーティング、ブラウザの状態を調べます。
Cookieのスコープとブラウザの判断を確認する
Cookie名、Domain、Path、Secure、HttpOnly、SameSite、有効期限を確認し、異なるパスやドメインに同じ名前の重複Cookieが存在しないか確認します。ブラウザの開発者ツールでは、Cookieが保存されたか、拒否されたか、次のリクエストから省略されたかを確認できます。サーバーログだけでは、その判断を把握できません。
OWASPのSameSite Cookieの挙動では、SameSiteの値がサイト間でのCookie送信をどのように制御するかを説明しています。認証がサイトをまたぐ場合や埋め込みフローを使用する場合、SameSite=NoneにはSecureも必要です。単純な同一サイトのアプリケーションでは、Cookieの適用範囲を不必要に広げると設計の安全性が低下します。
記録した後、対照プロファイルで影響を受けたCookieだけを削除し、ログインを再試行します。新しいCookieでは動作するのに保存していたプロファイルで失敗する場合は、スコープと有効期限を比較します。両方とも失敗する場合は、状態を繰り返し削除するのではなく、レスポンスヘッダーまたはバックエンドのセッションストレージに戻って確認します。
共有セッション状態を確認し、修正を検証する
複数のコンテナやレプリケーションされたアプリケーションでは、必要に応じて、すべてのインスタンスが同じセッション署名シークレット、時刻ソース、共有セッションバックエンドを使用していることを確認します。プロキシがインスタンス間でリクエストを振り分けると、あるインスタンスが別のインスタンスのCookieを検証できない場合に、ランダムなログアウトのように見えることがあります。
PortSwiggerのSameSiteのセキュリティ境界に関する説明はセキュリティに重点を置いていますが、SameSiteが汎用的なログイン修復スイッチではなく、ブラウザ側の境界であることを明確にしています。アプリケーションの実際のオリジンとリダイレクトフローに合わせつつ、CSRF対策を維持してください。
ログイン、ログアウト、アイドル時の有効期限、ブラウザの再起動、パスワード変更、想定された内部およびリモートのホスト名からのアクセスを検証します。古いCookieが安全に無効となり、新しいセッションが通常のルーティングを通じて維持され、転送設定やCookie属性が文書化された必要以上に緩和されていないことを確認してから、問題を解決済みとしてください。
おすすめ商品
サポートとヒント
もっと読む
名前を変更したデータセットと安定したファイルハンドルのためのNFS移行チェックリスト
ストレージの識別情報が変わるとファイルハンドルも変わる可能性があることを前提としてください。クライアントを停止し、エクスポートを意図的に切り替え、再マウントして、開いているファイルと新規ファイルを検証してください。
Windows、macOS、Linux向けSMBクライアントのトラブルシューティングガイド
各クライアントで同じサーバー、アカウント、共有、ファイル操作を使用し、検出、認証情報、ポリシー、ストレージの障害が混在しないようにします。
アプリ、データベース、バックアップ向けホームサーバーのシークレットローテーションチェックリスト
ローテーションは依存関係の移行として扱い、すべての利用箇所を洗い出し、可能な場合は認証情報を重複配置し、新しい値を検証してから、古い値を無効化し、復旧をテストします。
