# OAuthを使ったアカウント乗っ取り
AWSハッキングをゼロからヒーローまで学ぶには htARTE (HackTricks AWS Red Team Expert)をチェック！ HackTricksをサポートする他の方法: * **HackTricksにあなたの会社を広告したい**、または**HackTricksをPDFでダウンロードしたい**場合は、[**サブスクリプションプラン**](https://github.com/sponsors/carlospolop)をチェックしてください！ * [**公式PEASS & HackTricksグッズ**](https://peass.creator-spring.com)を入手する * [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を発見し、独占的な[**NFTs**](https://opensea.io/collection/the-peass-family)のコレクションをチェックする * 💬 [**Discordグループ**](https://discord.gg/hRep4RUj7f)に**参加する**か、[**テレグラムグループ**](https://t.me/peass)に参加する、または**Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)を**フォローする**。 * **HackTricks**の[**GitHubリポジトリ**](https://github.com/carlospolop/hacktricks)と[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)にPRを提出して、あなたのハッキングのコツを共有する。
## 基本情報 OAuthにはいくつかの異なるバージョンがあります。基本的な理解を得るために[https://oauth.net/2/](https://oauth.net/2/)を読むことができます。 この記事では、今日最も一般的に遭遇するフローである[OAuth 2.0認可コードグラントタイプ](https://oauth.net/2/grant-types/authorization-code/)に焦点を当てます。本質的に、OAuthは開発者に**別のアプリケーション（認可サーバー）からあなたのアカウントのデータにアクセスしたり、特定のアクションを実行するための認可メカニズム**を提供します。 例えば、_**https://yourtweetreader.com**_ が**あなたが今までに送った全てのツイートを表示する**機能を持っているとしましょう。これにはOAuth 2.0が導入されています。_https://yourtweetreader.com_ は**あなたのツイートにアクセスするためにTwitterアプリケーションの認可を求めます**。_https://twitter.com_ に同意ページが表示され、**どの権限が要求されているか**、そしてそれを要求している開発者が誰かが表示されます。あなたが要求を認可すると、_https://yourtweetreader.com_ は**あなたに代わってあなたのツイートにアクセスすることができる**ようになります。 OAuth 2.0のコンテキストで理解する重要な要素: * **リソースオーナー**: `リソースオーナー`は、Twitterアカウントのツイートなど、保護されたリソースへのアクセスを許可する**ユーザー/エンティティ**です。この例では、これは**あなた**です。 * **リソースサーバー**: `リソースサーバー`は、アプリケーションが`アクセストークン`を取得した後に認証されたリクエストを処理する**サーバー**です。この例では、これは**https://twitter.com**です。 * **クライアントアプリケーション**: `クライアントアプリケーション`は、`リソースオーナー`から認可を要求する**アプリケーション**です。この例では、これは**https://yourtweetreader.com**です。 * **認可サーバー**: `認可サーバー`は、`リソースオーナー`を正常に認証し、認可を取得した後に`クライアントアプリケーション`に`アクセストークン`を発行する**サーバー**です。上記の例では、これは**https://twitter.com**です。 * **client\_id**: `client_id`は**アプリケーションの識別子**です。これは公開されている、**非秘密**の一意の識別子です。 * **client\_secret:** `client_secret`は**アプリケーションと認可サーバーのみが知っている秘密**です。これは`アクセストークン`を生成するために使用されます。 * **response\_type**: `response_type`は、要求されている**トークンのタイプ**を詳細に説明する値です。例えば`code`などです。 * **scope**: `scope`は`クライアントアプリケーション`が`リソースオーナー`から要求している**アクセスレベル**です。 * **redirect\_uri**: `redirect_uri`は、認可が完了した後にユーザーがリダイレクトされる**URL**です。これは通常、以前にサービスに登録したリダイレクトURLと一致する必要があります。 * **state**: `state`パラメータは、ユーザーが認可サーバーにリダイレクトされてから再び戻ってくる間にデータを**保持することができます**。これはリクエストごとに一意またはランダムな値を含む場合、**CSRF保護メカニズム**として機能するため、一意の値であることが重要です。 * **grant\_type**: `grant_type`パラメータは、**グラントタイプが何であるか**、どのトークンが返されるかを説明します。 * **code**: この`code`は、このリクエストのクエリ文字列パラメータ「code」にある`認可サーバー`から受け取った認可コードです。このコードは`クライアントアプリケーション`が`アクセストークン`を取得するために`client_id`と`client_secret`と共に使用されます。 * **access\_token**: `access_token`は、`クライアントアプリケーション`が`リソースオーナー`を代表してAPIリクエストを行うために使用する**トークン**です。 * **refresh\_token**: `refresh_token`は、アプリケーションがユーザーにプロンプトを表示せずに新しい`アクセストークン`を取得することを可能にします。 ### 実際の例 これらを全てまとめると、**実際のOAuthフローは以下のようになります**: 1. [https://yourtweetreader.com](https://yourtweetreader.com)を訪れ、「Twitterと連携する」ボタンをクリックします。 2. [https://yourtweetreader.com](https://yourtweetreader.com)は[https://twitter.com](https://twitter.com)にリクエストを送り、リソースオーナーであるあなたに、https://yourtweetreader.comのTwitterアプリケーションがあなたのツイートにアクセスすることを認可するよう求めます。リクエストは次のようになります： ``` https://twitter.com/auth ?response_type=code &client_id=yourtweetreader_clientId &redirect_uri=https%3A%2F%2Fyourtweetreader.com%2Fcallback &scope=readTweets &state=kasodk9d1jd992k9klaskdh123 ``` 3\. 同意ページが表示されます： ![](https://miro.medium.com/max/1215/1\*y66EY3Fn2qn-NPI9nhZC7A.png) 4\. 同意すると、Twitterは`redirect_uri`に`code`と`state`パラメータを含むリクエストを送り返します： ``` https://yourtweetreader.com?code=asd91j3jd91j92j1j9d1&state=kasodk9d1jd992k9klaskdh123 ``` 5\. [https://yourtweetreader.com](https://yourtweetreader.com) はその `code` を取得し、アプリケーションの `client_id` と `client_secret` を使用して、サーバーから `access_token` を取得するリクエストを行います。これにより、あなたが同意した権限にアクセスできるようになります： ``` POST /oauth/access_token Host: twitter.com ...{"client_id": "yourtweetreader_clientId", "client_secret": "yourtweetreader_clientSecret", "code": "asd91j3jd91j92j1j9d1", "grant_type": "authorization_code"} ``` 6\. 最終的に、フローが完了し、[https://yourtweetreader.com](https://yourtweetreader.com) はあなたの `access_token` を使って Twitter の API を呼び出し、あなたのツイートにアクセスします。 ## バグバウンティの発見 さて、興味深い部分です！OAuth 実装には多くの問題が発生する可能性があり、ここでは私が頻繁に見かけるバグの異なるカテゴリーを紹介します： ### 弱い redirect\_uri 設定 `redirect_uri` は非常に重要です。なぜなら、**機密データである `code` が認証後にこの URL に追加されるからです**。もし `redirect_uri` が **攻撃者が制御するサーバー** にリダイレクトされる場合、攻撃者は `code` を自分で使用し、被害者のデータにアクセスすることで、**被害者のアカウントを乗っ取る** 可能性があります。 この脆弱性をどのように悪用するかは、認証サーバーによって異なります。**一部のサーバーは** クライアントアプリケーションで指定された **`redirect_uri` パスと全く同じもののみを受け入れますが**、他のサーバーは `redirect_uri` の同じドメインやサブディレクトリ内のものなら **何でも受け入れます**。 サーバーが扱うロジックによっては、`redirect_uri` をバイパスするためのいくつかのテクニックがあります。`redirect_uri` が [https://yourtweetreader.com](https://yourtweetreader.com)/callback の場合、これには以下が含まれます： * オープンリダイレクト: [`https://yourtweetreader.com`](https://yourtweetreader.com)`/callback?redirectUrl=https://evil.com` * パストラバーサル: `https://yourtweetreader.com/callback/../redirect?url=https://evil.com` * 弱い `redirect_uri` 正規表現: `https://yourtweetreader.com.evil.com` * HTML インジェクションと referer ヘッダーを介したトークンの盗難: `https://yourtweetreader.com/callback/home/attackerimg.jpg` オープンリダイレクトに脆弱な**他のパラメーター**には以下があります： * **client\_uri** - クライアントアプリケーションのホームページの URL * **policy\_uri** - エンドユーザーが自分のプロファイルデータの使用方法について読むことができるように、クライアントアプリケーションが提供する URL。 * **tos\_uri** - エンドユーザーが利用規約について読むことができるように、クライアントが提供する URL。 * **initiate\_login\_uri** - 第三者が RP によるログインを開始するために使用できる https スキームの URI。クライアント側のリダイレクションにも使用されるべきです。 これらのパラメーターは **OAuth および OpenID** の仕様によると **オプションであり**、特定のサーバーでは常にサポートされているわけではないので、サーバーでどのパラメーターがサポートされているかを特定することが常に価値があります。 OpenID サーバーを対象とする場合、\*\*`.well-known/openid-configuration`\*\* の発見エンドポイントには、"_registration\_endpoint_"、"_request\_uri\_parameter\_supported_"、"_require\_request\_uri\_registration_" などのパラメーターが含まれることがあります。これらは、登録エンドポイントや他のサーバー構成値を見つけるのに役立ちます。 ### リダイレクト実装における XSS このバグバウンティレポート [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html) で述べられているように、ユーザーが認証した後にサーバーのレスポンスでリダイレクト **URL が反映されている** 可能性があり、**XSS に脆弱** です。テストする可能性のあるペイロード： ``` https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard

test

``` ### CSRF - 状態パラメータの不適切な取り扱い 非常に多くの場合、**`state` パラメータは完全に省略されているか、間違った方法で使用されています**。もし状態パラメータが **存在しない**、**または変化しない静的な値**であれば、OAuthフローは非常に高い確率で **CSRFに対して脆弱** になります。時には、`state` パラメータが存在しても、**アプリケーションがパラメータの検証を全く行わない**ことがあり、攻撃が成功する可能性があります。この脆弱性を利用する方法は、自分のアカウントで認証プロセスを行い、認証直後に一時停止することです。すると、次のようなリクエストに遭遇します： ``` https://yourtweetreader.com?code=asd91j3jd91j92j1j9d1 ``` このリクエストを受け取った後、これらのコードは通常一度限りの使用なので、**リクエストをドロップすることができます**。その後、このURLを**ログイン済みのユーザーに送信し、あなたのアカウントをそのユーザーのアカウントに追加することができます**。最初は、単にあなたのアカウントを被害者のアカウントに追加しているだけなので、それほど敏感に聞こえないかもしれません。しかし、多くのOAuth実装はサインイン目的で使用されているため、ログインに使用されるGoogleアカウントを追加できれば、クリック一つで**アカウント乗っ取り**を実行し、Googleアカウントでログインすることで被害者のアカウントにアクセスできる可能性があります。 この件についての**例**は、この[**CTF writeup**](https://github.com/gr455/ctf-writeups/blob/master/hacktivity20/notes\_surfer.md)や**HTB box called Oouch**で見ることができます。 また、`state`パラメータが追加のリダイレクト値として使用されることも何度か見かけました。アプリケーションは初期リダイレクトに`redirect_uri`を使用しますが、その後、クエリパラメータ内に`code`を含むか、refererヘッダーを参照する可能性のある2回目のリダイレクトに`state`パラメータを使用します。 重要な点は、これがログインやアカウント乗っ取りタイプの状況にのみ適用されるわけではないということです。私が見た設定ミスには以下のようなものがあります： * Slackの統合により、攻撃者がすべての通知/メッセージの受信者として自分のSlackアカウントを追加できる * Stripeの統合により、攻撃者が支払い情報を上書きし、被害者の顧客からの支払いを受け取ることができる * PayPalの統合により、攻撃者が自分のPayPalアカウントを被害者のアカウントに追加でき、攻撃者のPayPalにお金が入金される ### アカウント乗っ取り前 私がよく見る問題の1つは、アプリケーションが「Xでサインイン」を許可する一方で、ユーザー名/パスワードも使用できる場合です。これには2つの異なる攻撃方法があります： 1. アプリケーションが**アカウント作成時にメール確認を要求しない場合**、被害者が登録する前に被害者のメールアドレスと攻撃者のパスワードを使用してアカウントを**作成してみてください**。その後、**被害者**がGoogleなどの**第三者を使用して**登録またはサインインしようとすると、アプリケーションがルックアップを行い、そのメールアドレスがすでに登録されていることを確認し、**攻撃者が作成したアカウントに被害者のGoogleアカウントをリンクする**可能性があります。これは、攻撃者が被害者が登録する前にアカウントを作成した場合に、被害者のアカウントにアクセスできる「**アカウント乗っ取り前**」の状況です。 2. **OAuthアプリがメール確認を要求しない場合**、そのOAuthアプリでサインアップし、その後、**被害者のメールアドレス**にメールアドレスを変更してみてください。上記と同じ問題が存在する可能性がありますが、逆の方向から攻撃して、アカウント乗っ取りのために被害者のアカウントにアクセスします。 ### シークレットの開示 OAuthパラメータの中で**どれが秘密であるか**を認識し、それらを保護することが非常に重要です。例えば、`client_id`の漏洩は完全に問題なく、必要ですが、**`client_secret`の漏洩は危険です**。これが漏洩すると、**攻撃者**は信頼されたクライアントアプリケーションの信頼とアイデンティティを悪用して、統合されたアカウントのユーザー`access_tokens`やプライベート情報/アクセスを盗む可能性があります。先ほどの例に戻ると、私が見た問題の1つは、このステップをサーバーではなくクライアントから実行することです： _5._ [_https://yourtweetreader.com_](https://yourtweetreader.com) _はその`code`を取得し、アプリケーションの`client_id`と`client_secret`を使用して、あなたに代わって`access_token`を取得するためにサーバーからリクエストを行います。これにより、あなたが同意した権限にアクセスできます。_ **これがクライアントから行われる場合、`client_secret`が漏洩し、ユーザーはアプリケーションを代表して`access_tokens`を生成することができます**。いくつかのソーシャルエンジニアリングを行うことで、OAuth認証にさらにスコープを追加することもでき、信頼されたクライアントアプリケーションからのリクエストとしてすべてが正当に見えます。 ### クライアントシークレットのブルートフォース サービスプロバイダの`client_secret`をアイデンティティプロバイダとともに**ブルートフォースする**ことを試みることができます。これにより、アカウントを盗むことを試みることができます。 BFへのリクエストは以下のようになるかもしれません： ``` POST /token HTTP/1.1 content-type: application/x-www-form-urlencoded host: 10.10.10.10:3000 content-length: 135 Connection: close code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce] ``` ### Referer ヘッダーによる Code + State の漏洩 クライアントが **code と state** を持っている場合、別のページに移動する際にそれが **Referer ヘッダー内で反映されている** と、脆弱性があると言えます。 ### ブラウザ履歴に保存されたアクセストークン **ブラウザの履歴を確認し、アクセストークンが保存されているかをチェックしてください**。 ### 永続的な認可コード **認可コードは一定時間のみ有効であるべきです。攻撃者が盗み、使用する時間窓を限定するためです**。 ### クライアントに紐づいていない認可/リフレッシュトークン 異なるクライアントで **認可コードを取得し、使用できる場合、他のアカウントの乗っ取りが可能です**。 ### Happy Paths, XSS, Iframes & Post Messages を利用した code & state 値の漏洩 ### AWS Cognito このバグバウンティレポート: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) では、**AWS Cognito** がユーザーに返す **トークン** が、ユーザーデータを上書きするのに **十分な権限を持っている** 可能性があることがわかります。したがって、異なるユーザーのメールアドレスに **ユーザーのメールを変更できる** 場合、他のアカウントの **乗っ取り** が可能になるかもしれません。 ```bash # Read info of the user aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...] # Change email address aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com { "CodeDeliveryDetailsList": [ { "Destination": "i***@f***.com", "DeliveryMedium": "EMAIL", "AttributeName": "email" } ] } ``` AWS cognitoの悪用方法についての詳細は、以下をチェックしてください： {% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %} ### 他のアプリのトークンを悪用する [**このライトアップで述べられているように**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts)、**トークン**を受け取ることを期待しているOAuthフローは、そのトークンがアプリに属しているかどうかをチェックしていない場合、脆弱性を持つ可能性があります。 これは、**攻撃者**がOAuthをサポートする**アプリケーションを作成し、Facebookでログイン**する（例えば）ことができるためです。その後、被害者が**攻撃者のアプリケーションでFacebookでログイン**すると、攻撃者は**自分のアプリケーションに与えられたユーザーのOAuthトークンを取得し、被害者のOAuthアプリケーションで被害者のユーザートークンを使用してログインすることができます**。 {% hint style="danger" %} したがって、攻撃者がユーザーに自分のOAuthアプリケーションを使用させることに成功した場合、トークンを期待していて、そのトークンが自分たちのアプリIDに付与されたものかどうかをチェックしていないアプリケーションで、被害者のアカウントを乗っ取ることができます。 {% endhint %} ### 二つのリンクとクッキー [**このライトアップによると**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f)、攻撃者のホストを指す**returnUrl**を含むページを被害者に開かせることが可能でした。この情報は**クッキー（RU）に保存され**、**後のステップ**で**プロンプト**が**ユーザー**にその攻撃者のホストへのアクセスを許可するかどうかを**尋ねます**。 このプロンプトをバイパスするために、**returnUrl**を使用してこのRUクッキーを設定する**Oauthフロー**を開始するタブを開き、プロンプトが表示される前にタブを閉じ、その値なしで新しいタブを開くことが可能でした。その結果、**プロンプトは攻撃者のホストについて通知しません**が、クッキーはそれに設定されているため、**トークンはリダイレクションで攻撃者のホストに送信されます**。 ### SSRFsパラメータ 見逃してしまうかもしれない隠されたURLの一つは、**Dynamic Client Registrationエンドポイント**です。ユーザーを正常に認証するために、OAuthサーバーはクライアントアプリケーションに関する詳細を知る必要があります。例えば"client\_name"、"client\_secret"、"redirect\_uris"などです。これらの詳細はローカル設定を介して提供されることもありますが、OAuth認証サーバーには**特別な登録エンドポイント**も存在することがあります。このエンドポイントは通常"/register"にマッピングされ、以下の形式のPOSTリクエストを受け付けます： ```json POST /connect/register HTTP/1.1 Content-Type: application/json Host: server.example.com Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ... { "application_type": "web", "redirect_uris": ["https://client.example.org/callback"], "client_name": "My Example", "logo_uri": "https://client.example.org/logo.png", "subject_type": "pairwise", "sector_identifier_uri": "https://example.org/rdrct_uris.json", "token_endpoint_auth_method": "client_secret_basic", "jwks_uri": "https://client.example.org/public_keys.jwks", "contacts": ["ve7jtb@example.org"], "request_uris": ["https://client.example.org/rf.txt"] } ``` このリクエストで定義されるパラメーターには、OAuth用の[RFC7591](https://tools.ietf.org/html/rfc7591)と[Openid Connect Registration 1.0](https://openid.net/specs/openid-connect-registration-1_0.html#rfc.section.3.1)の2つの仕様があります。 ここで見ることができるように、これらの値の多くはURL参照を介して渡され、[Server Side Request Forgery](https://portswigger.net/web-security/ssrf)の潜在的なターゲットのように見えます。同時に、私たちがテストしたほとんどのサーバーは、登録リクエストを受け取ったときにこれらのURLをすぐに解決しません。代わりに、**これらのパラメーターを保存し、OAuth認証フロー中に後で使用します**。言い換えれば、これはより二次的なSSRFであり、ブラックボックス検出を困難にします。 以下のパラメーターはSSRF攻撃に特に興味深いです： * **logo\_uri** - クライアントアプリケーションの**ロゴを参照するURL**。**クライアントを登録した後**、新しい"client\_id"を使用してOAuth認証エンドポイント("/authorize")を呼び出すことができます。ログイン後、サーバーはリクエストを承認するように求め、**"logo\_uri"から画像を表示する可能性があります**。**サーバーが自身で画像を取得する場合**、SSRFはこのステップでトリガーされるはずです。代わりに、サーバーは**クライアント側の""タグ**を介してロゴを含めるかもしれません。これはSSRFにはつながりませんが、URLがエスケープされていない場合は**XSSにつながる可能性があります**。 * **jwks\_uri** - クライアントのJSON Web Key Set \[JWK]ドキュメントのURL。このキーセットは、JWTをクライアント認証に使用するときにトークンエンドポイントへの署名付きリクエストを検証するためにサーバー上で必要です \[RFC7523]。このパラメーターでSSRFをテストするために、**悪意のある"jwks\_uri"を持つ新しいクライアントアプリケーションを登録し**、**任意のユーザーの認証コードを取得するために認証プロセスを実行し、次のボディを持つ"/token"エンドポイントをフェッチします**： `POST /oauth/token HTTP/1.1`\ `...`\ \`\`\ `grant_type=authorization_code&code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion=eyJhbGci...` 脆弱であれば、**サーバーは提供された"jwks\_uri"へのサーバー間HTTPリクエストを実行するはずです**。なぜなら、リクエスト内の"client\_assertion"パラメーターの妥当性をチェックするためにこのキーが必要だからです。これはおそらく**ブラインドSSRFの脆弱性になるでしょう**。サーバーは適切なJSONレスポンスを期待しています。 * **sector\_identifier\_uri** - **redirect\_uri値のJSON配列を参照するファイルのURL**です。サポートされている場合、サーバーは**動的登録リクエストを提出するとすぐにこの値をフェッチする可能性があります**。すぐにフェッチされない場合は、このクライアントに対してサーバーで認証を実行してみてください。認証フローを完了するためにredirect\_urisを知る必要があるため、これによりサーバーは悪意のあるsector\_identifier\_uriへのリクエストを強制されます。 * **request\_uris** - このクライアントの**許可されたrequest\_urisの配列**です。"request\_uri"パラメーターは、リクエスト情報を含むJWTを含むURLを提供するために認証エンドポイントでサポートされている可能性があります（[https://openid.net/specs/openid-connect-core-1\_0.html#rfc.section.6.2](https://openid.net/specs/openid-connect-core-1_0.html#rfc.section.6.2)を参照）。 動的クライアント登録が有効でない場合、または認証が必要な場合でも、単に"request\_uri"を使用して認証エンドポイントでSSRFを実行しようとすることができます：\\ `GET /authorize?response_type=code%20id_token&client_id=sclient1&request_uri=https://ybd1rc7ylpbqzygoahtjh6v0frlh96.burpcollaborator.net/request.jwt` 注：このパラメーターを"redirect\_uri"と混同しないでください。"redirect\_uri"は認証後のリダイレクトに使用されますが、**"request\_uri"は認証プロセスの開始時にサーバーによってフェッチされます**。 同時に、私たちが見た多くのサーバーは任意の"request\_uri"値を許可しません：事前にクライアント登録プロセス中に登録されたホワイトリストされたURLのみを許可します。そのため、事前に"request\_uris": "https://ybd1rc7ylpbqzygoahtjh6v0frlh96.burpcollaborator.net/request.jwt"を提供する必要があります。 ## OAuthプロバイダーのレースコンディション テストしているプラットフォームがOAuthプロバイダーである場合は、[**レースコンディションの可能性をテストするためにこれを読んでください**](race-condition.md)。 ## 参考文献 * [**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)
htARTE (HackTricks AWS Red Team Expert)でAWSハッキングをゼロからヒーローまで学ぶ HackTricksをサポートする他の方法： * **HackTricksに広告を掲載したい**、または**HackTricksをPDFでダウンロードしたい**場合は、[**サブスクリプションプラン**](https://github.com/sponsors/carlospolop)をチェックしてください！ * [**公式PEASS & HackTricksグッズ**](https://peass.creator-spring.com)を入手してください。 * [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を発見してください。私たちの独占的な[**NFTs**](https://opensea.io/collection/the-peass-family)のコレクションです。 * 💬 [**Discordグループ**](https://discord.gg/hRep4RUj7f)に**参加するか**、[**telegramグループ**](https://t.me/peass)に参加するか、**Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)で**フォローしてください**。 * **HackTricks**と[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のgithubリポジトリにPRを提出して、あなたのハッキングのコツを共有してください。