Translated ['src/generic-methodologies-and-resources/external-recon-meth

2025-10-10 18:36:50 +00:00 · 2025-03-29 22:58:21 +00:00 · 2025-03-29 22:58:21 +00:00 · 6389bdff88
commit 6389bdff88
parent 8325efe983
3 changed files with 99 additions and 66 deletions
--- 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)
--- a/src/pentesting-web/oauth-to-account-takeover.md
+++ b/src/pentesting-web/oauth-to-account-takeover.md
@ -6,23 +6,23 @@

 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 server**: **resource owner**를 대신하여 `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 application`이 `access_token`을 획득하기 위해 `client_id` 및 `client_secret`과 함께 사용합니다.
- **access_token**: **클라이언트 애플리케이션이 `resource owner`를 대신하여 API 요청에 사용하는 토큰**.
+- **resource server**: **인증된 요청을 관리하는 서버**로, 애플리케이션이 `access token`을 `resource owner`를 대신하여 확보한 후에 작동합니다. 예: **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 application`이 `access_token`을 획득하기 위해 `client_id` 및 `client_secret`과 함께 사용합니다.
+- **access_token**: **클라이언트 애플리케이션이 `resource owner`를 대신하여 API 요청에 사용하는 토큰**입니다.
 - **refresh_token**: 애플리케이션이 **사용자에게 다시 요청하지 않고 새로운 `access_token`을 얻을 수 있게 해줍니다**.

 ### Flow
@ -30,7 +30,7 @@ OAuth 2.0 프레임워크 내에서 다음 구성 요소를 이해하는 것이
 **실제 OAuth 흐름**은 다음과 같이 진행됩니다:

 1. 귀하는 [https://example.com](https://example.com)으로 이동하여 “소셜 미디어와 통합” 버튼을 선택합니다.
-2. 사이트는 귀하의 게시물에 접근하기 위해 https://example.com의 애플리케이션에 대한 권한을 요청하는 [https://socialmedia.com](https://socialmedia.com)으로 요청을 보냅니다. 요청은 다음과 같이 구성됩니다:
+2. 사이트는 귀하의 게시물에 접근할 수 있도록 https://example.com의 애플리케이션에 대한 승인을 요청하는 [https://socialmedia.com](https://socialmedia.com)으로 요청을 보냅니다. 요청은 다음과 같이 구성됩니다:
 ```
 https://socialmedia.com/auth
 ?response_type=code
@ -50,31 +50,31 @@ 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 호출을 하여 접근하는 것으로 마무리됩니다.
+6. 마지막으로, 프로세스는 https://example.com이 귀하의 `access_token`을 사용하여 소셜 미디어에 API 호출을 하여 접근하는 것으로 마무리됩니다.

 ## 취약점 <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 매개변수도 리디렉션 공격에 취약합니다. 이러한 매개변수는 선택 사항이며 서버마다 지원이 다릅니다.

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

-이 버그 바운티 보고서에서 언급된 바와 같이 [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>

-OAuth 구현에서 **`state` 매개변수**의 오용 또는 누락은 **교차 사이트 요청 위조(CSRF)** 공격의 위험을 크게 증가시킬 수 있습니다. 이 취약점은 `state` 매개변수가 **사용되지 않거나, 정적 값으로 사용되거나, 제대로 검증되지 않을 때** 발생하여 공격자가 CSRF 보호를 우회할 수 있게 합니다.
+OAuth 구현에서 **`state` 매개변수**의 오용 또는 누락은 **교차 사이트 요청 위조(CSRF)** 공격의 위험을 크게 증가시킬 수 있습니다. 이 취약점은 `state` 매개변수가 **사용되지 않거나, 정적 값으로 사용되거나, 로그인 중 사용자 세션과 적절하게 검증되거나 연결되지 않을 때 발생**하여 공격자가 CSRF 보호를 우회할 수 있게 합니다.

-공격자는 이를 이용해 인증 프로세스를 가로채어 자신의 계정을 피해자의 계정과 연결할 수 있으며, 이는 잠재적인 **계정 탈취**로 이어질 수 있습니다. 이는 OAuth가 **인증 목적으로** 사용되는 애플리케이션에서 특히 중요합니다.
+공격자는 이를 이용해 권한 부여 프로세스를 가로채 피해자의 계정과 자신의 계정을 연결하여 사용자가 공격자의 거의 완료된 oauth 흐름으로 로그인하게 하여 잠재적인 **계정 탈취**를 초래할 수 있습니다. 이는 OAuth가 **인증 목적으로** 사용되는 애플리케이션에서 특히 중요합니다.

 이 취약점의 실제 사례는 다양한 **CTF 챌린지**와 **해킹 플랫폼**에서 문서화되어 있으며, 그 실질적인 영향을 강조합니다. 이 문제는 **Slack**, **Stripe**, **PayPal**과 같은 제3자 서비스와의 통합에도 확장되어, 공격자가 알림이나 결제를 자신의 계정으로 리디렉션할 수 있습니다.

@ -82,14 +82,14 @@ OAuth 구현에서 **`state` 매개변수**의 오용 또는 누락은 **교차

 ### 계정 탈취 전 <a href="#ebe4" id="ebe4"></a>

-1. **계정 생성 시 이메일 검증 없이**: 공격자는 피해자의 이메일을 사용하여 미리 계정을 생성할 수 있습니다. 이후 피해자가 로그인 시 제3자 서비스를 사용하면, 애플리케이션이 이 제3자 계정을 공격자가 미리 생성한 계정에 우연히 연결할 수 있어 무단 접근이 발생할 수 있습니다.
-2. **느슨한 OAuth 이메일 검증 악용**: 공격자는 이메일을 검증하지 않는 OAuth 서비스를 악용하여 자신의 서비스에 등록한 후 계정 이메일을 피해자의 이메일로 변경할 수 있습니다. 이 방법은 첫 번째 시나리오와 유사하게 무단 계정 접근의 위험을 초래하지만, 다른 공격 벡터를 통해 이루어집니다.
+1. **계정 생성 시 이메일 검증 없음**: 공격자는 피해자의 이메일을 사용하여 미리 계정을 생성할 수 있습니다. 피해자가 나중에 로그인 시 제3자 서비스를 사용하면, 애플리케이션이 이 제3자 계정을 공격자가 미리 생성한 계정에 우연히 연결할 수 있어 무단 접근이 발생할 수 있습니다.
+2. **느슨한 OAuth 이메일 검증 악용**: 공격자는 이메일을 검증하지 않는 OAuth 서비스를 악용하여 자신의 서비스에 등록한 후 계정 이메일을 피해자의 이메일로 변경할 수 있습니다. 이 방법은 첫 번째 시나리오와 유사하게 무단 계정 접근의 위험을 초래하지만 다른 공격 벡터를 통해 이루어집니다.

 ### 비밀 정보의 노출 <a href="#e177" id="e177"></a>

 비밀 OAuth 매개변수를 식별하고 보호하는 것은 중요합니다. **`client_id`**는 안전하게 공개할 수 있지만, **`client_secret`**을 노출하는 것은 상당한 위험을 초래합니다. `client_secret`이 유출되면 공격자는 애플리케이션의 신원과 신뢰를 악용하여 **사용자 `access_tokens`** 및 개인 정보를 **탈취**할 수 있습니다.

-일반적인 취약점은 애플리케이션이 클라이언트 측에서 `access_token`을 위한 인증 `code`의 교환을 잘못 처리할 때 발생합니다. 이 실수는 `client_secret`의 노출로 이어져, 공격자가 애플리케이션의 가장으로 `access_tokens`를 생성할 수 있게 합니다. 또한, 사회 공학을 통해 공격자는 OAuth 인증에 추가 범위를 추가하여 권한을 상승시킬 수 있으며, 애플리케이션의 신뢰된 상태를 더욱 악용할 수 있습니다.
+일반적인 취약점은 애플리케이션이 클라이언트 측에서 `access_token`을 위한 권한 부여 `code`의 교환을 잘못 처리할 때 발생합니다. 이 실수는 `client_secret`의 노출로 이어져 공격자가 애플리케이션의 가장으로 `access_tokens`를 생성할 수 있게 합니다. 또한, 사회 공학을 통해 공격자는 OAuth 권한 부여에 추가 범위를 추가하여 권한을 상승시킬 수 있으며, 애플리케이션의 신뢰된 상태를 더욱 악용할 수 있습니다.

 ### 클라이언트 비밀 무차별 대입

@ -106,7 +106,7 @@ code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=au
 ```
 ### Referer Header leaking Code + State

-클라이언트가 **코드와 상태**를 가지고 있고, 다른 페이지로 이동할 때 **Referer 헤더에 반영된다면**, 이는 취약합니다.
+클라이언트가 **코드와 상태**를 가지고 있을 때, 만약 **다른 페이지로 이동할 때 Referer 헤더에 반영된다면**, 이는 취약합니다.

 ### Access Token Stored in Browser History

@ -114,11 +114,11 @@ code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=au

 ### Everlasting Authorization Code

-**인증 코드는 공격자가 훔치고 사용할 수 있는 시간 창을 제한하기 위해 잠시만 존재해야 합니다**.
+**인증 코드는 공격자가 이를 훔치고 사용할 수 있는 시간 창을 제한하기 위해 잠시만 존재해야 합니다**.

 ### Authorization/Refresh Token not bound to client

-**인증 코드를 얻고 다른 클라이언트와 함께 사용할 수 있다면, 다른 계정을 탈취할 수 있습니다**.
+**인증 코드를 얻고 이를 다른 클라이언트와 함께 사용할 수 있다면, 다른 계정을 탈취할 수 있습니다**.

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

@ -153,27 +153,27 @@ https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticat

 [**이 글에서 언급된 바와 같이**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), **토큰**(코드가 아닌)을 수신할 것으로 예상되는 OAuth 흐름은 토큰이 앱에 속하는지 확인하지 않으면 취약할 수 있습니다.

-이는 **공격자**가 자신의 애플리케이션에서 **Facebook으로 로그인하는 OAuth를 지원하는 애플리케이션**을 생성할 수 있기 때문입니다. 그런 다음, 피해자가 **공격자의 애플리케이션**에서 Facebook으로 로그인하면, 공격자는 **자신의 애플리케이션에 제공된 사용자의 OAuth 토큰을 얻고, 이를 사용하여 피해자의 OAuth 애플리케이션에 피해자의 사용자 토큰으로 로그인할 수 있습니다**.
+이는 **공격자**가 자신의 애플리케이션에서 **Facebook으로 로그인하는 OAuth를 지원하는 애플리케이션**을 생성할 수 있기 때문입니다. 그런 다음, 피해자가 **공격자의 애플리케이션**에서 Facebook으로 로그인하면, 공격자는 **자신의 애플리케이션에 제공된 사용자의 OAuth 토큰을 얻고 이를 사용하여 피해자의 OAuth 애플리케이션에 로그인할 수 있습니다.**

 > [!CAUTION]
 > 따라서 공격자가 사용자가 자신의 OAuth 애플리케이션에 접근하도록 관리하면, 토큰을 기대하고 해당 토큰이 자신의 앱 ID에 부여되었는지 확인하지 않는 애플리케이션에서 피해자의 계정을 탈취할 수 있습니다.

 ### 두 링크 및 쿠키 <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)**에 **저장되며**, **나중에** **프롬프트**가 **사용자에게** 해당 공격자의 호스트에 대한 접근을 허용할 것인지 물어봅니다.

-이 프롬프트를 우회하기 위해, **returnUrl**을 사용하여 이 RU 쿠키를 설정하는 **Oauth 흐름**을 시작하기 위해 탭을 열고, 프롬프트가 표시되기 전에 탭을 닫고, 해당 값을 포함하지 않은 새 탭을 열 수 있었습니다. 그러면 **프롬프트는 공격자의 호스트에 대해 알리지 않지만**, 쿠키는 설정되므로 **토큰은 리디렉션에서 공격자의 호스트로 전송됩니다**.
+이 프롬프트를 우회하기 위해, **returnUrl**을 사용하여 이 RU 쿠키를 설정하는 **Oauth 흐름**을 시작하기 위해 탭을 열고, 프롬프트가 표시되기 전에 탭을 닫고 그 값을 포함하지 않은 새 탭을 열 수 있었습니다. 그러면 **프롬프트는 공격자의 호스트에 대해 알리지 않지만**, 쿠키는 설정되므로 **토큰은 리디렉션에서 공격자의 호스트로 전송됩니다.**

 ### 프롬프트 상호작용 우회 <a href="#bda5" id="bda5"></a>

-[**이 비디오에서 설명된 바와 같이**](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), 최종 URL에서 코드를 제공할 위치를 지정하기 위해 **`response_mode`** 매개변수를 지정하는 것이 가능할 수 있습니다:
+[**이 비디오에서 설명된 바와 같이**](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=fragment` -> 코드는 URL 조각 매개변수 내에 제공됩니다: `#code=2397rf3gu93f`
 - `response_mode=form_post` -> 코드는 `code`라는 입력을 가진 POST 양식 내에 제공됩니다.
 - `response_mode=web_message` -> 코드는 포스트 메시지로 전송됩니다: `window.opener.postMessage({"code": "asdasdasd...`

@ -181,43 +181,65 @@ https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticat

 [**이 블로그 게시물에 따르면**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96), 이는 **사용자 이름**과 **비밀번호**를 통해 OAuth에 로그인할 수 있는 OAuth 흐름입니다. 이 간단한 흐름에서 모든 작업에 대한 접근 권한이 있는 **토큰**이 반환되면, 해당 토큰을 사용하여 2FA를 우회할 수 있습니다.

-### 오픈 리디렉션을 기반으로 한 웹 페이지 리디렉션에서 ATO <a href="#bda5" id="bda5"></a>
+### 리디렉션 기반 ATO <a href="#bda5" id="bda5"></a>

-이 [**블로그 게시물**](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. 피해자 **웹사이트는 리퍼러를 기반으로 오픈 리디렉션을 트리거하여** 피해자 사용자를 공격자의 웹사이트로 리디렉션합니다. **`response_type`**이 **`id_token,code`**였기 때문에, 코드는 URL의 **조각**으로 공격자에게 다시 전송되어 피해자의 사이트에서 Google을 통해 사용자의 계정을 탈취할 수 있게 됩니다.
+2. 피해자가 악성 링크를 열고, 오프너가 `response_type=id_token,code&prompt=none`을 추가 매개변수로 사용하여 Google OAuth 흐름을 시작합니다.
+3. 오프너에서 제공자가 피해자를 승인한 후, `redirect_uri` 매개변수의 값(피해자 웹)으로 30X 코드와 함께 되돌려 보냅니다. 이때 여전히 공격자의 웹사이트가 리퍼러에 남아 있습니다.
+4. 피해자 **웹사이트는 리퍼러를 기반으로 오픈 리디렉션을 트리거하여** 피해자 사용자를 공격자의 웹사이트로 리디렉션합니다. **`response_type`**이 **`id_token,code`**였기 때문에, 코드는 URL의 **조각**으로 공격자에게 전송되어 피해자의 사이트에서 Google을 통해 사용자의 계정을 탈취할 수 있게 됩니다.

 ### SSRF 매개변수 <a href="#bda5" id="bda5"></a>

 [**이 연구를 확인하세요**](https://portswigger.net/research/hidden-oauth-attack-vectors) **이 기술에 대한 추가 세부정보를 위해.**

-OAuth의 동적 클라이언트 등록은 보안 취약점, 특히 **서버 측 요청 위조(SSRF)** 공격을 위한 덜 명백하지만 중요한 벡터로 작용합니다. 이 엔드포인트는 OAuth 서버가 클라이언트 애플리케이션에 대한 세부정보를 수신할 수 있도록 하며, 여기에는 악용될 수 있는 민감한 URL이 포함됩니다.
+OAuth의 동적 클라이언트 등록은 **서버 측 요청 위조(SSRF)** 공격을 위한 덜 명백하지만 중요한 벡터로 작용합니다. 이 엔드포인트는 OAuth 서버가 클라이언트 애플리케이션에 대한 세부정보를 수신할 수 있도록 하며, 여기에는 악용될 수 있는 민감한 URL이 포함됩니다.

 **주요 사항:**

 - **동적 클라이언트 등록**은 종종 `/register`에 매핑되며 `client_name`, `client_secret`, `redirect_uris`, 로고 또는 JSON 웹 키 세트(JWK)에 대한 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를 가져오면 악용될 수 있습니다.
+- 등록 프로세스는 여러 가지 방법으로 SSRF에 서버를 노출시킬 수 있습니다:
+  - **`logo_uri`**: 서버가 가져올 수 있는 클라이언트 애플리케이션의 로고 URL로, SSRF를 유발하거나 URL이 잘못 처리될 경우 XSS로 이어질 수 있습니다.
+  - **`jwks_uri`**: 클라이언트의 JWK 문서에 대한 URL로, 악의적으로 작성된 경우 서버가 공격자가 제어하는 서버로 아웃바운드 요청을 하게 만들 수 있습니다.
+  - **`sector_identifier_uri`**: 서버가 가져올 수 있는 `redirect_uris`의 JSON 배열을 참조하여 SSRF 기회를 생성할 수 있습니다.
+  - **`request_uris`**: 클라이언트에 대해 허용된 요청 URI를 나열하며, 서버가 인증 프로세스 시작 시 이러한 URI를 가져오면 악용될 수 있습니다.

 **악용 전략:**

 - SSRF는 `logo_uri`, `jwks_uri` 또는 `sector_identifier_uri`와 같은 매개변수에 악의적인 URL로 새 클라이언트를 등록하여 유발할 수 있습니다.
- `request_uris`를 통한 직접적인 악용은 화이트리스트 제어로 완화될 수 있지만, 사전 등록된 공격자가 제어하는 `request_uri`를 제공하면 권한 부여 단계에서 SSRF를 촉발할 수 있습니다.
+- `request_uris`를 통한 직접적인 악용은 화이트리스트 제어로 완화될 수 있지만, 사전 등록된 공격자가 제어하는 `request_uri`를 제공하면 인증 단계에서 SSRF를 촉진할 수 있습니다.

 ## OAuth 제공자의 경쟁 조건

 테스트 중인 플랫폼이 OAuth 제공자인 경우 [**경쟁 조건을 테스트하기 위해 이 내용을 읽어보세요**](race-condition.md).

+## 변경 가능한 클레임 공격
+
+OAuth에서 sub 필드는 사용자를 고유하게 식별하지만, 그 형식은 인증 서버에 따라 다릅니다. 사용자 식별을 표준화하기 위해 일부 클라이언트는 이메일이나 사용자 핸들을 사용합니다. 그러나 이는 위험할 수 있습니다:
+
+- 일부 인증 서버는 이러한 속성(예: 이메일)이 불변으로 유지되도록 보장하지 않습니다.
+- 특정 구현—예: **"Microsoft로 로그인"**—에서는 클라이언트가 이메일 필드에 의존하며, 이는 **Entra ID에서 사용자가 제어합니다**.
+- 공격자는 자신의 Azure AD 조직(예: doyensectestorg)을 생성하고 이를 사용하여 Microsoft 로그인을 수행할 수 있습니다.
+- Object ID(서브에 저장됨)는 불변하고 안전하지만, 변경 가능한 이메일 필드에 대한 의존은 계정 탈취를 가능하게 할 수 있습니다(예: victim@gmail.com과 같은 계정 탈취).
+
+## 클라이언트 혼란 공격
+
+**클라이언트 혼란 공격**에서 OAuth 암시적 흐름을 사용하는 애플리케이션은 최종 액세스 토큰이 자신의 클라이언트 ID에 대해 특별히 생성되었는지 확인하지 못합니다. 공격자는 Google의 OAuth 암시적 흐름을 사용하는 공개 웹사이트를 설정하여 수천 명의 사용자가 로그인하도록 유도하고, 그 결과 공격자의 사이트를 위한 액세스 토큰을 수집합니다. 이러한 사용자가 클라이언트 ID의 유효성을 검사하지 않는 다른 취약한 웹사이트에 계정을 가지고 있다면, 공격자는 수집한 토큰을 재사용하여 피해자를 가장하고 그들의 계정을 탈취할 수 있습니다.
+
+## 범위 업그레이드 공격
+
+**Authorization Code Grant** 유형은 사용자 데이터를 전송하기 위한 안전한 서버 간 통신을 포함합니다. 그러나 **Authorization Server**가 액세스 토큰 요청에서 범위 매개변수를 암묵적으로 신뢰하는 경우(이는 RFC에 정의되지 않은 매개변수), 악의적인 애플리케이션이 더 높은 범위를 요청하여 권한 부여 코드를 업그레이드할 수 있습니다. **Access Token**이 생성된 후, **Resource Server**는 이를 검증해야 합니다: JWT 토큰의 경우 JWT 서명을 확인하고 client_id 및 scope와 같은 데이터를 추출해야 하며, 무작위 문자열 토큰의 경우 서버는 Authorization Server에 쿼리하여 토큰의 세부정보를 검색해야 합니다.
+
+## 리디렉션 스킴 하이재킹
+
+모바일 OAuth 구현에서 앱은 **사용자 정의 URI 스킴**을 사용하여 권한 부여 코드를 포함한 리디렉션을 수신합니다. 그러나 여러 앱이 장치에서 동일한 스킴을 등록할 수 있기 때문에, 합법적인 클라이언트만 리디렉션 URI를 제어한다는 가정이 위배됩니다. 예를 들어 Android에서는 `com.example.app://`와 같은 Intent URI가 스킴 및 앱의 intent-filter에 정의된 선택적 필터를 기반으로 포착됩니다. Android의 인텐트 해상도가 광범위할 수 있기 때문에(특히 스킴만 지정된 경우) 공격자는 정교하게 작성된 인텐트 필터를 가진 악성 앱을 등록하여 권한 부여 코드를 하이재킹할 수 있습니다. 이는 사용자 상호작용(여러 앱이 인텐트를 처리할 수 있는 경우) 또는 지나치게 구체적인 필터를 악용하는 우회 기술을 통해 계정 탈취를 가능하게 할 수 있습니다.
+
 ## 참고 문헌

 - [**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}}
--- a/src/pentesting-web/unicode-injection/README.md
+++ b/src/pentesting-web/unicode-injection/README.md
@ -1,36 +1,36 @@
-# 유니코드 주입
+# Unicode Injection

 {{#include ../../banners/hacktricks-training.md}}

-## 소개
+## Introduction

-백엔드/프론트엔드가 **이상한 유니코드 문자를 수신할 때** 어떻게 동작하는지에 따라 공격자는 **보호를 우회하고 임의의 문자를 주입**할 수 있으며, 이는 XSS 또는 SQLi와 같은 **주입 취약점을 악용하는 데 사용될 수 있습니다**.
+백엔드/프론트엔드가 **이상한 유니코드 문자를 받을 때** 어떻게 동작하는지에 따라 공격자는 **보호를 우회하고 임의의 문자를 주입**할 수 있으며, 이는 XSS나 SQLi와 같은 **주입 취약점을 악용**하는 데 사용될 수 있습니다.

-## 유니코드 정규화
+## Unicode Normalization

-유니코드 정규화는 **유니코드 문자가 ASCII 문자로 정규화될 때** 발생합니다.
+유니코드 정규화는 **유니코드 문자가 ASCII 문자로 정규화**될 때 발생합니다.

-이러한 유형의 취약점의 일반적인 시나리오는 시스템이 **검사한 후** 사용자 **입력을 어떤 식으로든 수정**할 때 발생합니다. 예를 들어, 일부 언어에서는 **입력을 대문자 또는 소문자로** 만드는 간단한 호출이 주어진 입력을 정규화하고 **유니코드가 ASCII로 변환**되어 새로운 문자가 생성될 수 있습니다.\
+이 유형의 취약점의 일반적인 시나리오는 시스템이 **사용자의 입력을 확인한 후** 어떤 식으로든 **수정**할 때 발생합니다. 예를 들어, 일부 언어에서는 **입력을 대문자 또는 소문자로** 만드는 간단한 호출이 주어진 입력을 정규화하고 **유니코드가 ASCII로 변환**되어 새로운 문자가 생성될 수 있습니다.\
 자세한 내용은 다음을 확인하세요:

 {{#ref}}
 unicode-normalization.md
 {{#endref}}

-## `\u`에서 `%`로
+## `\u` to `%`

-유니코드 문자는 일반적으로 **`\u` 접두사**로 표현됩니다. 예를 들어 문자 `㱋`는 `\u3c4b`입니다([여기에서 확인](https://unicode-explorer.com/c/3c4B)). 만약 백엔드가 **`\u` 접두사를 `%`로 변환**하면, 결과 문자열은 `%3c4b`가 되며, URL 디코딩하면 **`<4b`**가 됩니다. 그리고, 보시다시피, **`<` 문자가 주입됩니다**.\
+유니코드 문자는 일반적으로 **`\u` 접두사**로 표현됩니다. 예를 들어 문자 `㱋`는 `\u3c4b`입니다([여기에서 확인](https://unicode-explorer.com/c/3c4B)). 만약 백엔드가 **`\u` 접두사를 `%`로 변환**하면, 결과 문자열은 `%3c4b`가 되며, URL 디코딩하면: **`<4b`**가 됩니다. 그리고, 보시다시피, **`<` 문자가 주입**됩니다.\
 백엔드가 취약하다면 이 기술을 사용하여 **어떤 종류의 문자도 주입**할 수 있습니다.\
 필요한 문자를 찾으려면 [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)에서 발생한 일입니다.

-이 경우, 서버가 악성 문자를 제거한 후 **Windows-1252에서 UTF-8로 UTF-8 문자열을 변환**했기 때문에 오류가 발생했습니다(기본적으로 입력 인코딩과 변환 인코딩이 불일치했습니다). 그러면 이는 적절한 <를 제공하지 않고 이상한 유니코드 문자 `‹`만 제공합니다.\
-``그래서 그들은 이 출력을 가져와서 **이제 UTF-8에서 ASCII로 다시 변환**했습니다. 이렇게 하면 `‹`가 `<`로 **정규화**되어 이 시스템에서 익스플로잇이 작동할 수 있었습니다.\
+이 경우, 서버가 악성 문자를 제거한 후 **UTF-8 문자열을 Windows-1252에서 UTF-8로 변환**했기 때문에 오류가 발생했습니다(기본적으로 입력 인코딩과 변환 인코딩이 불일치했습니다). 그러면 제대로 된 <가 아니라 이상한 유니코드 문자인 `‹`가 생성됩니다.\
+``그래서 이 출력을 가져와서 **이제 UTF-8에서 ASCII로 다시 변환**했습니다. 이렇게 하면 `‹`가 ` <`로 **정규화**되어 이 시스템에서 익스플로잇이 작동할 수 있었습니다.\
 이것이 발생한 일입니다:
 ```php
 <?php
@ -42,9 +42,23 @@ $str = iconv("UTF-8", "ASCII//TRANSLIT", $str);

 echo "String: " . $str;
 ```
-이모지 목록:
+Emoji 목록:

 - [https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv](https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv)
 - [https://unicode.org/emoji/charts-14.0/full-emoji-list.html](https://unicode.org/emoji/charts-14.0/full-emoji-list.html)

+## Windows Best-Fit/Worst-fit
+
+**[이 훌륭한 게시물](https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/)**에서 설명된 바와 같이, Windows에는 **Best-Fit**이라는 기능이 있어 **ASCII 모드에서 표시할 수 없는 유니코드 문자를** 유사한 문자로 **대체**합니다. 이는 백엔드가 **특정 문자를 기대**하고 있지만 다른 문자를 받을 때 **예상치 못한 동작**을 초래할 수 있습니다.
+
+**[https://worst.fit/mapping/](https://worst.fit/mapping/)**에서 best-fit 문자를 찾을 수 있습니다.
+
+Windows는 일반적으로 실행의 마지막 부분에서 유니코드 문자열을 ASCII 문자열로 변환하므로(보통 "W" 접미사가 있는 API에서 "A" 접미사가 있는 API로 이동, 예: `GetEnvironmentVariableA`와 `GetEnvironmentVariableW`) 공격자가 유니코드 문자를 보내어 보호를 우회할 수 있습니다. 이 문자는 마지막에 ASCII 문자로 변환되어 예상치 못한 동작을 수행하게 됩니다.
+
+블로그 게시물에서는 **문자 블랙리스트**를 사용하여 수정된 취약점을 우회하는 방법, [“/“ (0x2F)로 매핑된 문자](https://worst.fit/mapping/#to%3A0x2f)를 사용하여 **경로 탐색**을 악용하는 방법, [“\“ (0x5C)로 매핑된 문자](https://worst.fit/mapping/#to%3A0x5c)를 사용하거나 PHP의 `escapeshellarg` 또는 Python의 `subprocess.run`과 같은 셸 이스케이프 보호를 우회하는 방법이 제안되었습니다. 예를 들어, **전각 따옴표 (U+FF02)**를 사용하여 최종적으로 1개의 인수처럼 보이는 것이 2개의 인수로 변환되었습니다.
+
+**앱이 취약하려면 "W" Windows API를 사용해야 하지만 "A" Windows API를 호출해야 하므로 유니코드 문자열의 "Best-fit"이 생성됩니다.**
+
+**여러 발견된 취약점은 이 문제를 누가 해결해야 하는지에 대한 합의가 없기 때문에 수정되지 않을 것입니다.**
+
 {{#include ../../banners/hacktricks-training.md}}