diff --git a/src/pentesting-web/domain-subdomain-takeover.md b/src/pentesting-web/domain-subdomain-takeover.md index a93cfc226..3e8bb1070 100644 --- a/src/pentesting-web/domain-subdomain-takeover.md +++ b/src/pentesting-web/domain-subdomain-takeover.md @@ -2,16 +2,15 @@ {{#include ../banners/hacktricks-training.md}} - ## ドメインテイクオーバー -もし、**スコープ内のサービスによって使用されている**ドメイン（domain.tld）を発見し、**会社**がその**所有権**を**失っている**場合、あなたはそれを**登録**し（十分に安価であれば）、会社に知らせることができます。このドメインが**GET**パラメータや**Referer**ヘッダーを介してセッションクッキーのような**機密情報**を受信している場合、これは確実に**脆弱性**です。 +もし、**スコープ内のサービスによって使用されている**ドメイン（domain.tld）を発見し、**会社**がその**所有権**を**失っている**場合、**登録**を試みることができます（十分に安価であれば）そして会社に知らせることができます。このドメインが**GET**パラメータや**Referer**ヘッダーを介してセッションクッキーのような**機密情報**を受信している場合、これは確実に**脆弱性**です。 ### サブドメインテイクオーバー 会社のサブドメインが**登録されていない名前の第三者サービス**を指している場合、あなたがこの**第三者サービス**で**アカウント**を**作成**し、使用中の**名前**を**登録**できれば、サブドメインテイクオーバーを実行できます。 -可能なテイクオーバーをチェックするための辞書を持ついくつかのツールがあります： +可能なテイクオーバーを確認するための辞書を持つツールがいくつかあります： - [https://github.com/EdOverflow/can-i-take-over-xyz](https://github.com/EdOverflow/can-i-take-over-xyz) - [https://github.com/blacklanternsecurity/bbot](https://github.com/blacklanternsecurity/bbot) @@ -29,27 +28,43 @@ ### DNSワイルドカードによるサブドメインテイクオーバー生成 -ドメインでDNSワイルドカードが使用されている場合、そのドメインの異なるアドレスが明示的に指定されていない任意の要求されたサブドメインは、**同じ情報に解決されます**。これはA IPアドレスやCNAMEなどです。 +ドメインでDNSワイルドカードが使用されている場合、そのドメインの異なるアドレスが明示的に指定されていないすべての要求されたサブドメインは**同じ情報に解決されます**。これはA IPアドレスやCNAMEなどです。 例えば、`*.testing.com`が`1.1.1.1`にワイルドカードされている場合、`not-existent.testing.com`は`1.1.1.1`を指します。 -しかし、IPアドレスを指すのではなく、システム管理者が**CNAMEを介して第三者サービス**に指す場合、例えばG**ithubのサブドメイン**（`sohomdatta1.github.io`）のように、攻撃者は**自分自身の第三者ページ**（この場合はGihub上）を**作成**し、`something.testing.com`がそこを指していると言うことができます。なぜなら、**CNAMEワイルドカード**により、攻撃者は**被害者のドメインに対して任意のサブドメインを生成し、自分のページに指すことができる**からです。 +しかし、IPアドレスを指す代わりに、システム管理者が**CNAMEを介して第三者サービス**に指す場合、例えばG**ithubのサブドメイン**（`sohomdatta1.github.io`）のように、攻撃者は**自分自身の第三者ページ**（この場合はGihub）を作成し、`something.testing.com`がそこを指していると言うことができます。なぜなら、**CNAMEワイルドカード**が攻撃者に**被害者のドメインに対して任意のサブドメインを生成することを許可するからです**。 -この脆弱性の例は、CTFのレポートで見つけることができます：[https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api) +この脆弱性の例はCTFのレポートで見つけることができます：[https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api) ## サブドメインテイクオーバーの悪用 -サブドメインテイクオーバーは、インターネット上の特定のドメインに対するDNSスプーフィングであり、攻撃者がドメインのAレコードを設定し、ブラウザが攻撃者のサーバーからのコンテンツを表示することを可能にします。この**透明性**は、ブラウザがフィッシングに対してドメインを脆弱にします。攻撃者はこの目的のために[_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting)や[_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger)を使用することがあります。特に脆弱なのは、フィッシングメールのURLが正当であるように見えるドメインであり、ドメインの固有の信頼性により、ユーザーを欺き、スパムフィルターを回避します。 +サブドメインテイクオーバーは、特定のドメインに対するDNSスプーフィングであり、攻撃者がドメインのAレコードを設定できるようにし、ブラウザが攻撃者のサーバーからのコンテンツを表示することを可能にします。この**透明性**はブラウザにおいてドメインをフィッシングに対して脆弱にします。攻撃者はこの目的のために[_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting)や[_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger)を使用することがあります。特に脆弱なのは、フィッシングメールのURLが正当であるように見えるドメインであり、ドメインの固有の信頼性によりユーザーを欺き、スパムフィルターを回避します。 詳細についてはこの[投稿を確認してください](https://0xpatrik.com/subdomain-takeover/) ### **SSL証明書** -SSL証明書は、攻撃者が[_Let's Encrypt_](https://letsencrypt.org/)のようなサービスを介して生成した場合、これらの偽のドメインの正当性を高め、フィッシング攻撃をより説得力のあるものにします。 +SSL証明書は、[_Let's Encrypt_](https://letsencrypt.org/)のようなサービスを介して攻撃者によって生成される場合、これらの偽のドメインの正当性を高め、フィッシング攻撃をより説得力のあるものにします。 ### **クッキーセキュリティとブラウザの透明性** -ブラウザの透明性は、[同一生成元ポリシー](https://en.wikipedia.org/wiki/Same-origin_policy)のようなポリシーによって管理されるクッキーセキュリティにも及びます。クッキーは、セッションを管理し、ログイントークンを保存するために使用されることが多く、サブドメインテイクオーバーを通じて悪用される可能性があります。攻撃者は、ユーザーを侵害されたサブドメインに誘導することで**セッションクッキーを収集**し、ユーザーデータとプライバシーを危険にさらすことができます。 +ブラウザの透明性は、[同一生成元ポリシー](https://en.wikipedia.org/wiki/Same-origin_policy)のようなポリシーによって管理されるクッキーセキュリティにも及びます。クッキーは、セッションを管理し、ログイントークンを保存するために使用されることが多く、サブドメインテイクオーバーを通じて悪用される可能性があります。攻撃者は**侵害されたサブドメインにユーザーを誘導することによってセッションクッキーを収集**し、ユーザーデータとプライバシーを危険にさらすことができます。 + +### CORSバイパス + +すべてのサブドメインがメインドメインまたは他のサブドメインからCORSリソースにアクセスできる可能性があります。これを攻撃者が悪用して**機密情報にアクセス**することができます。 + +### CSRF - Same-Siteクッキーのバイパス + +サブドメインが、クッキーの`Same-Site`属性によって防止されていたドメインまたは他のサブドメインにクッキーを送信することが許可されている可能性があります。ただし、適切に実装されている場合、anti-CSRFトークンはこの攻撃を防ぐことができます。 + +### OAuthトークンのリダイレクト + +侵害されたサブドメインがOAuthフローの`redirect_uri` URLで使用されることが許可されている可能性があります。これを攻撃者が悪用して**OAuthトークンを盗む**ことができます。 + +### CSPバイパス + +侵害されたサブドメイン（またはすべてのサブドメイン）が、例えばCSPの`script-src`で使用されることが許可されている可能性があります。これを攻撃者が悪用して**悪意のあるスクリプトを注入**し、潜在的なXSS脆弱性を悪用することができます。 ### **メールとサブドメインテイクオーバー** @@ -57,11 +72,11 @@ SSL証明書は、攻撃者が[_Let's Encrypt_](https://letsencrypt.org/)のよ ### **高次のリスク** -さらなるリスクには**NSレコードのテイクオーバー**が含まれます。攻撃者がドメインの1つのNSレコードを制御すると、彼らはトラフィックの一部を自分の制御下にあるサーバーに向けることができます。このリスクは、攻撃者がDNSレコードのTTL（生存時間）を高く設定する場合に増幅され、攻撃の持続時間を延ばします。 +さらなるリスクには**NSレコードのテイクオーバー**が含まれます。攻撃者がドメインの1つのNSレコードを制御すると、彼らはトラフィックの一部を自分の制御下にあるサーバーに向けることができます。このリスクは、攻撃者がDNSレコードのTTL（Time to Live）を高く設定することで増幅され、攻撃の持続時間が延長されます。 ### CNAMEレコードの脆弱性 -攻撃者は、もはや使用されていないか、廃止された外部サービスを指す未請求のCNAMEレコードを悪用する可能性があります。これにより、信頼されたドメインの下にページを作成し、フィッシングやマルウェアの配布をさらに促進することができます。 +攻撃者は、もはや使用されていないか、廃止された外部サービスを指す未請求のCNAMEレコードを悪用する可能性があります。これにより、彼らは信頼されたドメインの下にページを作成し、フィッシングやマルウェアの配布をさらに促進することができます。 ### **緩和戦略** @@ -69,13 +84,14 @@ SSL証明書は、攻撃者が[_Let's Encrypt_](https://letsencrypt.org/)のよ 1. **脆弱なDNSレコードの削除** - サブドメインがもはや必要ない場合に効果的です。 2. **ドメイン名の請求** - 関連するクラウドプロバイダーでリソースを登録するか、期限切れのドメインを再購入します。 -3. **脆弱性の定期的な監視** - [aquatone](https://github.com/michenriksen/aquatone)のようなツールは、脆弱なドメインを特定するのに役立ちます。組織はまた、DNSレコードの作成がリソースの作成の最終ステップであり、リソースの破棄の最初のステップであることを確認するために、インフラ管理プロセスを見直すべきです。 +3. **脆弱性の定期的な監視** - [aquatone](https://github.com/michenriksen/aquatone)のようなツールは、脆弱なドメインを特定するのに役立ちます。組織はまた、インフラ管理プロセスを見直し、DNSレコードの作成がリソース作成の最終ステップであり、リソース破棄の最初のステップであることを確認する必要があります。 -クラウドプロバイダーにとって、ドメイン所有権の確認はサブドメインテイクオーバーを防ぐために重要です。例えば、[GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/)のように、この問題を認識し、ドメイン検証メカニズムを実装しているプロバイダーもあります。 +クラウドプロバイダーにとって、ドメイン所有権の確認はサブドメインテイクオーバーを防ぐために重要です。例えば、[GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/)のように、この問題を認識し、ドメイン確認メカニズムを実装しているプロバイダーもあります。 ## 参考文献 - [https://0xpatrik.com/subdomain-takeover/](https://0xpatrik.com/subdomain-takeover/) - [https://www.stratussecurity.com/post/subdomain-takeover-guide](https://www.stratussecurity.com/post/subdomain-takeover-guide) +- [https://www.hackerone.com/blog/guide-subdomain-takeovers-20](https://www.hackerone.com/blog/guide-subdomain-takeovers-20) {{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/hacking-with-cookies/README.md b/src/pentesting-web/hacking-with-cookies/README.md index 4f9bf1427..a06430a22 100644 --- a/src/pentesting-web/hacking-with-cookies/README.md +++ b/src/pentesting-web/hacking-with-cookies/README.md @@ -1,147 +1,147 @@ -# クッキーのハッキング +# Cookies Hacking {{#include ../../banners/hacktricks-training.md}} -## クッキー属性 +## Cookie Attributes -クッキーには、ユーザーのブラウザでの動作を制御するいくつかの属性があります。これらの属性について、より受動的な声で説明します。 +Cookiesには、ユーザーのブラウザでの動作を制御するいくつかの属性があります。これらの属性について、より受動的な声で説明します。 -### Expires と Max-Age +### Expires and Max-Age -クッキーの有効期限は `Expires` 属性によって決まります。対照的に、`Max-age` 属性はクッキーが削除されるまでの時間（秒単位）を定義します。**より現代的な慣行を反映するために `Max-age` を選択してください。** +Cookieの有効期限は`Expires`属性によって決まります。対照的に、`Max-age`属性はCookieが削除されるまでの時間（秒単位）を定義します。**`Max-age`を選択することをお勧めします。これはより現代的な慣行を反映しています。** ### Domain -クッキーを受け取るホストは `Domain` 属性によって指定されます。デフォルトでは、これはクッキーを発行したホストに設定され、サブドメインは含まれません。しかし、`Domain` 属性が明示的に設定されると、サブドメインも含まれます。これにより、サブドメイン間でのクッキー共有が必要なシナリオで、`Domain` 属性の指定が制限の少ないオプションとなります。たとえば、`Domain=mozilla.org` を設定すると、`developer.mozilla.org` のようなサブドメインでクッキーにアクセスできます。 +Cookieを受け取るホストは`Domain`属性によって指定されます。デフォルトでは、これはCookieを発行したホストに設定され、サブドメインは含まれません。しかし、`Domain`属性が明示的に設定されると、サブドメインも含まれます。これにより、サブドメイン間でのCookie共有が必要なシナリオで、`Domain`属性の指定が制限の少ないオプションとなります。たとえば、`Domain=mozilla.org`を設定すると、`developer.mozilla.org`のようなサブドメインでもCookieにアクセスできます。 ### Path -`Cookie` ヘッダーが送信されるために要求された URL に存在しなければならない特定の URL パスは、`Path` 属性によって示されます。この属性は `/` 文字をディレクトリ区切りとして考慮し、サブディレクトリ内での一致も可能にします。 +`Cookie`ヘッダーが送信されるために要求されたURLに存在しなければならない特定のURLパスは、`Path`属性によって示されます。この属性は`/`文字をディレクトリセパレーターとして考慮し、サブディレクトリ内での一致も可能にします。 ### Ordering Rules -同じ名前のクッキーが2つある場合、送信されるクッキーは以下に基づいて選択されます： +同じ名前のCookieが2つある場合、送信されるCookieは以下に基づいて選択されます： -- 要求された URL で最も長いパスに一致するクッキー。 -- パスが同じ場合は、最も最近設定されたクッキー。 +- 要求されたURL内で最も長いパスに一致するCookie。 +- パスが同じ場合は、最も最近設定されたCookie。 ### SameSite -- `SameSite` 属性は、クッキーがサードパーティのドメインからのリクエストで送信されるかどうかを決定します。3つの設定があります： -- **Strict**: サードパーティのリクエストでクッキーが送信されるのを制限します。 -- **Lax**: サードパーティのウェブサイトによって開始された GET リクエストでクッキーが送信されることを許可します。 -- **None**: どのサードパーティのドメインからでもクッキーが送信されることを許可します。 +- `SameSite`属性は、Cookieがサードパーティのドメインからのリクエストで送信されるかどうかを決定します。3つの設定があります： +- **Strict**: サードパーティのリクエストでCookieが送信されるのを制限します。 +- **Lax**: サードパーティのウェブサイトによって開始されたGETリクエストでCookieが送信されることを許可します。 +- **None**: どのサードパーティのドメインからでもCookieが送信されることを許可します。 -クッキーを設定する際には、これらの属性を理解することで、さまざまなシナリオで期待通りに動作することを確保できます。 +Cookieを設定する際には、これらの属性を理解することで、さまざまなシナリオで期待通りに動作することを確保できます。 -| **リクエストタイプ** | **例コード** | **クッキーが送信されるとき** | +| **Request Type** | **Example Code** | **Cookies Sent When** | | ---------------- | ---------------------------------- | --------------------- | -| リンク | \\ | NotSet\*, Lax, None | -| プリレンダリング | \ | NotSet\*, Lax, None | -| フォーム GET | \
| NotSet\*, Lax, None | -| フォーム POST | \ | NotSet\*, None | +| Link | \\ | NotSet\*, Lax, None | +| Prerender | \ | NotSet\*, Lax, None | +| Form GET | \ | NotSet\*, Lax, None | +| Form POST | \ | NotSet\*, None | | iframe | \ | NotSet\*, None | | AJAX | $.get("...") | NotSet\*, None | -| 画像 | \ | NetSet\*, None | +| Image | \ | NetSet\*, None | -表は [Invicti](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/) からのもので、若干修正されています。\ -_**SameSite**_ 属性を持つクッキーは、**CSRF攻撃を軽減**します。 +Table from [Invicti](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/) and slightly modified.\ +_**SameSite**_属性を持つCookieは、**CSRF攻撃を軽減**します。ログインセッションが必要です。 -**\*Chrome80（2019年2月）から、SameSite 属性を持たないクッキーのデフォルトの動作は Lax になります** ([https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/](https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)).\ -この変更を適用した後、Chrome では **SameSite ポリシーを持たないクッキーは最初の2分間は None として扱われ、その後はトップレベルのクロスサイト POST リクエストに対して Lax として扱われます。** +**\*Chrome80（2019年2月）以降、CookieにSameSite属性がない場合のデフォルトの動作はLaxになります** ([https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/](https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)).\ +この変更を適用した後、**SameSiteポリシーのないCookie**は、最初の**2分間はNoneとして扱われ、その後はトップレベルのクロスサイトPOSTリクエストに対してLaxとして扱われます。** -## クッキーのフラグ +## Cookies Flags ### HttpOnly -これにより、**クライアント**がクッキーにアクセスするのを防ぎます（例えば、**Javascript** を介して： `document.cookie`）。 +これにより、**クライアント**がCookieにアクセスするのを防ぎます（例えば、**Javascript**経由で：`document.cookie`）。 -#### **バイパス** +#### **Bypasses** -- ページがリクエストのレスポンスとしてクッキーを**送信している**場合（例えば、**PHPinfo** ページで）、XSS を悪用してこのページにリクエストを送り、**レスポンスからクッキーを盗む**ことが可能です（例は [https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/](https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/) を参照）。 -- **TRACE** **HTTP** リクエストを使用することでバイパス可能です。この場合、サーバーからのレスポンスは送信されたクッキーを反映します。この技術は **Cross-Site Tracking** と呼ばれます。 -- この技術は、**モダンブラウザが JS から TRACE リクエストを送信することを許可しないことによって回避されます**。ただし、IE6.0 SP2 に対して `TRACE` の代わりに `\r\nTRACE` を送信するなど、特定のソフトウェアでのバイパスが見つかっています。 +- ページがリクエストのレスポンスとしてCookieを**送信している**場合（例えば、**PHPinfo**ページで）、XSSを悪用してこのページにリクエストを送り、レスポンスから**Cookieを盗む**ことが可能です（例は[こちら](https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/)を参照）。 +- **TRACE** **HTTP**リクエストを使用することでバイパス可能です。このHTTPメソッドが利用可能な場合、サーバーからのレスポンスは送信されたCookieを反映します。この技術は**Cross-Site Tracking**と呼ばれます。 +- この技術は、**モダンブラウザがJSからTRACEリクエストを送信することを許可しないことによって回避されます**。ただし、IE6.0 SP2に対して`TRACE`の代わりに`\r\nTRACE`を送信するなど、特定のソフトウェアでのバイパスが見つかっています。 - もう一つの方法は、ブラウザのゼロデイ脆弱性を悪用することです。 -- クッキージャーオーバーフロー攻撃を実行することで、**HttpOnly クッキーを上書きする**ことが可能です： +- Cookie Jarオーバーフロー攻撃を実行することで、**HttpOnly Cookieを上書きする**ことが可能です： {{#ref}} cookie-jar-overflow.md {{#endref}} -- これらのクッキーを外部に持ち出すために [**Cookie Smuggling**](#cookie-smuggling) 攻撃を使用することが可能です。 +- これらのCookieを外部に持ち出すために[**Cookie Smuggling**](#cookie-smuggling)攻撃を使用することが可能です。 ### Secure -リクエストは、**HTTPS** などの安全なチャネルを介して送信される場合にのみ、クッキーを HTTP リクエストで**送信**します。 +リクエストは、**HTTPS**などの安全なチャネルを介して送信される場合にのみ、HTTPリクエストでCookieを**送信します**。 -## クッキーのプレフィックス +## Cookies Prefixes -`__Secure-` で始まるクッキーは、HTTPS によって保護されたページから `secure` フラグとともに設定される必要があります。 +`__Secure-`で始まるCookieは、HTTPSで保護されたページから`secure`フラグとともに設定される必要があります。 -`__Host-` で始まるクッキーには、いくつかの条件が満たされなければなりません： +`__Host-`で始まるCookieには、いくつかの条件が満たされなければなりません： -- `secure` フラグで設定されなければなりません。 -- HTTPS によって保護されたページから発信されなければなりません。 +- `secure`フラグで設定されなければなりません。 +- HTTPSで保護されたページから発信されなければなりません。 - ドメインを指定することは禁じられており、サブドメインへの送信を防ぎます。 -- これらのクッキーのパスは `/` に設定されなければなりません。 +- これらのCookieのパスは`/`に設定されなければなりません。 -`__Host-` で始まるクッキーは、スーパードメインやサブドメインに送信されることは許可されていないことに注意することが重要です。この制限は、アプリケーションクッキーを隔離するのに役立ちます。したがって、すべてのアプリケーションクッキーに `__Host-` プレフィックスを使用することは、セキュリティと隔離を強化するための良いプラクティスと見なされます。 +`__Host-`で始まるCookieは、スーパードメインやサブドメインに送信されることは許可されていないことに注意することが重要です。この制限は、アプリケーションCookieを隔離するのに役立ちます。したがって、すべてのアプリケーションCookieに`__Host-`プレフィックスを使用することは、セキュリティと隔離を強化するための良いプラクティスと見なされます。 -### クッキーの上書き +### Overwriting cookies -したがって、`__Host-` プレフィックスのクッキーの保護の一つは、サブドメインからの上書きを防ぐことです。たとえば、[**Cookie Tossing attacks**](cookie-tossing.md) を防ぎます。トークで [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**論文**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)) では、パーサーを騙すことでサブドメインから __HOST- プレフィックスのクッキーを設定することが可能であることが示されています。たとえば、最初や最後に "=" を追加することです： +したがって、`__Host-`で始まるCookieの保護の一つは、サブドメインからの上書きを防ぐことです。たとえば、[**Cookie Tossing attacks**](cookie-tossing.md)を防ぎます。トークで[**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**paper**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf))では、パーサーを騙すことでサブドメインから__HOST-で始まるCookieを設定することが可能であることが示されています。たとえば、最初や最後に`=`を追加することなどです：
-また、PHP ではクッキー名の先頭に**他の文字を追加**することで、**アンダースコア**文字に置き換えられ、`__HOST-` クッキーを上書きすることが可能でした： +また、PHPでは、Cookie名の先頭に**他の文字を追加する**ことで、**アンダースコア**文字に置き換えられ、`__HOST-` Cookieを上書きすることが可能でした：
-## クッキー攻撃 +## Cookies Attacks -カスタムクッキーに機密データが含まれている場合は、それを確認してください（特に CTF を行っている場合）、脆弱性があるかもしれません。 +カスタムCookieに機密データが含まれている場合は、特にCTFを行っている場合は確認してください。脆弱性があるかもしれません。 -### クッキーのデコードと操作 +### Decoding and Manipulating Cookies -クッキーに埋め込まれた機密データは常に精査されるべきです。Base64 や類似の形式でエンコードされたクッキーは、しばしばデコード可能です。この脆弱性により、攻撃者はクッキーの内容を変更し、修正されたデータを再度クッキーにエンコードすることで他のユーザーを偽装することができます。 +Cookieに埋め込まれた機密データは常に精査されるべきです。Base64や類似の形式でエンコードされたCookieは、しばしばデコード可能です。この脆弱性により、攻撃者はCookieの内容を変更し、他のユーザーを偽装するために修正されたデータを再度Cookieにエンコードすることができます。 -### セッションハイジャック +### Session Hijacking -この攻撃は、ユーザーのクッキーを盗んで、アプリケーション内のアカウントに不正にアクセスすることを含みます。盗まれたクッキーを使用することで、攻撃者は正当なユーザーを偽装できます。 +この攻撃は、ユーザーのCookieを盗んで、アプリケーション内のアカウントに不正にアクセスすることを含みます。盗まれたCookieを使用することで、攻撃者は正当なユーザーを偽装できます。 -### セッション固定 +### Session Fixation -このシナリオでは、攻撃者が被害者を特定のクッキーを使用してログインさせるように仕向けます。アプリケーションがログイン時に新しいクッキーを割り当てない場合、攻撃者は元のクッキーを持っているため、被害者を偽装できます。この技術は、被害者が攻撃者が提供したクッキーでログインすることに依存しています。 +このシナリオでは、攻撃者が被害者を特定のCookieを使用してログインさせるように仕向けます。アプリケーションがログイン時に新しいCookieを割り当てない場合、攻撃者は元のCookieを持っているため、被害者を偽装できます。この技術は、被害者が攻撃者が提供したCookieでログインすることに依存しています。 -**サブドメインに XSS を見つけた場合**や **サブドメインを制御している場合**は、次をお読みください： +**サブドメインにXSSを見つけた場合**や**サブドメインを制御している場合**は、次を読んでください： {{#ref}} cookie-tossing.md {{#endref}} -### セッション寄付 +### Session Donation -ここでは、攻撃者が被害者に攻撃者のセッションクッキーを使用させるように仕向けます。被害者は自分のアカウントにログインしていると信じて、攻撃者のアカウントのコンテキストで意図せずにアクションを実行します。 +ここでは、攻撃者が被害者に攻撃者のセッションCookieを使用させるように仕向けます。被害者は自分のアカウントにログインしていると信じて、攻撃者のアカウントのコンテキストで意図せずにアクションを実行します。 -**サブドメインに XSS を見つけた場合**や **サブドメインを制御している場合**は、次をお読みください： +**サブドメインにXSSを見つけた場合**や**サブドメインを制御している場合**は、次を読んでください： {{#ref}} cookie-tossing.md {{#endref}} -### [JWT クッキー](../hacking-jwt-json-web-tokens.md) +### [JWT Cookies](../hacking-jwt-json-web-tokens.md) -前のリンクをクリックして、JWT の可能な欠陥を説明するページにアクセスしてください。 +前のリンクをクリックして、JWTの可能な欠陥を説明するページにアクセスしてください。 -クッキーで使用される JSON Web Tokens (JWT) も脆弱性を示す可能性があります。潜在的な欠陥とそれを悪用する方法についての詳細情報は、JWT ハッキングに関するリンクされた文書にアクセスすることをお勧めします。 +Cookieで使用されるJSON Web Tokens（JWT）も脆弱性を示す可能性があります。潜在的な欠陥とそれを悪用する方法についての詳細情報は、JWTのハッキングに関するリンクされた文書にアクセスすることをお勧めします。 -### クロスサイトリクエストフォージェリ (CSRF) +### Cross-Site Request Forgery (CSRF) -この攻撃は、ログイン中のユーザーに対して、現在認証されているウェブアプリケーションで不要なアクションを実行させるものです。攻撃者は、脆弱なサイトへのすべてのリクエストに自動的に送信されるクッキーを悪用できます。 +この攻撃は、ログイン中のユーザーに対して、現在認証されているWebアプリケーションで不要なアクションを実行させるものです。攻撃者は、脆弱なサイトへのすべてのリクエストに自動的に送信されるCookieを悪用できます。 -### 空のクッキー +### Empty Cookies -（詳細は[元の研究](https://blog.ankursundara.com/cookie-bugs/)を参照してください）ブラウザは名前のないクッキーの作成を許可しており、次のように JavaScript で示すことができます： +（詳細は[元の研究](https://blog.ankursundara.com/cookie-bugs/)を参照してください）ブラウザは名前のないCookieの作成を許可しており、次のようにJavaScriptで示すことができます： ```js document.cookie = "a=v1" document.cookie = "=test value;" // Setting an empty named cookie @@ -155,15 +155,15 @@ document.cookie = `${name}=${value}` setCookie("", "a=b") // Setting the empty cookie modifies another cookie's value ``` -これにより、ブラウザはすべてのウェブサーバーによって `a` という名前のクッキーと `b` という値として解釈されるクッキー ヘッダーを送信します。 +これにより、ブラウザはクッキーヘッダーを送信し、すべてのウェブサーバーはそれを値 `b` のクッキー `a` として解釈します。 -#### Chrome バグ: Unicode サロゲート コードポイントの問題 +#### Chromeのバグ: Unicodeサロゲートコードポイントの問題 -Chrome では、Unicode サロゲート コードポイントがセットされたクッキーの一部である場合、`document.cookie` が破損し、その後空の文字列を返します: +Chromeでは、Unicodeサロゲートコードポイントが設定されたクッキーの一部である場合、`document.cookie` が破損し、その後空の文字列を返します: ```js document.cookie = "\ud800=meep" ``` -これにより、`document.cookie`が空の文字列を出力し、永続的な破損を示します。 +この結果、`document.cookie`が空の文字列を出力し、永続的な破損を示します。 #### パースの問題によるクッキーのスモグリング @@ -179,24 +179,50 @@ RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end"; - Zope は、次のクッキーの解析を開始するためにカンマを探します。 - Python のクッキークラスは、スペース文字で解析を開始します。 -この脆弱性は、クッキーに基づく CSRF 保護に依存するウェブアプリケーションにとって特に危険であり、攻撃者が偽装された CSRF トークンクッキーを注入し、セキュリティ対策を回避する可能性があります。この問題は、Python が重複したクッキー名を処理する方法によって悪化し、最後の出現が以前のものを上書きします。また、`__Secure-` および `__Host-` クッキーが安全でないコンテキストで扱われることに対する懸念を引き起こし、クッキーが偽装に対して脆弱なバックエンドサーバーに渡されると、認証バイパスにつながる可能性があります。 +この脆弱性は、クッキーベースの CSRF 保護に依存するウェブアプリケーションにとって特に危険であり、攻撃者が偽装された CSRF トークンクッキーを注入し、セキュリティ対策を回避する可能性があります。この問題は、Python が重複したクッキー名を処理する方法によって悪化し、最後の出現が以前のものを上書きします。また、`__Secure-` および `__Host-` クッキーが不安全なコンテキストで扱われることに対する懸念を引き起こし、クッキーが偽装に対して脆弱なバックエンドサーバーに渡されると、認可のバイパスにつながる可能性があります。 -### Cookies $version and WAF bypasses +### Cookies $version -According to [**this blogpost**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie), **`$Version=1`** クッキー属性を使用して、バックエンドが **RFC2109** に基づいて古いロジックを使用してクッキーを解析することが可能かもしれません。さらに、**`$Domain`** や **`$Path`** といった他の値も、クッキーを使用してバックエンドの動作を変更するために使用できます。 +#### WAF Bypass -#### Bypassing value analysis with quoted-string encoding +According to [**this blogpost**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie), **`$Version=1`** クッキー属性を使用して、バックエンドが古いロジックを使用してクッキーを解析することが可能かもしれません。これは **RFC2109** によるものです。さらに、**`$Domain`** や **`$Path`** といった他の値も、クッキーを使用してバックエンドの動作を変更するために使用できます。 -この解析は、クッキー内のエスケープされた値をアンエスケープすることを示しており、したがって "\a" は "a" になります。これは WAF を回避するのに役立つ可能性があります： +#### Cookie Sandwich Attack + +According to [**this blogpost**](https://portswigger.net/research/stealing-httponly-cookies-with-the-cookie-sandwich-technique) クッキーサンドイッチ技術を使用して HttpOnly クッキーを盗むことが可能です。これらは要件と手順です： + +- 明らかに無駄な **クッキーがレスポンスに反映される場所を見つける** +- **`$Version`** という名前のクッキーを値 `1` で作成する（これは JS からの XSS 攻撃で行うことができます）し、初期位置を取得するためにより具体的なパスを設定します（Python のような一部のフレームワークではこのステップは必要ありません） +- **反映されるクッキーを作成** し、**オープンダブルクォート** を残す値を設定し、前のクッキー（`$Version`）の後に位置するように特定のパスを設定します +- その後、正当なクッキーが順番に続きます +- **ダミークッキーを作成し、ダブルクォートを閉じる** 値を持たせます + +このようにして、被害者のクッキーは新しいクッキーのバージョン1の中に閉じ込められ、反映されるたびに反映されます。 +e.g. from the post: +```javascript +document.cookie = `$Version=1;`; +document.cookie = `param1="start`; +// any cookies inside the sandwich will be placed into param1 value server-side +document.cookie = `param2=end";`; +``` +### WAFバイパス + +#### Cookies $version + +前のセクションを確認してください。 + +#### 引用文字列エンコーディングによる値分析のバイパス + +この解析は、クッキー内のエスケープされた値をアンエスケープすることを示しています。したがって、"\a"は"a"になります。これはWAFをバイパスするのに役立つ場合があります： - `eval('test') => forbidden` - `"\e\v\a\l\(\'\t\e\s\t\'\)" => allowed` -#### Bypassing cookie-name blocklists +#### クッキー名ブロックリストのバイパス -RFC2109 では、**カンマをクッキー値の区切りとして使用できる**ことが示されています。また、**等号の前後にスペースやタブを追加することも可能です**。したがって、クッキー `$Version=1; foo=bar, abc = qux` は、クッキー `"foo":"bar, admin = qux"` を生成するのではなく、クッキー `foo":"bar"` と `"admin":"qux"` を生成します。2つのクッキーが生成され、admin の等号の前後のスペースが削除されたことに注意してください。 +RFC2109では、**カンマをクッキー値の区切りとして使用できる**ことが示されています。また、**等号の前後にスペースやタブを追加することも可能です**。したがって、クッキー`$Version=1; foo=bar, abc = qux`は、クッキー`"foo":"bar, admin = qux"`を生成するのではなく、クッキー`foo":"bar"`と`"admin":"qux"`を生成します。2つのクッキーが生成され、adminの前後のスペースが削除されたことに注意してください。 -#### Bypassing value analysis with cookie splitting +#### クッキー分割による値分析のバイパス 最後に、異なるバックドアは、異なるクッキーヘッダーで渡された異なるクッキーを文字列として結合します。 ``` @@ -226,10 +252,10 @@ Resulting cookie: name=eval('test//, comment') => allowed #### **高度なクッキー攻撃** -ログイン時にクッキーが同じ（またはほぼ同じ）である場合、これはおそらくクッキーがアカウントのいくつかのフィールド（おそらくユーザー名）に関連していることを意味します。次に、以下を試みることができます： +ログイン時にクッキーが同じ（またはほぼ同じ）である場合、これはおそらくクッキーがあなたのアカウントのいくつかのフィールド（おそらくユーザー名）に関連していることを意味します。次に、あなたは： - 非常に**似た**ユーザー名でたくさんの**アカウント**を作成し、アルゴリズムがどのように機能しているかを**推測**してみてください。 -- **ユーザー名をブルートフォース**してみてください。クッキーがユーザー名の認証方法としてのみ保存されている場合、ユーザー名"**Bmin**"でアカウントを作成し、クッキーの**ビット**をすべて**ブルートフォース**することができます。なぜなら、試すクッキーの1つは"**admin**"に属するものだからです。 +- **ユーザー名をブルートフォース**してみてください。クッキーがあなたのユーザー名の認証方法としてのみ保存されている場合、ユーザー名"**Bmin**"でアカウントを作成し、クッキーのすべての**ビット**を**ブルートフォース**することができます。なぜなら、あなたが試すクッキーの1つは"**admin**"に属するものだからです。 - **パディング** **オラクル**を試してください（クッキーの内容を復号化できます）。**padbuster**を使用してください。 **パディングオラクル - Padbusterの例** @@ -250,7 +276,7 @@ Padbusterは複数回の試行を行い、どの条件がエラー条件（無 ``` padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator ``` -この実行により、文字列 **user=administrator** が内部に含まれた正しく暗号化され、エンコードされたクッキーが得られます。 +この実行により、**user=administrator**という文字列が正しく暗号化され、エンコードされたクッキーが得られます。 **CBC-MAC** @@ -271,9 +297,9 @@ padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lB ほぼ同じデータ（ユーザー名、パスワード、メールなど）を持つ2つのユーザーを作成し、与えられたクッキー内のパターンを発見しようとします。 -例えば "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" という名前のユーザーを作成し、クッキーにパターンがあるかどうかを確認します（ECBは同じキーで各ブロックを暗号化するため、ユーザー名が暗号化されると同じ暗号化されたバイトが現れる可能性があります）。 +例えば「aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa」というユーザーを作成し、クッキーにパターンがあるかどうかを確認します（ECBは同じキーで各ブロックを暗号化するため、ユーザー名が暗号化されると同じ暗号化されたバイトが現れる可能性があります）。 -使用されるブロックのサイズでパターンが存在するはずです。したがって、"a" の一群がどのように暗号化されるかを知っていれば、ユーザー名を "a"*(ブロックのサイズ)+"admin" と作成できます。その後、クッキーから "a" のブロックの暗号化パターンを削除することができます。そして、ユーザー名 "admin" のクッキーを得ることができます。 +使用されるブロックのサイズでパターンが存在するはずです。したがって、「a」をブロックのサイズ分繰り返したユーザー名「a」*(ブロックのサイズ) + "admin"を作成できます。その後、クッキーから「a」のブロックの暗号化パターンを削除することができます。そして、ユーザー名「admin」のクッキーを得ることができます。 ## 参考文献