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