Cookies Hacking
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Cookiesには、ユーザーのブラウザでの動作を制御するいくつかの属性があります。これらの属性についての概要は以下の通りです。
クッキーの有効期限はExpires属性によって決まります。対照的に、Max-age属性はクッキーが削除されるまでの時間を秒単位で定義します。Max-ageを選択することをお勧めします。これはより現代的な慣行を反映しています。
クッキーを受け取るホストはDomain属性によって指定されます。デフォルトでは、これはクッキーを発行したホストに設定され、サブドメインは含まれません。しかし、Domain属性が明示的に設定されると、サブドメインも含まれます。これにより、サブドメイン間でのクッキー共有が必要なシナリオで役立つ、Domain属性の指定が制限の少ないオプションとなります。たとえば、Domain=mozilla.orgを設定すると、developer.mozilla.orgのようなサブドメインでクッキーにアクセスできます。
Cookieヘッダーが送信されるために要求されたURLに存在しなければならない特定のURLパスは、Path属性によって示されます。この属性は/文字をディレクトリセパレーターとして考慮し、サブディレクトリ内での一致も可能にします。
同じ名前のクッキーが2つある場合、送信されるクッキーは以下に基づいて選択されます：
要求されたURL内で最も長いパスに一致するクッキー。
パスが同じ場合は、最も最近設定されたクッキー。
SameSite属性は、クッキーがサードパーティのドメインからのリクエストで送信されるかどうかを決定します。3つの設定があります：
Strict: サードパーティのリクエストでクッキーが送信されるのを制限します。
Lax: サードパーティのウェブサイトによって開始されたGETリクエストでクッキーが送信されることを許可します。
None: どのサードパーティのドメインからでもクッキーが送信されることを許可します。
クッキーを設定する際には、これらの属性を理解することで、さまざまなシナリオで期待通りに動作することを確保できます。
Request Type | Example Code | Cookies Sent When |
Link | <a href="..."></a> | NotSet*, Lax, None |
Prerender | <link rel="prerender" href=".."/> | NotSet*, Lax, None |
Form GET | <form method="GET" action="..."> | NotSet*, Lax, None |
Form POST | <form method="POST" action="..."> | NotSet*, None |
iframe | <iframe src="..."></iframe> | NotSet*, None |
AJAX | $.get("...") | NotSet*, None |
Image | <img src="..."> | NetSet*, None |
Table from Invicti and slightly modified. _SameSite_属性を持つクッキーは、CSRF攻撃を軽減します。ログインセッションが必要です。
*Chrome80（2019年2月）以降、SameSite属性のないクッキーのデフォルトの動作はLaxになります (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/). この変更を適用した後、ChromeではSameSiteポリシーのないクッキーは最初の2分間はNoneとして扱われ、その後はトップレベルのクロスサイトPOSTリクエストに対してLaxとして扱われます。
これはクライアントがクッキーにアクセスするのを防ぎます（例えばJavascript経由：document.cookie）。
ページがリクエストのレスポンスとしてクッキーを送信している場合（例えばPHPinfoページ）、XSSを悪用してこのページにリクエストを送り、レスポンスからクッキーを盗むことが可能です（例はこちらを参照）。
TRACE HTTPリクエストを使用することでバイパス可能です。サーバーからのレスポンスは送信されたクッキーを反映します。この技術はCross-Site Trackingと呼ばれます。
この技術は、モダンブラウザがJSからTRACEリクエストを送信することを許可しないことによって回避されます。ただし、IE6.0 SP2に対してTRACEの代わりに\r\nTRACEを送信するなど、特定のソフトウェアでのバイパスが見つかっています。
別の方法は、ブラウザのゼロデイ脆弱性を悪用することです。
クッキージャーオーバーフロー攻撃を実行することでHttpOnlyクッキーを上書きすることが可能です：
Cookie Smuggling攻撃を使用してこれらのクッキーを外部に持ち出すことが可能です。
リクエストは、HTTPSなどの安全なチャネルを介して送信される場合にのみ、HTTPリクエストでクッキーを送信します。
__Secure-で始まるクッキーは、HTTPSで保護されたページからsecureフラグとともに設定される必要があります。
__Host-で始まるクッキーには、いくつかの条件が満たされなければなりません：
secureフラグで設定されなければなりません。
HTTPSで保護されたページから発信されなければなりません。
ドメインを指定することは禁じられており、サブドメインへの送信を防ぎます。
これらのクッキーのパスは/に設定されなければなりません。
__Host-で始まるクッキーは、スーパードメインやサブドメインに送信されることは許可されていないことに注意することが重要です。この制限は、アプリケーションクッキーを隔離するのに役立ちます。したがって、すべてのアプリケーションクッキーに__Host-プレフィックスを使用することは、セキュリティと隔離を強化するための良いプラクティスと見なされます。
したがって、__Host-で始まるクッキーの保護の1つは、サブドメインからの上書きを防ぐことです。たとえば、Cookie Tossing attacksを防ぎます。トークでCookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper)では、パーサーを騙すことでサブドメインから__HOST-で始まるクッキーを設定することが可能であることが示されています。たとえば、最初や最後に=を追加することです：
また、PHPでは、クッキー名の最初に他の文字を追加することで、アンダースコア文字に置き換えられ、__HOST-クッキーを上書きすることが可能でした：
カスタムクッキーに機密データが含まれている場合は、それを確認してください（特にCTFをプレイしている場合）、脆弱性があるかもしれません。
クッキーに埋め込まれた機密データは常に精査されるべきです。Base64や類似の形式でエンコードされたクッキーは、しばしばデコード可能です。この脆弱性により、攻撃者はクッキーの内容を変更し、修正されたデータを再度クッキーにエンコードすることで他のユーザーを偽装することができます。
この攻撃は、ユーザーのクッキーを盗むことで、アプリケーション内のアカウントに不正にアクセスすることを含みます。盗まれたクッキーを使用することで、攻撃者は正当なユーザーを偽装できます。
このシナリオでは、攻撃者が被害者を特定のクッキーを使用してログインさせるように仕向けます。アプリケーションがログイン時に新しいクッキーを割り当てない場合、攻撃者は元のクッキーを持っているため、被害者を偽装できます。この技術は、被害者が攻撃者が提供したクッキーでログインすることに依存しています。
サブドメインにXSSを見つけた場合やサブドメインを制御している場合は、次をお読みください：
Cookie Tossingここでは、攻撃者が被害者に攻撃者のセッションクッキーを使用させるように仕向けます。被害者は自分のアカウントにログインしていると信じて、攻撃者のアカウントのコンテキストで意図せずにアクションを実行します。
サブドメインにXSSを見つけた場合やサブドメインを制御している場合は、次をお読みください：
Cookie Tossing前のリンクをクリックして、JWTの可能な欠陥を説明するページにアクセスしてください。
クッキーで使用されるJSON Web Tokens (JWT)も脆弱性を示す可能性があります。潜在的な欠陥とそれを悪用する方法についての詳細情報を得るには、JWTをハッキングするためのリンクされた文書にアクセスすることをお勧めします。
この攻撃は、ログイン中のユーザーに対して、現在認証されているWebアプリケーションで不要なアクションを実行させるものです。攻撃者は、脆弱なサイトへのすべてのリクエストに自動的に送信されるクッキーを悪用できます。
（詳細は元の研究を参照してください）ブラウザは名前のないクッキーの作成を許可しており、JavaScriptを通じて次のように示すことができます：
送信されたクッキー ヘッダーの結果は a=v1; test value; b=v2; です。興味深いことに、これは空の名前のクッキーが設定されている場合にクッキーを操作することを可能にし、空のクッキーを特定の値に設定することで他のクッキーを制御する可能性があります。
これにより、ブラウザはすべてのウェブサーバーによって a という名前のクッキーと b という値を持つクッキーとして解釈されるクッキー ヘッダーを送信します。
Chrome では、Unicode サロゲート コードポイントが設定されたクッキーの一部である場合、document.cookie が破損し、その後空の文字列を返します:
この結果、document.cookie は空の文字列を出力し、永続的な破損を示します。
(詳細は元の研究を参照) Java（Jetty、TomCat、Undertow）やPython（Zope、cherrypy、web.py、aiohttp、bottle、webob）を含むいくつかのウェブサーバーは、古いRFC2965サポートのためにクッキー文字列を誤って処理します。彼らは、セミコロンを含んでいても、ダブルクオートされたクッキー値を単一の値として読み取ります。これは通常、キーと値のペアを区切るべきです。
(Check further details in theoriginal research) サーバーによるクッキーの不適切な解析、特に Undertow、Zope、および Python の http.cookie.SimpleCookie と http.cookie.BaseCookie を使用しているものは、クッキーインジェクション攻撃の機会を生み出します。これらのサーバーは新しいクッキーの開始を適切に区切ることができず、攻撃者がクッキーを偽装することを可能にします：
Undertow は、セミコロンなしで引用された値の直後に新しいクッキーを期待します。
Zope は、次のクッキーの解析を開始するためにカンマを探します。
Python のクッキークラスは、スペース文字で解析を開始します。
この脆弱性は、クッキーに基づく CSRF 保護に依存するウェブアプリケーションにおいて特に危険です。攻撃者が偽装された CSRF トークンクッキーを注入できるため、セキュリティ対策を回避する可能性があります。この問題は、Python の重複クッキー名の処理によって悪化し、最後の出現が以前のものを上書きします。また、不安全なコンテキストにおける __Secure- および __Host- クッキーに対する懸念を引き起こし、クッキーが偽装に対して脆弱なバックエンドサーバーに渡されると、認可のバイパスを引き起こす可能性があります。
クッキーは、ログインするたびに同じです。
ログアウトして、同じクッキーを使用してみてください。
2つのデバイス（またはブラウザ）で同じアカウントに同じクッキーを使用してログインしてみてください。
クッキーに情報が含まれているか確認し、変更を試みてください。
ほぼ同じユーザー名で複数のアカウントを作成し、類似点が見えるか確認してください。
"remember me" オプションが存在する場合は、その動作を確認してください。存在し、脆弱である可能性がある場合は、他のクッキーなしでremember meのクッキーを常に使用してください。
パスワードを変更しても前のクッキーが機能するか確認してください。
クッキーがログイン時に同じ（またはほぼ同じ）である場合、これはおそらくクッキーがアカウントのいくつかのフィールド（おそらくユーザー名）に関連していることを意味します。次に、あなたは：
非常に似たユーザー名でたくさんのアカウントを作成し、アルゴリズムがどのように機能しているかを推測してみてください。
ユーザー名をブルートフォースしてみてください。クッキーがあなたのユーザー名の認証方法としてのみ保存されている場合、ユーザー名 "Bmin" でアカウントを作成し、クッキーのすべてのビットをブルートフォースすることができます。なぜなら、あなたが試すクッキーの1つは "admin" に属するものだからです。
Padding Oracleを試してください（クッキーの内容を復号化できます）。padbusterを使用してください。
Padding Oracle - Padbuster examples
Padbusterは複数回の試行を行い、どの条件がエラー条件（無効なもの）であるかを尋ねます。
その後、クッキーの復号を開始します（数分かかる場合があります）。
攻撃が成功した場合、任意の文字列を暗号化してみることができます。例えば、encrypt user=administratorを暗号化したい場合。
この実行により、文字列 user=administrator が内部に含まれた正しく暗号化され、エンコードされたクッキーが得られます。
CBC-MAC
クッキーには何らかの値が含まれ、CBCを使用して署名される可能性があります。その場合、値の整合性は、同じ値を使用してCBCで作成された署名です。IVとしてヌルベクターを使用することが推奨されるため、このタイプの整合性チェックは脆弱である可能性があります。
攻撃
ユーザー名 administ の署名を取得 = t
ユーザー名 rator\x00\x00\x00 XOR t の署名を取得 = t'
クッキーに値 administrator+t' を設定 (t' は (rator\x00\x00\x00 XOR t) XOR t の有効な署名になります = rator\x00\x00\x00)
ECB
クッキーがECBを使用して暗号化されている場合、脆弱である可能性があります。 ログインすると、受け取るクッキーは常に同じでなければなりません。
検出と攻撃方法:
ほぼ同じデータ（ユーザー名、パスワード、メールなど）を持つ2つのユーザーを作成し、与えられたクッキー内のパターンを発見しようとします。
例えば "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" というユーザーを作成し、クッキーにパターンがあるか確認します（ECBは同じキーで各ブロックを暗号化するため、ユーザー名が暗号化されると同じ暗号化されたバイトが現れる可能性があります）。
使用されるブロックのサイズでパターンが存在するはずです。したがって、"a" の bunch がどのように暗号化されるかを知っていれば、ユーザー名を作成できます: "a"*(ブロックのサイズ)+"admin"。次に、クッキーから "a" のブロックの暗号化パターンを削除することができます。そして、ユーザー名 "admin" のクッキーを得ることができます。
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する: HackTricks Training GCP Red Team Expert (GRTE)
