# OAuthを利用したアカウント乗っ取り

<details>

<summary><strong>htARTE（HackTricks AWS Red Team Expert）</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>でAWSハッキングをゼロからヒーローまで学ぶ</strong></a><strong>！</strong></summary>

HackTricksをサポートする他の方法：

- **HackTricksで企業を宣伝したい**または**HackTricksをPDFでダウンロードしたい**場合は、[**SUBSCRIPTION PLANS**](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/hacktricks_live)。
- **HackTricks**と**HackTricks Cloud**のGitHubリポジトリにPRを提出して、あなたのハッキングテクニックを共有してください。

</details>

## 基本情報 <a href="#d4a8" id="d4a8"></a>

OAuthにはさまざまなバージョンがあり、基本的な情報は[OAuth 2.0ドキュメント](https://oauth.net/2/)で入手できます。この議論は主に広く使用されている[OAuth 2.0認可コードグラントタイプ](https://oauth.net/2/grant-types/authorization-code/)に焦点を当て、**アプリケーションが別のアプリケーション（認可サーバー）のユーザーアカウントにアクセスしたりアクションを実行するための認可フレームワーク**を提供します。

仮想のウェブサイト _**https://example.com**_ を考えてみましょう。このサイトは**あなたのソーシャルメディア投稿をすべて表示**するように設計されています。これを実現するためにOAuth 2.0が使用されます。_https://example.com_ は**あなたのソーシャルメディア投稿にアクセスする許可**をリクエストします。その結果、同意画面が _https://socialmedia.com_ に表示され、**リクエストされている権限とリクエストを行っている開発者**が示されます。あなたの承認を得ると、_https://example.com_ は**あなたの投稿にアクセスする権限を取得**します。

OAuth 2.0フレームワーク内で以下のコンポーネントを把握することが重要です：

- **リソースオーナー**: **ユーザー/エンティティ**として、あなたがソーシャルメディアアカウントの投稿などのリソースへのアクセスを承認します。
- **リソースサーバー**: `リソースオーナー`の`アクセストークン`を取得した後に認証されたリクエストを処理する**サーバー**、例：**https://socialmedia.com**。
- **クライアントアプリケーション**: `リソースオーナー`から認可を求める**アプリケーション**、例：**https://example.com**。
- **認可サーバー**: `リソースオーナー`の認証に成功し、認可を取得した後に`クライアントアプリケーション`に`アクセストークン`を発行する**サーバー**、例：**https://socialmedia.com**。
- **client\_id**: アプリケーションのための公開された一意の識別子。
- **client\_secret:** アプリケーションと認可サーバーだけが知っている機密キーで、`アクセストークン`を生成するために使用されます。
- **response\_type**: 要求されたトークンの種類を指定する値、例：`code`。
- **scope**: `クライアントアプリケーション`が`リソースオーナー`から要求している**アクセスレベル**。
- **redirect\_uri**: 承認後にユーザーがリダイレクトされる**URL**。通常、事前登録されたリダイレクトURLと一致する必要があります。
- **state**: ユーザーの承認サーバーへのリダイレクトとリダイレクトからのデータの維持に使用されるパラメータ。その一意性は**CSRF保護メカニズム**として重要です。
- **grant\_type**: **グラントタイプと返されるトークンの種類**を示すパラメータ。
- **code**: `認可サーバー`からの認可コードで、`クライアントアプリケーション`が`アクセストークン`を取得するために`client_id`と`client_secret`と一緒に使用します。
- **access\_token**: `リソースオーナー`の代わりに`クライアントアプリケーション`がAPIリクエストに使用する**トークン**。
- **refresh\_token**: ユーザーに再度プロンプトを表示せずに新しい`アクセストークン`を取得するための**トークン**。

### フロー

**実際のOAuthフロー**は次のように進行します：

1. [https://example.com](https://example.com) に移動し、「ソーシャルメディアと統合」ボタンを選択します。
2. サイトはその後、https://example.comのアプリケーションがあなたの投稿にアクセスする許可を求めるために[https://socialmedia.com](https://socialmedia.com)にリクエストを送信します。リクエストは次のように構造化されます：
```
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
```
3. 同意ページが表示されます。

4. 承認した後、ソーシャルメディアは `redirect_uri` に `code` と `state` パラメータを含むレスポンスを送信します。
```
https://example.com?code=uniqueCode123&state=randomString123
```
5. https://example.comは、あなたの代わりに`code`とその`client_id`、`client_secret`を使用してサーバーサイドリクエストを行い、あなたが同意した権限にアクセスできる`access_token`を取得します。
```
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
```
6. 最終的に、プロセスはhttps://example.comが`access_token`を使用してAPIコールを行い、ソーシャルメディアにアクセスします。

## 脆弱性 <a href="#323a" id="323a"></a>

### オープンリダイレクト\_uri <a href="#cc36" id="cc36"></a>

`redirect_uri`はOAuthやOpenIDの実装においてセキュリティ上重要であり、認可後に認可コードなどの機密データが送信される先を指定します。誤って構成されていると、攻撃者がこれらのリクエストを悪意のあるサーバーにリダイレクトさせることが可能になり、アカウント乗っ取りを可能にします。

悪用技術は、認可サーバーの検証ロジックに基づいて異なります。厳密なパス一致から指定されたドメインやサブディレクトリ内の任意のURLを受け入れるまでさまざまです。一般的な悪用方法には、オープンリダイレクト、パストラバーサル、弱い正規表現の悪用、トークン盗難のためのHTMLインジェクションが含まれます。

`redirect_uri`以外にも、`client_uri`、`policy_uri`、`tos_uri`、`initiate_login_uri`などの他のOAuthやOpenIDのパラメーターもリダイレクト攻撃の対象となります。これらのパラメーターはオプションであり、サーバーによってサポートが異なります。

OpenIDサーバーを対象とする場合、ディスカバリーエンドポイント(`**.well-known/openid-configuration**`)はしばしば`registration_endpoint`、`request_uri_parameter_supported`、"`require_request_uri_registration`などの貴重な構成詳細をリストします。これらの詳細は、登録エンドポイントやサーバーのその他の構成の特定に役立ちます。

### リダイレクト実装におけるXSS <a href="#bda5" id="bda5"></a>

このバグバウンティーレポート[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</script><h1>test</h1>
```
### CSRF - `state`パラメータの不適切な処理 <a href="#bda5" id="bda5"></a>

OAuthの実装において、**`state`パラメータ**の誤用や省略は、**Cross-Site Request Forgery (CSRF)** 攻撃のリスクを著しく増加させる可能性があります。この脆弱性は、`state`パラメータが**使用されていない、静的な値として使用されている、または適切に検証されていない**場合に発生し、攻撃者がCSRF保護をバイパスすることを可能にします。

攻撃者は、認可プロセスを傍受して、自分のアカウントを被害者のアカウントとリンクさせることで、**アカウント乗っ取り**の可能性を引き起こすことができます。これは、OAuthが**認証目的**で使用されているアプリケーションにおいて特に重大です。

この脆弱性の実世界の例は、さまざまな**CTFチャレンジ**や**ハッキングプラットフォーム**で文書化されており、その実用的な影響が示されています。この問題は、**Slack**、**Stripe**、**PayPal**などのサードパーティサービスとの統合にも影響を及ぼし、攻撃者が通知や支払いを自分のアカウントにリダイレクトすることができます。

**`state`パラメータ**の適切な処理と検証は、CSRF対策を施し、OAuthフローをセキュリティ強化するために重要です。

### アカウント乗っ取り前 <a href="#ebe4" id="ebe4"></a>

1. **アカウント作成時のメール確認がない場合**: 攻撃者は、被害者のメールを使用して事前にアカウントを作成することができます。後に被害者がサードパーティサービスを使用してログインした場合、アプリケーションは誤ってこのサードパーティアカウントを攻撃者が事前に作成したアカウントにリンクさせ、不正アクセスを引き起こす可能性があります。

2. **緩いOAuthメール確認の悪用**: 攻撃者は、メールを確認しないOAuthサービスを悪用して、自分のサービスに登録し、その後アカウントのメールを被害者のものに変更することができます。この方法は、最初のシナリオと同様に、未承認のアカウントアクセスのリスクをもたらしますが、異なる攻撃ベクトルを介して行われます。

### シークレット情報の開示 <a href="#e177" id="e177"></a>

秘密のOAuthパラメータを特定し、保護することは重要です。**`client_id`**は安全に開示できますが、**`client_secret`**を明らかにすると、重大なリスクが生じます。`client_secret`が漏洩すると、攻撃者はアプリケーションのアイデンティティと信頼を悪用して、ユーザーの`access_token`や個人情報を**盗み出す**ことができます。

アプリケーションが認可コードを`access_token`に交換する処理を誤ってクライアントサイドで処理する場合、一般的な脆弱性が発生します。このミスは`client_secret`の露出を引き起こし、攻撃者がアプリケーションの姿を装って`access_token`を生成することを可能にします。さらに、ソーシャルエンジニアリングを通じて、攻撃者はOAuth認可に追加のスコープを追加することで特権を昇格させ、アプリケーションの信頼されたステータスをさらに悪用することができます。

### クライアントシークレットのブルートフォース

サービスプロバイダのクライアントシークレットを**ブルートフォース**してアカウントを盗むことを試みることができます。\
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 Header leaking Code + State

クライアントが**コードと状態**を取得した後、別のページに移動する際に**Refererヘッダー内に反映されている場合、脆弱性がある**。

### Access Token Stored in Browser History

**ブラウザの履歴を確認し、アクセストークンが保存されているかどうかを確認します**。

### Everlasting Authorization Code

**認証コードは一定の期間だけ有効であり、攻撃者がそれを盗み出して使用できる時間枠を制限する必要があります**。

### Authorization/Refresh Token not bound to client

**認証コードを取得し、異なるクライアントで使用できる場合、他のアカウントを乗っ取ることができます**。

### Happy Paths, XSS, Iframes & Post Messages to leak code & state values

**[この投稿をチェックしてください](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url)**

### AWS Cognito <a href="#bda5" id="bda5"></a>

このバグバウンティレポート: [**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"
}
]
}
```
### 他のアプリのトークンの乱用 <a href="#bda5" id="bda5"></a>

[**この解説**](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 %}

### 2つのリンクとクッキー <a href="#bda5" id="bda5"></a>

[**この解説**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f)によると、被害者に**攻撃者のホストを指すreturnUrl**を持つページを開かせることが可能でした。この情報は**クッキー（RU）に保存され**、**後のステップ**で**プロンプト**が**ユーザーに**その攻撃者のホストへのアクセスを許可するかどうかを**尋ねます**。

このプロンプトをバイパスするために、**returnUrl**を使用してこのRUクッキーを設定する**Oauthフロー**を開始するためのタブを開き、プロンプトが表示される前にそのタブを閉じ、その値がない新しいタブを開くことが可能でした。その後、**プロンプトは攻撃者のホストについて通知しません**が、クッキーはそれに設定されるため、**トークンはリダイレクトで攻撃者のホストに送信**されます。

### SSRFパラメータ <a href="#bda5" id="bda5"></a>

**[この研究をチェック](https://portswigger.net/research/hidden-oauth-attack-vectors)して、この技術の詳細を確認してください。**

OAuthのDynamic Client Registrationは、**Server-Side Request Forgery (SSRF)** 攻撃に対して特に重要なセキュリティ脆弱性のベクトルとして機能します。このエンドポイントは、クライアントアプリケーションに関する詳細情報を受け取るために使用され、悪用される可能性のある機密性の高いURLをOAuthサーバーに提供します。

**主なポイント:**

- **Dynamic Client Registration** は、通常 `/register` にマップされ、`client_name`、`client_secret`、`redirect_uris`、およびPOSTリクエストを介してロゴやJSON Web Key Sets（JWKs）のURLなどの詳細を受け入れます。
- この機能は、**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を取得する場合に悪用される可能性があります。

**悪用戦略:**

- `logo_uri`、`jwks_uri`、または`sector_identifier_uri`などのパラメータに悪意のあるURLを持つ新しいクライアントを登録することで、SSRFをトリガーできます。
- `request_uris`を介した直接的な悪用はホワイトリスト制御によって緩和されるかもしれませんが、事前登録された攻撃者が制御する`request_uri`を提供することで、認可フェーズ中にSSRFを容易にすることができます。

## 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)