Translated ['pentesting-web/oauth-to-account-takeover.md'] to kr

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

@@ -1,16 +1,16 @@
-# OAuth를 통한 계정 탈취
+# OAuth to Account takeover
 
 <details>
 
-<summary><strong>htARTE (HackTricks AWS Red Team Expert)</strong>에서 <strong>AWS 해킹을 처음부터 전문가까지 배우세요</strong>!</summary>
+<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>
 
-HackTricks를 지원하는 다른 방법:
+Other ways to support 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을 제출하세요.
+* 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>
 
@@ -18,35 +18,35 @@ HackTricks를 지원하는 다른 방법:
 
 {% embed url="https://websec.nl/" %}
 
-## 기본 정보 <a href="#d4a8" id="d4a8"></a>
+## Basic Information <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/)에 중점을 두며, **응용 프로그램이 다른 응용 프로그램의 사용자 계정에 액세스하거나 작업을 수행할 수 있는 인가 프레임워크**를 제공합니다(인가 서버).
+OAuth offers various versions, with foundational insights accessible at [OAuth 2.0 documentation](https://oauth.net/2/). This discussion primarily centers on the widely used [OAuth 2.0 authorization code grant type](https://oauth.net/2/grant-types/authorization-code/), providing an **authorization framework that enables an application to access or perform actions on a user's account in another application** (the authorization server).
 
-가정적인 웹사이트 _**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 프레임워크 내에서 다음 구성 요소를 이해하는 것이 중요합니다:
 
-- **리소스 소유자**: **사용자/개체**로서 귀하의 리소스에 대한 액세스를 승인합니다(예: 소셜 미디어 계정 게시물).
-- **리소스 서버**: `액세스 토큰`을 확보한 후 `리소스 소유자`를 대신하여 인증된 요청을 처리하는 **서버**, 예: **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**: 응용 프로그램이 사용자에게 다시 프롬프팅하지 않고 새 `액세스 토큰`을 얻을 수 있게 합니다.
+* **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`을 얻기 위해 사용됨.
+* **access\_token**: `client application`이 `resource owner`를 대신하여 API 요청에 사용하는 **토큰**.
+* **refresh\_token**: 애플리케이션이 **사용자를 다시 프롬프트하지 않고 새로운 `access_token`을 얻을 수 있게 함**.
 
-### 흐름
+### Flow
 
 **실제 OAuth 흐름**은 다음과 같이 진행됩니다:
 
-1. [https://example.com](https://example.com)으로 이동하여 "소셜 미디어와 통합" 버튼을 선택합니다.
-2. 해당 사이트는 귀하의 게시물에 액세스할 수 있도록 https://example.com의 응용 프로그램에 권한을 부여하도록 [https://socialmedia.com](https://socialmedia.com)에 요청을 보냅니다. 요청은 다음과 같이 구성됩니다:
+1. 사용자는 [https://example.com](https://example.com)으로 이동하여 “소셜 미디어와 통합” 버튼을 선택합니다.
+2. 사이트는 [https://socialmedia.com](https://socialmedia.com)으로 요청을 보내어 https://example.com의 애플리케이션이 사용자의 게시물에 접근할 수 있도록 승인 요청을 합니다. 요청은 다음과 같이 구성됩니다:
 ```
 https://socialmedia.com/auth
 ?response_type=code
@@ -55,64 +55,62 @@ https://socialmedia.com/auth
 &scope=readPosts
 &state=randomString123
 ```
-3. 당신은 동의 페이지가 표시됩니다.
-
-4. 당신의 승인 이후, 소셜 미디어는 `redirect_uri`로 `code`와 `state` 매개변수를 포함한 응답을 보냅니다:
+3. 그러면 동의 페이지가 표시됩니다.
+4. 승인을 완료하면, Social Media는 `code`와 `state` 매개변수를 포함한 응답을 `redirect_uri`로 보냅니다:
 ```
 https://example.com?code=uniqueCode123&state=randomString123
 ```
-5. https://example.com은 `code`를 사용하여 당신을 대신하여 `access_token`을 얻기 위해 서버 측 요청을 만듭니다. 이 과정에서 `client_id`와 `client_secret`가 함께 사용됩니다. 이를 통해 당신이 동의한 권한에 액세스할 수 있게 됩니다:
+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 호출을 수행하여 소셜 미디어에 액세스합니다.
+6. Finally, the process concludes as https://example.com employs your `access_token` to make an API call to Social Media to access
 
-## 취약점 <a href="#323a" id="323a"></a>
+## Vulnerabilities <a href="#id-323a" id="id-323a"></a>
 
 ### Open redirect\_uri <a href="#cc36" id="cc36"></a>
 
-`redirect_uri`는 OAuth 및 OpenID 구현에서 보안에 중요한 역할을 합니다. 인가 후에 인증 코드와 같은 민감한 데이터가 전송되는 위치를 지정하기 때문입니다. 잘못 구성된 경우, 공격자가 이러한 요청을 악의적인 서버로 리디렉션하여 계정 탈취를 가능케 할 수 있습니다.
+`redirect_uri`는 OAuth 및 OpenID 구현에서 보안에 매우 중요합니다. 이는 승인 후에 인증 코드와 같은 민감한 데이터가 전송되는 위치를 지시합니다. 잘못 구성되면 공격자가 이러한 요청을 악성 서버로 리디렉션하여 계정 탈취를 가능하게 할 수 있습니다.
 
-악용 기술은 인가 서버의 유효성 검사 논리에 따라 다양합니다. 엄격한 경로 일치부터 지정된 도메인이나 하위 디렉토리 내의 모든 URL을 허용하는 것까지 다양합니다. 일반적인 악용 방법으로는 오픈 리다이렉트, 경로 순회, 약한 정규식 악용 및 토큰 도난을 위한 HTML 삽입이 있습니다.
+공격 기법은 인증 서버의 검증 논리에 따라 다릅니다. 엄격한 경로 일치에서부터 지정된 도메인 또는 하위 디렉토리 내의 모든 URL을 수락하는 것까지 다양합니다. 일반적인 공격 방법에는 열린 리디렉션, 경로 탐색, 약한 정규 표현식 악용, 토큰 도난을 위한 HTML 삽입 등이 포함됩니다.
 
-`redirect_uri` 외에도 `client_uri`, `policy_uri`, `tos_uri`, `initiate_login_uri`와 같은 다른 OAuth 및 OpenID 매개변수도 리디렉션 공격에 취약할 수 있습니다. 이러한 매개변수는 선택 사항이며 지원 범위는 서버마다 다릅니다.
+`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`과 같은 가치 있는 구성 세부 정보를 나열합니다. 이러한 세부 정보는 등록 엔드포인트 및 서버의 기타 구성 세부 정보를 식별하는 데 도움이 될 수 있습니다.
+OpenID 서버를 대상으로 하는 경우, 발견 엔드포인트(`**.well-known/openid-configuration**`)는 `registration_endpoint`, `request_uri_parameter_supported`, "`require_request_uri_registration`와 같은 유용한 구성 세부 정보를 나열하는 경우가 많습니다. 이러한 세부 정보는 등록 엔드포인트 및 서버의 다른 구성 세부 정보를 식별하는 데 도움이 될 수 있습니다.
 
-### 리디렉트 구현에서의 XSS <a href="#bda5" id="bda5"></a>
+### 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://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 - 상태 매개변수의 부적절한 처리 <a href="#bda5" id="bda5"></a>
+### CSRF - Improper handling of state parameter <a href="#bda5" id="bda5"></a>
 
-OAuth 구현에서 **`state` 매개변수**의 오용 또는 누락은 **Cross-Site Request Forgery (CSRF)** 공격의 위험을 크게 증가시킬 수 있습니다. 이 취약점은 `state` 매개변수가 **사용되지 않거나 정적 값으로 사용되거나 적절하게 유효성이 검사되지 않을 때** 발생하며, 이로 인해 공격자가 CSRF 보호를 우회할 수 있습니다.
+OAuth 구현에서 **`state` parameter**의 오용 또는 생략은 **Cross-Site Request Forgery (CSRF)** 공격의 위험을 크게 증가시킬 수 있습니다. 이 취약점은 `state` parameter가 **사용되지 않거나, 정적 값으로 사용되거나, 제대로 검증되지 않을 때** 발생하여 공격자가 CSRF 보호를 우회할 수 있게 합니다.
 
-공격자는 권한 부여 프로세스를 가로채어 자신의 계정을 피해자의 계정과 연결하여 **계정 탈취**로 이어질 수 있습니다. 이는 특히 OAuth가 **인증 목적으로 사용되는 애플리케이션**에서 매우 중요합니다.
+공격자는 이를 악용하여 인증 과정을 가로채어 자신의 계정을 피해자의 계정과 연결시킬 수 있으며, 이는 잠재적인 **계정 탈취**로 이어질 수 있습니다. 이는 OAuth가 **인증 목적으로** 사용되는 애플리케이션에서 특히 중요합니다.
 
-이러한 취약점의 실제 사례는 다양한 **CTF 챌린지** 및 **해킹 플랫폼**에서 문서화되어 있으며, 실제 적용 가능성을 강조합니다. 이 문제는 **Slack**, **Stripe**, **PayPal**과 같은 제3자 서비스와의 통합에도 영향을 미치며, 공격자는 알림이나 결제를 자신의 계정으로 리디렉션할 수 있습니다.
+이 취약점의 실제 사례는 다양한 **CTF 챌린지**와 **해킹 플랫폼**에서 문서화되어 있으며, 그 실질적인 영향을 강조하고 있습니다. 이 문제는 **Slack**, **Stripe**, **PayPal**과 같은 타사 서비스와의 통합에도 확장되어, 공격자가 알림이나 결제를 자신의 계정으로 리디렉션할 수 있습니다.
 
-**`state` 매개변수**의 적절한 처리 및 유효성 검사는 CSRF에 대한 보호 및 OAuth 흐름의 보안을 확보하는 데 중요합니다.
+**`state` parameter**의 적절한 처리와 검증은 CSRF를 방지하고 OAuth 흐름을 보호하는 데 중요합니다.
 
-### 계정 탈취 전 <a href="#ebe4" id="ebe4"></a>
+### Pre Account Takeover <a href="#ebe4" id="ebe4"></a>
 
-1. **계정 생성 시 이메일 확인 없음**: 공격자는 피해자의 이메일을 사용하여 미리 계정을 생성할 수 있습니다. 피해자가 나중에 로그인을 위해 제3자 서비스를 사용하는 경우, 애플리케이션이 이 제3자 계정을 공격자가 미리 생성한 계정에 부적절하게 연결할 수 있어 무단 액세스로 이어질 수 있습니다.
+1. **계정 생성 시 이메일 검증 없음**: 공격자는 피해자의 이메일을 사용하여 사전에 계정을 생성할 수 있습니다. 피해자가 나중에 타사 서비스를 사용하여 로그인하면 애플리케이션이 이 타사 계정을 공격자가 사전에 생성한 계정과 연결하여 무단 접근이 발생할 수 있습니다.
+2. **느슨한 OAuth 이메일 검증 악용**: 공격자는 이메일을 검증하지 않는 OAuth 서비스를 악용하여 자신의 서비스에 등록한 후 계정 이메일을 피해자의 이메일로 변경할 수 있습니다. 이 방법은 첫 번째 시나리오와 유사하지만 다른 공격 벡터를 통해 무단 계정 접근 위험을 초래합니다.
 
-2. **느슨한 OAuth 이메일 확인 악용**: 공격자는 이메일을 확인하지 않는 OAuth 서비스를 악용하여 해당 서비스에 등록한 후 계정 이메일을 피해자의 이메일로 변경할 수 있습니다. 이 방법은 첫 번째 시나리오와 유사하게 무단 계정 액세스의 위험을 초래하지만 다른 공격 벡터를 통해 발생합니다.
+### Disclosure of Secrets <a href="#e177" id="e177"></a>
 
-### 비밀 정보 노출 <a href="#e177" id="e177"></a>
+비밀 OAuth 파라미터를 식별하고 보호하는 것이 중요합니다. **`client_id`**는 안전하게 공개될 수 있지만, **`client_secret`**을 공개하는 것은 큰 위험을 초래합니다. `client_secret`이 유출되면 공격자는 애플리케이션의 신원과 신뢰를 악용하여 **사용자 `access_tokens`** 및 개인 정보를 탈취할 수 있습니다.
 
-비밀 OAuth 매개변수를 식별하고 보호하는 것이 중요합니다. **`client_id`**는 안전하게 공개할 수 있지만 **`client_secret`**를 공개하면 중대한 위험을 초래할 수 있습니다. `client_secret`가 노출되면 공격자가 애플리케이션의 신원과 신뢰를 악용하여 사용자 `access_token` 및 개인 정보를 **도용**할 수 있습니다.
+일반적인 취약점은 애플리케이션이 인증 `code`를 `access_token`으로 교환하는 과정을 클라이언트 측에서 처리할 때 발생합니다. 이 실수는 `client_secret`의 노출로 이어져 공격자가 애플리케이션을 가장하여 `access_tokens`를 생성할 수 있게 합니다. 또한, 사회 공학을 통해 공격자는 OAuth 인증에 추가 범위를 추가하여 애플리케이션의 신뢰 상태를 더욱 악용할 수 있습니다.
 
-일반적인 취약점은 애플리케이션이 권한 `code`를 `access_token`으로 교환하는 것을 서버 측이 아닌 클라이언트 측에서 잘못 처리할 때 발생합니다. 이 실수로 인해 `client_secret`가 노출되어 공격자가 애플리케이션의 위장으로 `access_token`을 생성할 수 있습니다. 더 나아가 사회 공학을 통해 공격자는 OAuth 권한에 추가적인 범위를 추가하여 애플리케이션의 신뢰 상태를 더 악용할 수 있습니다.
+### Client Secret Bruteforce
 
-### 클라이언트 시크릿 브루트포스
-
-서비스 제공자의 클라이언트 시크릿을 **브루트포스**하여 계정을 도용하려는 시도를 할 수 있습니다.\
-BF에 대한 요청은 다음과 유사할 수 있습니다:
+서비스 제공자의 **client\_secret**을 신원 제공자와 함께 **bruteforce**하여 계정을 탈취하려고 시도할 수 있습니다.\
+BF 요청은 다음과 유사할 수 있습니다:
 ```
 POST /token HTTP/1.1
 content-type: application/x-www-form-urlencoded
@@ -124,27 +122,27 @@ code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=au
 ```
 ### Referer Header leaking Code + State
 
-클라이언트가 **코드와 상태를** 가지고 있고, 다른 페이지로 이동할 때 **Referer 헤더 내에 반영**된다면 취약합니다.
+클라이언트가 **code와 state**를 가지고 있을 때, **Referer 헤더에 반영**되어 다른 페이지로 이동할 때 노출된다면 취약합니다.
 
 ### Access Token Stored in Browser History
 
-**브라우저 기록을 확인하여 액세스 토큰이 저장되어 있는지** 확인합니다.
+**브라우저 기록을 확인하여 access token이 저장되어 있는지 확인**합니다.
 
 ### 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)**
+[**이 게시물 확인**](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**가 사용자에게 돌려주는 **토큰**이 **사용자 데이터를 덮어쓸 충분한 권한을 가질 수 있다는 것**을 볼 수 있습니다. 따라서, **다른 사용자 이메일로 사용자 이메일을 변경**할 수 있다면, 다른 사람의 계정을 **탈취**할 수 있을 수도 있습니다.
+이 버그 바운티 보고서에서: [**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[...]
@@ -161,71 +159,83 @@ aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ
 ]
 }
 ```
-더 자세한 정보를 원하시면 AWS Cognito를 악용하는 방법을 확인하세요:
+For more detailed info about how to abuse AWS cognito check:
 
 {% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}
 
-### 다른 앱 토큰 남용 <a href="#bda5" id="bda5"></a>
+### Abusing other Apps tokens <a href="#bda5" id="bda5"></a>
 
-[**이 글에서 언급된 것**](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 애플리케이션에 피해자의 사용자 토큰으로 로그인**할 수 있습니다.
 
 {% hint style="danger" %}
-따라서, 공격자가 사용자가 자신의 OAuth 애플리케이션에 액세스하도록 관리하면, 토큰을 기대하고 있고 토큰이 자신의 앱 ID에 부여되었는지 확인하지 않는 애플리케이션에서 피해자 계정을 탈취할 수 있습니다.
+따라서, 공격자가 사용자가 자신의 OAuth 애플리케이션에 접근하도록 할 수 있다면, 토큰을 기대하고 토큰이 자신의 앱 ID에 부여되었는지 확인하지 않는 애플리케이션에서 피해자의 계정을 탈취할 수 있습니다.
 {% endhint %}
 
-### 두 링크 & 쿠키 <a href="#bda5" id="bda5"></a>
+### Two links & cookie <a href="#bda5" id="bda5"></a>
 
-[**이 글에 따르면**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), 피해자가 **공격자의 호스트를 가리키는 returnUrl**이 있는 페이지를 열도록 만들 수 있었습니다. 이 정보는 **쿠키(RU)에 저장**되며 **나중 단계에서** **프롬프트**가 **사용자에게** 해당 **공격자의 호스트에 액세스를 허용할지 물어볼 것입니다**.
+[**이 글**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f)에 따르면, 피해자가 **returnUrl**이 공격자의 호스트를 가리키는 페이지를 열도록 할 수 있었습니다. 이 정보는 **쿠키(RU)**에 저장되고 **나중 단계**에서 **프롬프트**가 **사용자**에게 공격자의 호스트에 접근 권한을 부여할지 묻습니다.
 
-이 프롬프트를 우회하기 위해 **Oauth 플로우를 시작하는 탭을 열어** 이 **RU 쿠키를 설정**할 수 있었고, **프롬프트가 표시되기 전에 탭을 닫고** 그 값을 가지지 않은 새 탭을 열 수 있었습니다. 그러면 **프롬프트는 공격자의 호스트에 대해 알리지 않겠지만**, 쿠키는 그것으로 설정되므로 **토큰은 리다이렉션 시 공격자의 호스트로 전송**됩니다.
+이 프롬프트를 우회하기 위해, **Oauth 흐름**을 시작하는 탭을 열어 이 RU 쿠키를 **returnUrl**을 사용하여 설정하고, 프롬프트가 표시되기 전에 탭을 닫고, 그 값을 사용하지 않고 새 탭을 엽니다. 그러면 **프롬프트는 공격자의 호스트에 대해 알리지 않지만**, 쿠키는 설정되어 **토큰이 리디렉션에서 공격자의 호스트로 전송**됩니다.
 
-### SSRF 매개변수 <a href="#bda5" id="bda5"></a>
+### Prompt Interaction Bypass <a href="#bda5" id="bda5"></a>
 
-**[이 연구를 확인하세요](https://portswigger.net/research/hidden-oauth-attack-vectors) 이 기술의 자세한 내용을 알아보세요.**
+[**이 비디오**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q)에서 설명된 것처럼, 일부 OAuth 구현에서는 **`prompt`** GET 매개변수를 None(**`&prompt=none`**)으로 설정하여 **사용자가 이미 플랫폼에 로그인되어 있는 경우 프롬프트에서 주어진 접근 권한을 확인하지 않도록** 할 수 있습니다.
 
-OAuth의 Dynamic Client Registration은 **Server-Side Request Forgery (SSRF)** 공격을 위한 덜 명백하지만 중요한 취약성 벡터로 작용합니다. 이 엔드포인트는 OAuth 서버가 클라이언트 애플리케이션에 대한 세부 정보를 받아들일 수 있도록 하며, 이 정보에는 악용될 수 있는 민감한 URL도 포함될 수 있습니다.
+### response\_mode
 
-**주요 포인트:**
+[**이 비디오**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q)에서 설명된 것처럼, 최종 URL에서 코드를 제공할 위치를 나타내기 위해 **`response_mode`** 매개변수를 지정할 수 있습니다:
 
-- **Dynamic Client Registration**은 주로 `/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를 가져오면 악용될 수 있습니다.
+* `response_mode=query` -> 코드는 GET 매개변수 내에 제공됩니다: `?code=2397rf3gu93f`
+* `response_mode=fragment` -> 코드는 URL 프래그먼트 매개변수 내에 제공됩니다: `#code=2397rf3gu93f`
+* `response_mode=form_post` -> 코드는 `code`라는 입력과 값이 있는 POST 폼 내에 제공됩니다
+* `response_mode=web_message` -> 코드는 post 메시지로 전송됩니다: `window.opener.postMessage({"code": "asdasdasd...`
 
-**악용 전략:**
+### SSRFs parameters <a href="#bda5" id="bda5"></a>
 
-- `logo_uri`, `jwks_uri`, 또는 `sector_identifier_uri`와 같은 매개변수에 악의적인 URL을 가진 새 클라이언트를 등록하여 SSRF를 트리거할 수 있습니다.
-- `request_uris`를 통한 직접적인 악용은 화이트리스트 제어로 완화될 수 있지만, 사전 등록된 공격자가 제어하는 `request_uri`를 제공하면 권한 부여 단계 중에 SSRF를 용이하게 할 수 있습니다.
+[**이 연구**](https://portswigger.net/research/hidden-oauth-attack-vectors)를 **자세히 확인하십시오.**
 
-## OAuth 제공자 Race Conditions
+OAuth의 동적 클라이언트 등록은 **서버 측 요청 위조(SSRF)** 공격에 대한 중요한 벡터로 작용할 수 있습니다. 이 엔드포인트는 OAuth 서버가 클라이언트 애플리케이션에 대한 세부 정보를 수신할 수 있도록 합니다.
 
-테스트 중인 플랫폼이 OAuth 제공자인 경우 [**가능한 Race Conditions을 테스트하려면 이를 읽으세요**](race-condition.md).
+**핵심 포인트:**
 
-## 참고 자료
+* **동적 클라이언트 등록**은 종종 `/register`에 매핑되며, POST 요청을 통해 `client_name`, `client_secret`, `redirect_uris`, 로고 또는 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 providers Race Conditions
+
+테스트 중인 플랫폼이 OAuth 제공자인 경우 [**이 문서를 읽고 가능한 Race Conditions을 테스트하십시오**](race-condition.md).
+
+## 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)
 
-
 <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>htARTE (HackTricks AWS Red Team Expert)로부터 제로에서 영웅까지 AWS 해킹 배우기</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
+<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>
 
-HackTricks를 지원하는 다른 방법:
+Other ways to support 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) 컬렉션
-* 💬 [**디스코드 그룹**](https://discord.gg/hRep4RUj7f) 또는 [**텔레그램 그룹**](https://t.me/peass)에 **가입**하거나 **트위터** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)을 **팔로우**하세요.
-* **HackTricks** 및 **HackTricks Cloud** 깃허브 저장소에 PR을 제출하여 **해킹 트릭을 공유**하세요.
+* 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>