Cookie Tossing
説明
攻撃者がサブドメインまたは企業のドメインを制御できる場合、またはサブドメインにXSSを見つけた場合、この攻撃を実行できるようになります。
クッキーのハッキングセクションで示されたように、クッキーがドメインに設定されると（指定されている場合）、そのドメインとサブドメインで使用されます。
したがって、攻撃者は特定のクッキーをドメインとサブドメインに設定できるようになり、次のようなことを行います document.cookie="session=1234; Path=/app/login; domain=.example.com"
これは危険です。攻撃者は次のことができるかもしれません：
被害者のクッキーを攻撃者のアカウントに固定するので、ユーザーが気づかない場合、攻撃者のアカウントでアクションを実行します。攻撃者は興味深い情報を取得できるかもしれません（プラットフォームでのユーザーの検索履歴を確認する、被害者がアカウントにクレジットカードを設定する...）。
クッキーがログイン後に変更されない場合、攻撃者は単にクッキーを固定（セッション固定）し、被害者がログインするのを待ってからそのクッキーを使用して被害者としてログインします。
時には、セッションクッキーが変更されても、攻撃者は以前のものを使用し、新しいものも受け取ります。
クッキーが初期値を設定している場合（フラスクのように、クッキーがセッションのCSRFトークンを設定し、この値が被害者がログインした後も維持される場合）、攻撃者はこの既知の値を設定し、それを悪用することができます（そのシナリオでは、攻撃者はユーザーにCSRFリクエストを実行させることができます。なぜなら、CSRFトークンを知っているからです）。
値を設定するのと同様に、攻撃者はサーバーによって生成された認証されていないクッキーを取得し、そこからCSRFトークンを取得して使用することもできます。
クッキーの順序
ブラウザが同じ名前の2つのクッキーを受け取ると、同じスコープ（ドメイン、サブドメイン、パス）に部分的に影響を与える場合、ブラウザはリクエストに対して両方のクッキーの値を送信します。
誰が最も特定のパスを持っているか、またはどちらが古いものであるかに応じて、ブラウザは最初にクッキーの値を設定し、次に他の値を設定します。例：Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;
ほとんどのウェブサイトは最初の値のみを使用します。したがって、攻撃者がクッキーを設定したい場合は、他のクッキーが設定される前に設定するか、より特定のパスで設定する方が良いです。
さらに、より特定のパスにクッキーを設定する能力は非常に興味深いです。なぜなら、被害者がそのクッキーで作業することができるのは、悪意のあるクッキーが設定された特定のパスを除いて、前に送信されるからです。
保護バイパス
この攻撃に対する可能な保護は、ウェブサーバーが同じ名前の2つのクッキーを異なる値で受け入れないことです。
攻撃者が被害者にクッキーがすでに与えられた後にクッキーを設定するシナリオを回避するために、攻撃者はクッキーオーバーフローを引き起こし、その後、正当なクッキーが削除されたら、悪意のあるクッキーを設定することができます。
Cookie Jar Overflow別の有用なバイパスは、クッキーの名前をURLエンコードすることです。なぜなら、一部の保護はリクエスト内の同じ名前の2つのクッキーをチェックし、その後サーバーがクッキーの名前をデコードするからです。
クッキーボム
クッキー投げ攻撃は、クッキーボム攻撃を実行するためにも使用される可能性があります：
Cookie Bomb防御
クッキー名にプレフィックス__Hostを使用する
__Hostを使用するクッキー名にこのプレフィックスがある場合、Secureとしてマークされ、セキュアなオリジンから送信され、Domain属性を含まず、Path属性が/に設定されている場合にのみSet-Cookieディレクティブで受け入れられます。
これにより、サブドメインがクッキーを頂点ドメインに強制することを防ぎます。これらのクッキーは「ドメインロック」と見なされる可能性があります。
参考文献
Last updated
