サブドメイン間のCookie攻撃からの保護
私はクロスサブドメインのCookie攻撃について読んでいます ここ 。
それがどのように動作するかの簡単な概要（ウィキペディアから）：
- ウェブサイトwww.example.comがサブドメインを信頼できない第三者に配布している
- そのようなパーティーの1つであるMalloryがevil.example.comを制御し、アリスを自分のサイトに誘い込みます。
- Evil.example.comにアクセスすると、Aliceのブラウザにドメイン.example.comのセッションCookieが設定されます
- Aliceがwww.example.comにアクセスすると、Cookieの仕様に従って、このCookieがリクエストとともに送信され、Aliceは、MalloryのCookieによって指定されたセッションを取得します。
- アリスがログオンすると、マロリーは自分のアカウントを使用できます。
お客様が独自のサブドメインを持つWebアプリを構築しています：subdomain.ourapp.com。
各顧客は、JavaScriptを含むことができるテンプレートファイルをアップロードできます（クライアント側の対話用）。
JavaScriptはCookieの読み取り/書き込みに使用できるため、上記のセッション固定攻撃をどのように防ぐことができますか？ CookieにはセッションIDのみを保存していることに注意してください。
Squarespace.comのようなサイトでは、ユーザーが自分のJavaScriptを自分のサブドメインのページに挿入することもできます。アップロードされたテンプレートファイルでCookieを設定/読み取るJavaScriptステートメントをフィルターで除外するのはほとんど不可能であるため、この攻撃方法を緩和するにはどうすればよいですか？
特定のシナリオは簡単に防ぐことができます：ログイン時に新しいセッションIDを作成します。
Sessionidがurl-parameterの場合、問題はドメイン全体に存在することに注意してください。
ただし、新しいsesionidを生成しても、他の種類の攻撃を防ぐには不十分です。Aliceがログインして、Malloryのサブドメインにアクセスすると、Cookieは送信されますか？
すべての信頼できるアクティビティに完全に異なるドメインを使用することは一般的な方法です。たとえば、Googleは信頼できるアクティビティにはgoogle.comを使用し、信頼できないサイトには* .googleusercontent.comを使用しています。
最も安全な答えは、まったく異なるドメインを使用することです。
同じドメインのサブドメインを使用する場合は、まず、起こり得る攻撃の詳細について学びます。これについては、このサイトですでにたくさん書かれています。例： 関連するDNSドメイン（* .example.com）のコンピューター間でどのようなCookie攻撃が可能ですか？ 、 サブドメインで安全でないwebappを防止すると、メインwebappのセキュリティが侵害されます 、- ユーザー固有のサブドメイン：JavaScriptセキュリティ 、 Webアプリで顧客ごとにサブドメインを使用することでセキュリティが向上しますか？ への私の答え。
同じドメインのサブドメインを使用している場合、自分自身を保護するために実行できるいくつかの手順を次に示します。すべての状態をサーバー側に保存します（Cookieを使用してクライアントに状態を保存しないでください。代わりに、使用する唯一のCookieはセッションでなければなりません。 ID）;ログインおよびログアウト時に新しいセッションIDを作成します。 Cookieのスコープがサブドメインであることを確認します（たとえば、スコープは.ourapp.comではなくfoo.ourapp.comにする必要があります）。サーバーサイドで、名前の付いた複数のCookieを受信していないことを確認してください。セッションの固定から身を守ってください。 CORSを使用する場合は、クロスドメインポリシーに十分注意して、クロスサブドメインのリクエストを許可しないようにしてください。
パブリックサフィックス には、すべてのベンダー（Chrome/Firefox/IE/Safari/Opera）が他のサブドメインから（他の機能とともに）Cookieを盗むこの問題を回避するために使用するドメインのリストがあります。リストは毎日更新され、 Githubで管理 です。
この情報は Herokuのブログ から入手しました。
Googleのgoogleusercontent.comドメインがherokuapp.com、herokussl.comドメインとともにリストに含まれていることを確認しました。
私はちょうど考えを持ちました。 暗号化されたトークンパターン からアイデアを借りることができます：Cookie値を暗号化します！
Cookieがサーバーによってのみアクセスされる場合は、安価な対称暗号化を使用できます。それ以外の場合は、より高価な公開鍵暗号化を使用します。
これにより、悪意のあるサブドメインがCookieを削除したことを検出したり、偽のCookieへの書き込みを検出したりできます。
サーバー上のセッションデータに正確なサブドメインを格納することで、この問題を解決することができました。そして、Cookieドメイン設定で正確なサブドメインを送信します。
ユーザーがdom1.website.comに初めてアクセスした場合は、それをセッションに保存し、今後のすべてのリクエストで一致することを確認します。それ以外の場合は、サーバーのセッションをリセットします。
したがって、ブラウザーをだまして管理し、dom2.website.comコードに同じCookieを送信して管理しているユーザーが、セッションに格納されているドメイン名の値が、送信されたドメインと一致しないことを確認します。サーバーのセッションをリセットします。
唯一の副作用は、dom1.website.comのセッションもクリアされることです。