8.1 KiB
Cookie Tossing
ゼロからヒーローまでAWSハッキングを学ぶ htARTE（HackTricks AWS Red Team Expert）！
HackTricksをサポートする他の方法：
- HackTricksで企業を宣伝したいまたはHackTricksをPDFでダウンロードしたい場合は、サブスクリプションプランをチェックしてください！
- 公式PEASS＆HackTricksグッズを入手する
- The PEASS Familyを発見し、独占的なNFTコレクションを見る
- 💬 Discordグループに参加するか、telegramグループに参加するか、Twitter 🐦でフォローする @carlospolopm。
- ハッキングテクニックを共有するために、 HackTricksとHackTricks CloudのGitHubリポジトリにPRを提出する
説明
攻撃者が企業のサブドメインまたはドメインを制御できるか、サブドメインでXSSを見つけることができれば、この攻撃を実行できます。
Cookieハッキングセクションで示されているように、cookieがドメインに設定されると（それを指定して）、そのドメインとサブドメインで使用されます。
{% hint style="danger" %}
したがって、攻撃者はドメインとサブドメインに特定のcookieを設定できるようになります。 document.cookie="session=1234; Path=/app/login; domain=.example.com"のようなことを行います。
{% endhint %}
これは危険であり、攻撃者は次のようなことができるかもしれません：
- 被害者の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が設定される前に設定するか、より具体的なパスで設定することが良いでしょう。
{% hint style="warning" %} さらに、より具体的なパスにcookieを設定できる能力は非常に興味深いものです。これにより、悪意のあるcookieが送信される特定のパスを除いて、被害者が自分のcookieで作業できるようになります。 {% endhint %}
保護のバイパス
この攻撃に対する可能な保護策は、ウェブサーバーが同じ名前の2つの異なる値を持つcookieを受け入れないようにすることです。
攻撃者が被害者にすでにcookieが与えられた後にcookieを設定しているシナリオをバイパスするために、攻撃者はcookieオーバーフローを引き起こし、その後、正規のcookieが削除されたら、悪意のあるcookieを設定できます。
{% content-ref url="cookie-jar-overflow.md" %} cookie-jar-overflow.md {% endcontent-ref %}
別の有用なバイパスは、cookieの名前をURLエンコードすることです。一部の保護は、リクエスト内の同じ名前の2つのcookieをチェックし、その後、サーバーがcookieの名前をデコードするため、これが重要です。
Cookie Bomb
Cookie Tossing攻撃は、Cookie Bomb攻撃を実行するためにも使用できます：
{% content-ref url="cookie-bomb.md" %} cookie-bomb.md {% endcontent-ref %}
防御
Cookie名に接頭辞__Hostを使用する
- Cookie名にこの接頭辞がある場合、それはセキュアにマークされ、セキュアなオリジンから送信され、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
ゼロからヒーローまでAWSハッキングを学ぶ htARTE（HackTricks AWS Red Team Expert）！
HackTricksをサポートする他の方法：
- HackTricksで企業を宣伝したいまたはHackTricksをPDFでダウンロードしたい場合は、サブスクリプションプランをチェックしてください！
- 公式PEASS＆HackTricksグッズを入手する
- The PEASS Familyを発見し、独占的なNFTコレクションを見る
- 💬 Discordグループに参加するか、telegramグループに参加するか、Twitter 🐦でフォローする @carlospolopm。
- ハッキングテクニックを共有するために、 HackTricksとHackTricks CloudのGitHubリポジトリにPRを提出する