Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 12:43:23 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/hacking-with-cookies/cookie-tossing.md

7.9 KiB
Raw Blame History

Cookie Tossing

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

説明

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

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

{% hint style="danger" %} したがって、攻撃者は特定のクッキーをドメインとサブドメインに設定できるようになり、次のようなことを行います document.cookie="session=1234; Path=/app/login; domain=.example.com" {% endhint %}

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

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

クッキーの順序

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

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

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

{% hint style="warning" %} さらに、より特定のパスにクッキーを設定する能力は非常に興味深いです。なぜなら、被害者がそのクッキーで作業することができるのは、悪意のあるクッキーが設定された特定のパスを除いて、前に送信されるからです。 {% endhint %}

保護バイパス

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

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

{% content-ref url="cookie-jar-overflow.md" %} cookie-jar-overflow.md {% endcontent-ref %}

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

クッキーボム

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

{% content-ref url="cookie-bomb.md" %} cookie-bomb.md {% endcontent-ref %}

防御

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

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

参考文献

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}