diff --git a/src/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.md b/src/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.md index f52624481..a76cbfed1 100644 --- a/src/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.md +++ b/src/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.md @@ -2,16 +2,13 @@ {{#include ../../banners/hacktricks-training.md}} -資産のリストを構築したので、OSINTの低ハンギングフルーツを探す時が来ました。 - -### すでに漏洩を検索したプラットフォーム - -- [https://trufflesecurity.com/blog/introducing-forager/](https://trufflesecurity.com/blog/introducing-forager/) - -### GithubにおけるAPIキーの漏洩 +### 秘密を見つけるためのツール（gitリポジトリとファイルシステム） - [https://github.com/dxa4481/truffleHog](https://github.com/dxa4481/truffleHog) - [https://github.com/gitleaks/gitleaks](https://github.com/gitleaks/gitleaks) +- [https://github.com/praetorian-inc/noseyparker](https://github.com/praetorian-inc/noseyparker) +- [https://github.com/GitGuardian/ggshield](https://github.com/GitGuardian/ggshield) +- [https://github.com/JaimePolop/RExpository](https://github.com/JaimePolop/RExpository) - [https://github.com/Yelp/detect-secrets](https://github.com/Yelp/detect-secrets) - [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber) - [https://github.com/eth0izzle/shhgit](https://github.com/eth0izzle/shhgit) diff --git a/src/pentesting-web/oauth-to-account-takeover.md b/src/pentesting-web/oauth-to-account-takeover.md index 963ed5b94..478965fb3 100644 --- a/src/pentesting-web/oauth-to-account-takeover.md +++ b/src/pentesting-web/oauth-to-account-takeover.md @@ -4,13 +4,13 @@ ## Basic Information -OAuthはさまざまなバージョンを提供しており、基本的な情報は[OAuth 2.0 documentation](https://oauth.net/2/)で入手できます。この議論は主に広く使用されている[OAuth 2.0 authorization code grant type](https://oauth.net/2/grant-types/authorization-code/)に焦点を当てており、**アプリケーションが他のアプリケーション内のユーザーアカウントにアクセスしたり、アクションを実行したりすることを可能にする認可フレームワーク**を提供します（認可サーバー）。 +OAuthはさまざまなバージョンを提供しており、基本的な洞察は[OAuth 2.0 documentation](https://oauth.net/2/)でアクセス可能です。この議論は主に広く使用されている[OAuth 2.0 authorization code grant type](https://oauth.net/2/grant-types/authorization-code/)に焦点を当てており、**アプリケーションが他のアプリケーション内のユーザーのアカウントにアクセスまたはアクションを実行できるようにする認可フレームワーク**を提供します（認可サーバー）。 -仮想のウェブサイト_**https://example.com**_を考えてみてください。これは**すべてのソーシャルメディア投稿を表示する**ために設計されています。プライベートな投稿も含まれます。これを実現するためにOAuth 2.0が使用されます。_https://example.com_はあなたの**ソーシャルメディア投稿にアクセスする**ための許可を求めます。その結果、_https://socialmedia.com_で同意画面が表示され、**要求されている権限とリクエストを行っている開発者**が示されます。あなたが承認すると、_https://example.com_はあなたの**代わりに投稿にアクセスする**能力を得ます。 +仮想のウェブサイト_**https://example.com**_を考えてみてください。これは**すべてのソーシャルメディア投稿を表示する**ために設計されています。プライベートな投稿も含まれます。これを実現するために、OAuth 2.0が使用されます。_https://example.com_は**あなたのソーシャルメディア投稿にアクセスする**ための許可を求めます。その結果、_https://socialmedia.com_に同意画面が表示され、**要求されている権限とリクエストを行っている開発者**が示されます。あなたが承認すると、_https://example.com_は**あなたの代わりに投稿にアクセスする**能力を得ます。 OAuth 2.0フレームワーク内の以下のコンポーネントを理解することが重要です： -- **resource owner**: あなた、すなわち**ユーザー/エンティティ**が、ソーシャルメディアアカウントの投稿などのリソースへのアクセスを許可します。 +- **resource owner**: あなた、つまり**ユーザー/エンティティ**が、ソーシャルメディアアカウントの投稿など、自分のリソースへのアクセスを許可します。 - **resource server**: **リソースオーナー**の代わりに`access token`を取得した後に認証されたリクエストを管理する**サーバー**、例：**https://socialmedia.com**。 - **client application**: **リソースオーナー**からの認可を求める**アプリケーション**、例：**https://example.com**。 - **authorization server**: **リソースオーナー**の認証が成功し、認可が得られた後に`client application`に`access tokens`を発行する**サーバー**、例：**https://socialmedia.com**。 @@ -18,11 +18,11 @@ OAuth 2.0フレームワーク内の以下のコンポーネントを理解す - **client_secret:** アプリケーションと認可サーバーのみに知られる機密鍵で、`access_tokens`を生成するために使用されます。 - **response_type**: **要求されるトークンのタイプ**を指定する値、例：`code`。 - **scope**: `client application`が`resource owner`から要求している**アクセスレベル**。 -- **redirect_uri**: **ユーザーが認可後にリダイレクトされるURL**。通常、事前に登録されたリダイレクトURLと一致する必要があります。 -- **state**: **ユーザーが認可サーバーにリダイレクトされる際にデータを保持するためのパラメータ**。ユニーク性は**CSRF保護メカニズム**として機能するために重要です。 +- **redirect_uri**: **ユーザーが認可後にリダイレクトされるURL**。これは通常、事前に登録されたリダイレクトURLと一致する必要があります。 +- **state**: **ユーザーが認可サーバーにリダイレクトされる際にデータを保持するためのパラメータ**。そのユニーク性は、**CSRF保護メカニズム**として機能するために重要です。 - **grant_type**: **グラントタイプと返されるトークンのタイプ**を示すパラメータ。 - **code**: `authorization server`からの認可コードで、`client application`が`access_token`を取得するために`client_id`と`client_secret`と共に使用します。 -- **access_token**: **リソースオーナーの代わりにAPIリクエストに使用されるトークン**。 +- **access_token**: **クライアントアプリケーションが`resource owner`の代わりにAPIリクエストに使用するトークン**。 - **refresh_token**: アプリケーションが**ユーザーに再度プロンプトを表示することなく新しい`access_token`を取得する**ことを可能にします。 ### Flow @@ -44,7 +44,7 @@ https://socialmedia.com/auth ``` https://example.com?code=uniqueCode123&state=randomString123 ``` -5. https://example.com はこの `code` を使用し、`client_id` と `client_secret` と共に、あなたの代わりに `access_token` を取得するためのサーバーサイドリクエストを行い、あなたが同意した権限へのアクセスを可能にします： +5. https://example.com はこの `code` を使用し、`client_id` と `client_secret` と共に、あなたの代わりに `access_token` を取得するためにサーバーサイドリクエストを行い、あなたが同意した権限へのアクセスを可能にします: ``` POST /oauth/access_token Host: socialmedia.com @@ -54,7 +54,7 @@ Host: socialmedia.com ## 脆弱性 -### オープンリダイレクト_uri +### オープンリダイレクトURI `redirect_uri` はOAuthおよびOpenIDの実装においてセキュリティにとって重要であり、認可後に認可コードなどの機密データが送信される場所を指示します。誤って設定されると、攻撃者がこれらのリクエストを悪意のあるサーバーにリダイレクトさせ、アカウントの乗っ取りを可能にすることがあります。 @@ -72,9 +72,9 @@ https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard -OAuthの実装において、**`state`パラメータ**の誤用または省略は、**クロスサイトリクエストフォージェリ（CSRF）**攻撃のリスクを大幅に増加させる可能性があります。この脆弱性は、`state`パラメータが**使用されていない、静的な値として使用されている、または適切に検証されていない**場合に発生し、攻撃者がCSRF保護を回避できるようになります。 +OAuthの実装において、**`state`パラメータ**の誤用または省略は、**クロスサイトリクエストフォージェリ（CSRF）**攻撃のリスクを大幅に増加させる可能性があります。この脆弱性は、`state`パラメータが**使用されていない、静的な値として使用されている、またはユーザーのセッションと適切に検証または関連付けられていない**場合に発生し、攻撃者がCSRF保護を回避できるようになります。 -攻撃者は、認可プロセスを傍受して自分のアカウントを被害者のアカウントにリンクさせることでこれを悪用し、潜在的な**アカウント乗っ取り**を引き起こすことができます。これは、OAuthが**認証目的**で使用されるアプリケーションでは特に重要です。 +攻撃者は、認証プロセスを傍受して自分のアカウントを被害者のアカウントにリンクさせることでこれを悪用し、攻撃者のほぼ完了したoauthフローを使用してユーザーにログインさせることによって、潜在的な**アカウント乗っ取り**を引き起こす可能性があります。これは、OAuthが**認証目的**で使用されるアプリケーションでは特に重要です。 この脆弱性の実例は、さまざまな**CTFチャレンジ**や**ハッキングプラットフォーム**で文書化されており、その実際の影響を強調しています。この問題は、**Slack**、**Stripe**、**PayPal**などのサードパーティサービスとの統合にも及び、攻撃者が通知や支払いを自分のアカウントにリダイレクトできる可能性があります。 @@ -82,14 +82,14 @@ OAuthの実装において、**`state`パラメータ**の誤用または省略 ### アカウント乗っ取り前 -1. **アカウント作成時のメール確認なし**: 攻撃者は被害者のメールを使用して事前にアカウントを作成できます。被害者が後にサードパーティサービスを使用してログインすると、アプリケーションがこのサードパーティアカウントを攻撃者の事前作成アカウントに誤ってリンクさせ、無許可のアクセスを引き起こす可能性があります。 -2. **緩いOAuthメール確認の悪用**: 攻撃者は、メールを確認しないOAuthサービスを悪用し、自分のサービスに登録した後、アカウントのメールを被害者のものに変更することができます。この方法も、最初のシナリオと同様に無許可のアカウントアクセスのリスクがありますが、異なる攻撃ベクターを通じて行われます。 +1. **アカウント作成時のメール確認なし**: 攻撃者は被害者のメールを使用して事前にアカウントを作成できます。被害者が後にサードパーティサービスを使用してログインすると、アプリケーションが誤ってこのサードパーティアカウントを攻撃者の事前作成アカウントにリンクさせ、無許可のアクセスを引き起こす可能性があります。 +2. **緩いOAuthメール確認の悪用**: 攻撃者は、メールを確認しないOAuthサービスを悪用し、自分のサービスに登録した後、アカウントのメールを被害者のものに変更することができます。この方法も、最初のシナリオと同様に無許可のアカウントアクセスのリスクを伴いますが、異なる攻撃ベクターを通じて行われます。 ### 秘密の開示 -秘密のOAuthパラメータを特定し保護することは重要です。**`client_id`**は安全に開示できますが、**`client_secret`**を明らかにすることは重大なリスクを伴います。`client_secret`が漏洩すると、攻撃者はアプリケーションのアイデンティティと信頼を悪用して**ユーザーの`access_tokens`**やプライベート情報を**盗む**ことができます。 +秘密のOAuthパラメータを特定し保護することは重要です。**`client_id`**は安全に開示できますが、**`client_secret`**を開示することは重大なリスクを伴います。`client_secret`が漏洩すると、攻撃者はアプリケーションのアイデンティティと信頼を悪用して**ユーザーの`access_tokens`**やプライベート情報を**盗む**ことができます。 -一般的な脆弱性は、アプリケーションが認可`code`を`access_token`に交換する際に、クライアント側ではなくサーバー側で誤って処理することから生じます。この誤りは`client_secret`の露出を引き起こし、攻撃者がアプリケーションの名義で`access_tokens`を生成できるようにします。さらに、ソーシャルエンジニアリングを通じて、攻撃者はOAuth認可に追加のスコープを追加することで権限をエスカレートし、アプリケーションの信頼された地位をさらに悪用することができます。 +一般的な脆弱性は、アプリケーションが認証`code`を`access_token`に交換する際に、クライアント側ではなくサーバー側で誤って処理する場合に発生します。この誤りは`client_secret`の露出を引き起こし、攻撃者がアプリケーションの名義で`access_tokens`を生成できるようにします。さらに、ソーシャルエンジニアリングを通じて、攻撃者はOAuth認証に追加のスコープを追加することで権限をエスカレートし、アプリケーションの信頼された地位をさらに悪用することができます。 ### クライアントシークレットブルートフォース @@ -106,15 +106,15 @@ code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=au ``` ### Referer Header leaking Code + State -クライアントが**code and state**を持っている場合、異なるページに移動するときにそれが**Refererヘッダー内に反映されている**と、脆弱です。 +クライアントが**コードとステート**を持っている場合、異なるページに移動するときにそれが**Refererヘッダー内に反映される**と、脆弱です。 ### Access Token Stored in Browser History -**ブラウザの履歴にアクセスして、アクセストークンが保存されているか確認します**。 +**ブラウザの履歴にアクセス トークンが保存されているか確認します**。 ### Everlasting Authorization Code -**認可コードは、攻撃者がそれを盗んで使用できる時間ウィンドウを制限するために、一定の時間だけ存在するべきです**。 +**認可コードは、攻撃者がそれを盗んで使用できる時間ウィンドウを制限するために、しばらくの間だけ存在する必要があります**。 ### Authorization/Refresh Token not bound to client @@ -149,48 +149,48 @@ For more detailed info about how to abuse AWS cognito check: https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.html {{#endref}} -### 他のアプリのトークンの悪用 +### Abusing other Apps tokens -[**この書き込みで言及されているように**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts)、**トークン**（コードではなく）を受け取ることを期待するOAuthフローは、トークンがアプリに属しているかどうかを確認しない場合、脆弱である可能性があります。 +[**この書き込みで述べられているように**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts)、**トークン**（コードではなく）を受け取ることを期待するOAuthフローは、トークンがアプリに属しているかどうかを確認しない場合、脆弱である可能性があります。 -これは、**攻撃者**が自分のアプリケーションで**OAuthをサポートし、Facebookでログイン**する**アプリケーション**を作成できるためです。次に、被害者が**攻撃者のアプリケーション**でFacebookにログインすると、攻撃者は**被害者のアプリケーションに与えられたユーザーのOAuthトークンを取得し、それを使用して被害者のOAuthアプリケーションにログインすることができます**。 +これは、**攻撃者**が自分のアプリケーションで**OAuthをサポートするアプリケーションを作成し、Facebookでログイン**（例えば）できるためです。そして、被害者が**攻撃者のアプリケーション**でFacebookにログインすると、攻撃者は**自分のアプリケーションに与えられたユーザーのOAuthトークンを取得し、それを使用して被害者のOAuthアプリケーションにログインすることができます**。 > [!CAUTION] -> したがって、攻撃者がユーザーに自分のOAuthアプリケーションへのアクセスを取得することに成功すれば、トークンを期待しているアプリケーションで被害者のアカウントを乗っ取ることができます。 +> したがって、攻撃者がユーザーに自分のOAuthアプリケーションへのアクセスを取得することに成功すれば、トークンを期待しているアプリケーションで被害者のアカウントを乗っ取ることができるでしょう。 -### 2つのリンクとクッキー +### Two links & cookie [**この書き込みによると**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f)、被害者が攻撃者のホストを指す**returnUrl**を持つページを開くことが可能でした。この情報は**クッキー（RU）**に**保存され**、**後のステップ**で**プロンプト**が**ユーザー**にその攻撃者のホストへのアクセスを許可するかどうかを**尋ねます**。 -このプロンプトを回避するために、**returnUrl**を使用してこのRUクッキーを設定する**Oauthフロー**を開始するタブを開き、プロンプトが表示される前にタブを閉じ、その値なしで新しいタブを開くことが可能でした。そうすると、**プロンプトは攻撃者のホストについて通知しませんが、クッキーはそれに設定されるため、**トークンはリダイレクトで攻撃者のホストに送信されます**。 +このプロンプトを回避するために、**Oauthフロー**を開始するためのタブを開き、このRUクッキーを**returnUrl**を使用して設定し、プロンプトが表示される前にタブを閉じ、新しいタブをその値なしで開くことが可能でした。これにより、**プロンプトは攻撃者のホストについて通知しませんが、クッキーはそれに設定されるため、**トークンはリダイレクトで攻撃者のホストに送信されます**。 -### プロンプトインタラクションバイパス +### Prompt Interaction Bypass -[**このビデオで説明されているように**](https://www.youtube.com/watch?v=n9x7_J_a_7Q)、一部のOAuth実装では、**`prompt`** GETパラメータをNone（**`&prompt=none`**）として指定することで、プラットフォームにすでにログインしている場合に、ウェブ上で与えられたアクセスを確認するようにユーザーに求めることを**防ぐ**ことができます。 +[**このビデオで説明されているように**](https://www.youtube.com/watch?v=n9x7_J_a_7Q)、一部のOAuth実装では、**`prompt`** GETパラメータをNone（**`&prompt=none`**）として指定することで、ユーザーがプラットフォームに既にログインしている場合に、ウェブ上で与えられたアクセスを確認するように求められないようにすることができます。 ### response_mode -[**このビデオで説明されているように**](https://www.youtube.com/watch?v=n9x7_J_a_7Q)、**`response_mode`**パラメータを指定して、最終URLでコードをどこに提供したいかを示すことが可能です： +[**このビデオで説明されているように**](https://www.youtube.com/watch?v=n9x7_J_a_7Q)、**`response_mode`**パラメータを指定して、最終URLでコードをどこに提供するかを示すことが可能です： - `response_mode=query` -> コードはGETパラメータ内に提供されます：`?code=2397rf3gu93f` - `response_mode=fragment` -> コードはURLフラグメントパラメータ内に提供されます`#code=2397rf3gu93f` -- `response_mode=form_post` -> コードは`code`という入力を持つPOSTフォーム内に提供されます +- `response_mode=form_post` -> コードは`code`という入力を持つPOSTフォーム内に提供され、その値が含まれます - `response_mode=web_message` -> コードはポストメッセージで送信されます：`window.opener.postMessage({"code": "asdasdasd...` -### OAuth ROPCフロー - 2FAバイパス +### OAuth ROPC flow - 2 FA bypass -[**このブログ投稿によると**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96)、これは**ユーザー名**と**パスワード**を介してOAuthにログインすることを許可するOAuthフローです。この単純なフロー中に、ユーザーが実行できるすべてのアクションへのアクセスを持つ**トークン**が返される場合、そのトークンを使用して2FAをバイパスすることが可能です。 +[**このブログ投稿によると**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96)、これは**ユーザー名**と**パスワード**を介してOAuthにログインすることを可能にするOAuthフローです。この単純なフロー中に、ユーザーが実行できるすべてのアクションへのアクセスを持つ**トークン**が返される場合、そのトークンを使用して2FAを回避することが可能です。 -### オープンリダイレクトに基づくウェブページのリダイレクトでのATO +### ATO on web page redirecting based on open redirect to referrer -この[**ブログ投稿**](https://blog.voorivex.team/oauth-non-happy-path-to-ato)は、**オープンリダイレクト**を利用して**リファラー**からの値を悪用し、OAuthを使用してATOを行う方法についてコメントしています。攻撃は次の通りです： +この[**ブログ投稿**](https://blog.voorivex.team/oauth-non-happy-path-to-ato)は、**リファラー**からの値への**オープンリダイレクト**を悪用してOAuthをATOに悪用する方法についてコメントしています。攻撃は次の通りです： 1. 被害者が攻撃者のウェブページにアクセスします -2. 被害者が悪意のあるリンクを開くと、オープナーが`response_type=id_token,code&prompt=none`を追加パラメータとして使用してGoogle OAuthフローを開始します。**リファラーは攻撃者のウェブサイト**です。 -3. オープナーで、プロバイダーが被害者を認可すると、`redirect_uri`パラメータの値（被害者のウェブ）に30Xコードで戻しますが、攻撃者のウェブサイトはリファラーに残ります。 -4. 被害者の**ウェブサイトはリファラーに基づいてオープンリダイレクトをトリガーし**、被害者のユーザーを攻撃者のウェブサイトにリダイレクトします。**`respose_type`**が**`id_token,code`**であったため、コードは**URLのフラグメント**で攻撃者に返され、被害者のサイトを介してユーザーのアカウントを乗っ取ることができます。 +2. 被害者が悪意のあるリンクを開き、オープナーが`response_type=id_token,code&prompt=none`を追加パラメータとして使用してGoogle OAuthフローを開始します。**リファラーは攻撃者のウェブサイト**です。 +3. オープナーで、プロバイダーが被害者を認可すると、`redirect_uri`パラメータの値（被害者のウェブ）に30Xコードで戻します。これにより、攻撃者のウェブサイトがリファラーに残ります。 +4. 被害者の**ウェブサイトはリファラーに基づいてオープンリダイレクトをトリガーし**、被害者のユーザーを攻撃者のウェブサイトにリダイレクトします。**`respose_type`**が**`id_token,code`**であったため、コードはURLの**フラグメント**で攻撃者に返され、被害者のサイトを介してGoogleのアカウントを乗っ取ることが可能になります。 -### SSRFsパラメータ +### SSRFs parameters [**この研究を確認してください**](https://portswigger.net/research/hidden-oauth-attack-vectors) **この技術の詳細について。** @@ -199,25 +199,47 @@ OAuthにおける動的クライアント登録は、特に**サーバーサイ **重要なポイント：** - **動的クライアント登録**は通常`/register`にマッピングされ、`client_name`、`client_secret`、`redirect_uris`、ロゴやJSON Web Key Sets（JWKs）のURLなどの詳細をPOSTリクエストで受け入れます。 -- この機能は、**RFC7591**および**OpenID Connect Registration 1.0**に記載された仕様に準拠しており、SSRFに対して脆弱なパラメータを含んでいます。 +- この機能は、**RFC7591**および**OpenID Connect Registration 1.0**に記載された仕様に従い、SSRFに対して脆弱なパラメータを含む可能性があります。 - 登録プロセスは、いくつかの方法でサーバーをSSRFにさらす可能性があります： - **`logo_uri`**：サーバーによって取得される可能性のあるクライアントアプリケーションのロゴのURLで、SSRFを引き起こすか、URLが不適切に処理された場合にXSSを引き起こす可能性があります。 - **`jwks_uri`**：クライアントのJWKドキュメントへのURLで、悪意を持って作成された場合、サーバーが攻撃者が制御するサーバーへの外部リクエストを行う原因となる可能性があります。 - **`sector_identifier_uri`**：サーバーが取得する可能性のある`redirect_uris`のJSON配列を参照し、SSRFの機会を生み出します。 -- **`request_uris`**：クライアントの許可されたリクエストURIをリストし、サーバーが認可プロセスの開始時にこれらのURIを取得する場合に悪用される可能性があります。 +- **`request_uris`**：クライアントのために許可されたリクエストURIをリストし、サーバーが認可プロセスの開始時にこれらのURIを取得する場合に悪用される可能性があります。 **悪用戦略：** -- SSRFは、`logo_uri`、`jwks_uri`、または`sector_identifier_uri`のパラメータに悪意のあるURLを持つ新しいクライアントを登録することで引き起こされる可能性があります。 -- `request_uris`を介った直接的な悪用はホワイトリスト制御によって軽減される可能性がありますが、事前に登録された攻撃者が制御する`request_uri`を提供することで、認可フェーズ中にSSRFを促進することができます。 +- SSRFは、`logo_uri`、`jwks_uri`、または`sector_identifier_uri`のパラメータに悪意のあるURLを持つ新しいクライアントを登録することでトリガーされる可能性があります。 +- `request_uris`を介した直接的な悪用はホワイトリスト制御によって軽減される可能性がありますが、事前に登録された攻撃者が制御する`request_uri`を提供することで、認可フェーズ中にSSRFを促進することができます。 -## OAuthプロバイダーのレースコンディション +## OAuth providers Race Conditions -テストしているプラットフォームがOAuthプロバイダーである場合、[**レースコンディションの可能性をテストするためにこれを読んでください**](race-condition.md)。 +テストしているプラットフォームがOAuthプロバイダーである場合、[**レース条件の可能性をテストするためにこれを読んでください**](race-condition.md)。 -## 参考文献 +## Mutable Claims Attack + +OAuthでは、subフィールドがユーザーを一意に識別しますが、その形式は認可サーバーによって異なります。ユーザー識別を標準化するために、一部のクライアントはメールアドレスやユーザーハンドルを使用します。しかし、これはリスクがあります： + +- 一部の認可サーバーは、これらのプロパティ（メールアドレスなど）が不変であることを保証しません。 +- **"Microsoftでログイン"**のような特定の実装では、クライアントはメールフィールドに依存しており、これは**Entra IDでユーザーによって制御され、検証されていません**。 +- 攻撃者は、自分のAzure AD組織（例：doyensectestorg）を作成し、それを使用してMicrosoftログインを実行することでこれを悪用できます。 +- Object ID（subに保存されている）は不変で安全ですが、可変のメールフィールドに依存することでアカウントの乗っ取りが可能になります（例えば、victim@gmail.comのようなアカウントをハイジャックすること）。 + +## Client Confusion Attack + +**クライアント混乱攻撃**では、OAuthインプリシットフローを使用するアプリケーションが、最終的なアクセストークンが特定のクライアントIDのために生成されたものであることを確認しません。攻撃者は、GoogleのOAuthインプリシットフローを使用する公開ウェブサイトを設定し、何千人ものユーザーを騙してログインさせ、その結果、攻撃者のサイト向けに意図されたアクセストークンを収集します。これらのユーザーが、トークンのクライアントIDを検証しない別の脆弱なウェブサイトにアカウントを持っている場合、攻撃者は収集したトークンを再利用して被害者を偽装し、アカウントを乗っ取ることができます。 + +## Scope Upgrade Attack + +**Authorization Code Grant**タイプは、ユーザーデータを送信するための安全なサーバー間通信を含みます。しかし、**Authorization Server**がアクセストークンリクエストのスコープパラメータを暗黙的に信頼する場合（RFCで定義されていないパラメータ）、悪意のあるアプリケーションがより高いスコープを要求することで認可コードの権限をアップグレードする可能性があります。**アクセストークン**が生成された後、**リソースサーバー**はそれを検証する必要があります：JWTトークンの場合、これはJWT署名を確認し、client_idやscopeなどのデータを抽出することを含みます。一方、ランダム文字列トークンの場合、サーバーは認可サーバーにクエリを行い、トークンの詳細を取得する必要があります。 + +## Redirect Scheme Hijacking + +モバイルOAuth実装では、アプリが**カスタムURIスキーム**を使用して認可コードを受け取るリダイレクトを受け取ります。しかし、複数のアプリがデバイス上で同じスキームを登録できるため、正当なクライアントのみがリダイレクトURIを制御しているという仮定が破られます。例えば、Androidでは、`com.example.app://`のようなIntent URIが、アプリのintent-filterで定義されたスキームとオプションのフィルターに基づいてキャッチされます。Androidのインテント解決は広範囲にわたる可能性があるため（特にスキームのみが指定されている場合）、攻撃者は巧妙に作成されたインテントフィルターを持つ悪意のあるアプリを登録して認可コードをハイジャックすることができます。これにより、ユーザーの相互作用（複数のアプリがインテントを処理する資格がある場合）または過度に特定的なフィルターを悪用するバイパステクニックを通じて**アカウントの乗っ取り**が可能になります。 + +## References - [**https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1**](https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1) - [**https://portswigger.net/research/hidden-oauth-attack-vectors**](https://portswigger.net/research/hidden-oauth-attack-vectors) +- [**https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html**](https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html) {{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/unicode-injection/README.md b/src/pentesting-web/unicode-injection/README.md index 77e0013a8..35f2bcb97 100644 --- a/src/pentesting-web/unicode-injection/README.md +++ b/src/pentesting-web/unicode-injection/README.md @@ -4,14 +4,14 @@ ## Introduction -バックエンド/フロントエンドが**奇妙なユニコード文字を受け取ったとき**の動作によって、攻撃者は**保護を回避し、任意の文字を注入する**ことができ、これによりXSSやSQLiなどの**注入脆弱性を悪用する**ことが可能になります。 +バックエンド/フロントエンドが**奇妙なユニコード文字**を受け取ったときの動作によって、攻撃者は**保護を回避し、任意の文字を注入する**ことができ、これによりXSSやSQLiなどの**注入脆弱性を悪用する**ことが可能になります。 ## Unicode Normalization ユニコード正規化は、**ユニコード文字がASCII文字に正規化される**ときに発生します。 -この種の脆弱性の一般的なシナリオは、システムが**チェックした後に**ユーザーの**入力を何らかの形で変更する**ときに発生します。たとえば、いくつかの言語では、**入力を大文字または小文字にする**ための単純な呼び出しが、与えられた入力を正規化し、**ユニコードがASCIIに変換され**て新しい文字が生成される可能性があります。\ -詳細については、次を確認してください: +この種の脆弱性の一般的なシナリオは、システムが**チェックした後に**ユーザーの**入力を何らかの方法で変更する**ときに発生します。たとえば、いくつかの言語では、**入力を大文字または小文字にする**ための単純な呼び出しが、与えられた入力を正規化し、**ユニコードがASCIIに変換され**新しい文字が生成される可能性があります。\ +詳細については、次を確認してください： {{#ref}} unicode-normalization.md @@ -21,17 +21,17 @@ unicode-normalization.md ユニコード文字は通常、**`\u`プレフィックス**で表されます。たとえば、文字`㱋`は`\u3c4b`です（[ここで確認](https://unicode-explorer.com/c/3c4B)）。バックエンドが**`\u`プレフィックスを`%`に変換**すると、結果の文字列は`%3c4b`になり、URLデコードすると**`<4b`**になります。そして、見ての通り、**`<`文字が注入されます**。\ バックエンドが脆弱であれば、この技術を使用して**任意の種類の文字を注入**することができます。\ -必要な文字を見つけるには[https://unicode-explorer.com/](https://unicode-explorer.com/)を確認してください。 +必要な文字を見つけるには、[https://unicode-explorer.com/](https://unicode-explorer.com/)を確認してください。 -この脆弱性は、研究者が発見した脆弱性から来ており、詳細な説明については[https://www.youtube.com/watch?v=aUsAHb0E7Cg](https://www.youtube.com/watch?v=aUsAHb0E7Cg)を確認してください。 +この脆弱性は、研究者が発見した脆弱性に由来します。詳細な説明については、[https://www.youtube.com/watch?v=aUsAHb0E7Cg](https://www.youtube.com/watch?v=aUsAHb0E7Cg)を確認してください。 ## Emoji Injection -バックエンドは、**絵文字を受け取るとき**に何かおかしな動作をします。これは、研究者が`💋img src=x onerror=alert(document.domain)//💛`のようなペイロードでXSSを達成した[**このレポート**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209)で起こったことです。 +バックエンドは、**絵文字を受け取るときに**何かおかしな動作をします。これは、研究者が`💋img src=x onerror=alert(document.domain)//💛`のようなペイロードでXSSを達成した[**このレポート**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209)で起こったことです。 -この場合、サーバーは悪意のある文字を削除した後、**UTF-8文字列をWindows-1252からUTF-8に変換**したためにエラーが発生しました（基本的に入力エンコーディングと変換元エンコーディングが不一致でした）。そのため、適切な<を提供せず、奇妙なユニコードのものが得られました: `‹`\ -``そのため、彼らはこの出力を取り、**再度UTF-8からASCIIに変換しました**。これにより、`‹`が`<`に**正規化**され、これがそのシステムでのエクスプロイトが機能する方法でした。\ -これが起こったことです: +この場合、サーバーが悪意のある文字を削除した後、**UTF-8文字列をWindows-1252からUTF-8に変換した**ことがエラーでした（基本的に入力エンコーディングと変換元エンコーディングが不一致でした）。そのため、適切な<を提供せず、奇妙なユニコードのものが得られました：`‹`\ +``そのため、彼らはこの出力を取り、**今度はUTF-8からASCIIに再変換しました**。これにより、`‹`が`<`に**正規化**され、これがそのシステムでのエクスプロイトが機能する方法でした。\ +これが起こったことです： ```php