Cookie Tossing

Reading time: 8 minutes

説明

攻撃者がサブドメインまたは企業のドメインを制御するか、サブドメインにXSSを見つけることができれば、この攻撃を実行できるようになります。

Cookies Hackingセクションで示されたように、クッキーがドメインに設定されると（指定されている場合）、そのドメインとサブドメインで使用されます。

これは危険であり、攻撃者は次のことができるかもしれません：

• 被害者のクッキーを攻撃者のアカウントに固定することができるため、ユーザーが気づかない場合、攻撃者のアカウントでアクションを実行します。攻撃者は興味深い情報を取得できるかもしれません（プラットフォームでのユーザーの検索履歴を確認する、被害者がアカウントにクレジットカードを設定する...）。
• この例はこちらにあります、攻撃者が被害者がgitリポジトリへのアクセスを認証するために使用する特定のセクションに自分のクッキーを設定したため、攻撃者のアカウントからアクセスされます。
• クッキーがログイン後に変更されない場合、攻撃者は単にクッキーを固定（セッション固定）し、被害者がログインするのを待ってからそのクッキーを使用して被害者としてログインします。
• 時には、セッションクッキーが変更されても、攻撃者は以前のものを使用し、新しいものも受け取ります。
• クッキーが初期値を設定している場合（flaskのように、クッキーがセッションのCSRFトークンを**設定することができ、この値は被害者がログインした後も保持される）、攻撃者はこの既知の値を設定し、その後悪用することができます（そのシナリオでは、攻撃者はユーザーにCSRFリクエストを実行させることができます）。
• 値を設定するのと同様に、攻撃者はサーバーによって生成された認証されていないクッキーを取得し、そこからCSRFトークンを取得して使用することもできます。

クッキーの順序

ブラウザが同じ名前の2つのクッキーを受け取ると、同じスコープ（ドメイン、サブドメイン、パス）に部分的に影響を与える場合、ブラウザはリクエストに対して両方のクッキーの値を送信します。

どちらが最も特定のパスを持っているか、またはどちらが古いものであるかに応じて、ブラウザは最初にクッキーの値を設定し、次に他のクッキーの値を設定します。例：Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;

ほとんどのウェブサイトは最初の値のみを使用します。したがって、攻撃者がクッキーを設定したい場合は、別のクッキーが設定される前に設定するか、より特定のパスで設定する方が良いです。

保護バイパス

この攻撃に対する可能な保護は、ウェブサーバーが同じ名前の2つのクッキーを異なる値で受け入れないことです。

攻撃者が被害者にクッキーがすでに与えられた後にクッキーを設定するシナリオを回避するために、攻撃者はクッキーオーバーフローを引き起こし、その後、正当なクッキーが削除されたら、悪意のあるクッキーを設定することができます。

Cookie Jar Overflow

別の有用なバイパスは、クッキーの名前をURLエンコードすることです。いくつかの保護は、リクエスト内の同じ名前の2つのクッキーをチェックし、その後サーバーはクッキーの名前をデコードします。

クッキーボム

Cookie Tossing攻撃は、クッキーボム攻撃を実行するためにも使用される可能性があります：

Cookie Bomb

防御

クッキー名にプレフィックス__Hostを使用する

• クッキー名にこのプレフィックスがある場合、Secureとしてマークされ、セキュアなオリジンから送信され、Domain属性を含まず、Path属性が/に設定されている場合にのみSet-Cookieディレクティブで受け入れられます。
• これにより、サブドメインがクッキーを頂点ドメインに強制することを防ぎます。これらのクッキーは「ドメインロック」されたものと見なされる可能性があります。

参考文献

• @blueminimal
• https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers
• https://github.blog/2013-04-09-yummy-cookies-across-domains/
• Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities