hacktricks/pentesting-web/oauth-to-account-takeover.md

# OAuth to Account takeover

<details>

<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Other ways to support HackTricks:

* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>

<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>

{% embed url="https://websec.nl/" %}

## Basic Information <a href="#d4a8" id="d4a8"></a>

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_は**あなたに代わってあなたの投稿にアクセスする**ことができるようになります。

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

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

### Flow

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

1. あなたは[https://example.com](https://example.com)にアクセスし、「ソーシャルメディアと統合」ボタンを選択します。
2. サイトは次に[https://socialmedia.com](https://socialmedia.com)にリクエストを送り、https://example.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. 承認後、Social Mediaは`code`と`state`パラメータを含むレスポンスを`redirect_uri`に送信します。
```
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` を使用して Social Media に API コールを行い、プロセスが完了します。

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

### Open redirect\_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 in redirect implementation <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 - Improper handling of state parameter <a href="#bda5" id="bda5"></a>

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

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

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

CSRFから保護し、OAuthフローを安全にするためには、**`state`パラメータ**の適切な処理と検証が不可欠です。

### Pre Account Takeover <a href="#ebe4" id="ebe4"></a>

1. **アカウント作成時のメール確認なし**: 攻撃者は被害者のメールを使用して事前にアカウントを作成することができます。被害者が後でサードパーティサービスを使用してログインすると、アプリケーションは誤ってこのサードパーティアカウントを攻撃者の事前作成アカウントにリンクする可能性があり、不正アクセスにつながります。
2. **緩いOAuthメール確認の悪用**: 攻撃者は、メールを確認しないOAuthサービスを悪用して、自分のサービスに登録し、その後アカウントのメールを被害者のものに変更することができます。この方法は、異なる攻撃ベクトルを通じて、最初のシナリオと同様に不正なアカウントアクセスのリスクをもたらします。

### Disclosure of Secrets <a href="#e177" id="e177"></a>

秘密のOAuthパラメータを特定し保護することは重要です。**`client_id`**は安全に公開できますが、**`client_secret`**を公開することは重大なリスクを伴います。`client_secret`が漏洩すると、攻撃者はアプリケーションのアイデンティティと信頼を悪用して、ユーザーの**`access_tokens`**やプライベート情報を盗むことができます。

一般的な脆弱性は、アプリケーションが認証`code`を`access_token`に交換する処理をクライアント側で行う誤りから生じます。この誤りにより、`client_secret`が露出し、攻撃者がアプリケーションのふりをして`access_tokens`を生成できるようになります。さらに、ソーシャルエンジニアリングを通じて、攻撃者はOAuth認証に追加のスコープを追加することで特権をエスカレートし、アプリケーションの信頼されたステータスをさらに悪用する可能性があります。

### Client Secret Bruteforce

サービスプロバイダーの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 Header leaking Code + State

クライアントが**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"
}
]
}
```
詳細なAWS Cognitoの悪用方法については、以下を参照してください：

{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}

### 他のアプリのトークンの悪用 <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 %}

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

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

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

### プロンプトインタラクションの回避 <a href="#bda5" id="bda5"></a>

[**このビデオ**](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)で説明されているように、最終URLでコードを提供する場所を示すために**`response_mode`**パラメータを指定することが可能です：

* `response_mode=query` -> コードはGETパラメータ内に提供されます：`?code=2397rf3gu93f`
* `response_mode=fragment` -> コードはURLフラグメントパラメータ内に提供されます：`#code=2397rf3gu93f`
* `response_mode=form_post` -> コードは`code`という名前の入力と値を持つPOSTフォーム内に提供されます
* `response_mode=web_message` -> コードはポストメッセージで送信されます：`window.opener.postMessage({"code": "asdasdasd...`

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

[**この研究をチェック**](https://portswigger.net/research/hidden-oauth-attack-vectors) **この技術の詳細について。**

OAuthの動的クライアント登録は、**Server-Side Request Forgery (SSRF)**攻撃のための重要なベクターとして機能します。このエンドポイントは、クライアントアプリケーションに関する詳細を受け取るため、悪用される可能性のある機密URLを含むことがあります。

**重要なポイント：**

* **動的クライアント登録**は通常`/register`にマッピングされ、`client_name`、`client_secret`、`redirect_uris`、およびロゴやJSON Web Key Sets (JWKs)のURLなどの詳細をPOSTリクエストで受け入れます。
* この機能は**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)

<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>

{% embed url="https://websec.nl/" %}

<details>

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

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/hacktricks\_live)をフォローしてください。
* **ハッキングのトリックを共有するには、** [**HackTricks**](https://github.com/carlospolop/hacktricks)および[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のGitHubリポジトリにPRを提出してください。

</details>