Cookie Tossing

Reading time: 8 minutes

説明

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

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

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

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

クッキーの順序

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

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

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

保護バイパス

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

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

Cookie Jar Overflow

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

クッキーボム

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

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