別のサブドメインにCookieを安全に設定するにはどうすればよいですか？
マイクロサービスアプリがあります。 hub.example.comは認証を処理します。ユーザーがログインするときに、learn.example.comにCookieを設定する必要があります。これを設定する安全な方法は何ですか？私はいくつかのアプローチを知っています：
hubはexample.comにCookieを設定します。これは機能しますが、Cookieは他のサブドメインに伝播します。また、labのような危険なサブドメインがCookieを設定する可能性があります。learnはsetCookieコントローラーを提供します。ハブはlearn/setCookie?session=123へのリダイレクト（または別のメカニズム）を返します。これは機能しますが、どのドメイン（evil.comでも）がコントローラーを使用できます。setCookieコントローラーはOriginを検証し、hubのみを許可できます。これがユーザビリティとセキュリティにどのような影響を与えるのかはよくわかりません。hub連絡先learnサーバー間認証で直接連絡し、ワンタイムトークンを取得します。hubは、ユーザーのブラウザへのリダイレクトをlearn/setCookie?token=tokenに送信します（Fire Quackerに感謝）
これについての提案は最も高く評価されます。
オプション3が最良の選択です。
setCookieコントローラーはOriginヘッダーを検証し、hubのみを許可します
これは、
- オープンCookieセッターのセキュリティリスクを回避
- 署名のリプレイの問題がない（タイムスタンプを使用している場合でも）
- 1回限りのアプローチでサーバーの状態を維持する必要がない
- JavaScriptに依存しない
誰かがOriginヘッダーを偽装できるとコメントしました。ただし、オープンCookieセッターは、被害者のブラウザーで行われるクロスドメイン攻撃の懸念事項です。このシナリオでは、Originヘッダーを偽装することはできません。
ドメイン間で情報を渡すためにJSメッセージイベントをリッスンするlearn.example.comでホストされている単純なページをロードするiframeを使用します。信頼できます message.Origin 。これにより、JSでのフィルタリングが簡単になります。基本的にメッセージイベントをサブスクライブし、イベントが発生したときに送信者がリストに含まれているかどうかを確認し、含まれている場合はCookieを設定します。 3つの簡単なステップ。
これは実際には、SOP、CSP（オプション）、サンドボックス化など、他の多くの戦いでテストされた技術の上に乗っています。これにより、想像力が大幅に低下し、追加のサーバー処理、プロビジョニング、構成、パッチ適用、テストなどを必要としません。
上記で提案されているTOTPを使用したアプローチは適切です。
別の解決策も可能です。 TOTPの代わりにhubサイトはメッセージに署名してlearnにリダイレクトできます。 learnサイトは署名を検証し、必要なCookieを設定します。 JWTについて考えてみてください。
別の答えはJWTに言及しました。 JWTをサポートする機能がある場合は、URLのJWTを使用してリダイレクトできます。
hub.example.comは認証を処理し、JWTを作成しますhub.example.comはlearn.example.com/?jwt={token}にリダイレクトしますlearn.example.comはJWTを検証し、ユーザーにサービスを提供します
JWT内のjtiフィールドを使用することにより、リプレイアタックが防止されます。
ここ は、Zendeskによるこの実装の例です
これは、JWTのオーバーヘッドとそれに伴うすべてのセキュリティ上の懸念をもたらします。