Translated ['src/pentesting-web/domain-subdomain-takeover.md', 'src/pent

2025-10-10 18:36:50 +00:00 · 2025-02-04 18:51:53 +00:00 · 2025-02-04 18:51:53 +00:00 · 0637bf91f2
commit 0637bf91f2
parent 088ec82044
2 changed files with 97 additions and 54 deletions
--- a/src/pentesting-web/domain-subdomain-takeover.md
+++ b/src/pentesting-web/domain-subdomain-takeover.md
@ -1,17 +1,17 @@
-# 도메인/서브도메인 탈취
+# Domain/Subdomain takeover

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


-## 도메인 탈취
+## Domain takeover

-어떤 서비스에서 **사용되고 있는 도메인(domain.tld)**을 발견했지만 **회사**가 **소유권**을 **잃은** 경우, 이를 **등록**하려고 시도할 수 있습니다(가격이 저렴할 경우). 그리고 회사에 알려줄 수 있습니다. 이 도메인이 **GET** 매개변수나 **Referer** 헤더를 통해 세션 쿠키와 같은 **민감한 정보**를 받고 있다면, 이는 확실히 **취약점**입니다.
+어떤 도메인(domain.tld)이 **범위 내의 서비스에 의해 사용되고 있지만** **회사가** **소유권**을 **잃은** 경우, 이를 **등록**하려고 시도할 수 있습니다(가격이 저렴할 경우) 그리고 회사에 알려줄 수 있습니다. 이 도메인이 **GET** 매개변수나 **Referer** 헤더를 통해 세션 쿠키와 같은 **민감한 정보**를 받고 있다면, 이는 확실히 **취약점**입니다.

-### 서브도메인 탈취
+### Subdomain takeover

 회사의 서브도메인이 **등록되지 않은 이름의 제3자 서비스**를 가리키고 있습니다. 이 **제3자 서비스**에서 **계정을 생성**하고 사용 중인 **이름**을 **등록**할 수 있다면, 서브도메인 탈취를 수행할 수 있습니다.

-가능한 탈취를 확인하기 위한 여러 도구가 있습니다:
+가능한 탈취를 확인하기 위한 여러 도구와 사전이 있습니다:

 - [https://github.com/EdOverflow/can-i-take-over-xyz](https://github.com/EdOverflow/can-i-take-over-xyz)
 - [https://github.com/blacklanternsecurity/bbot](https://github.com/blacklanternsecurity/bbot)
@ -27,55 +27,72 @@
 - [https://github.com/Stratus-Security/Subdominator](https://github.com/Stratus-Security/Subdominator)
 - [https://github.com/NImaism/takeit](https://github.com/NImaism/takeit)

-### DNS 와일드카드를 통한 서브도메인 탈취 생성
+### Subdomain Takeover Generation via DNS Wildcard

-도메인에서 DNS 와일드카드가 사용될 경우, 해당 도메인의 요청된 서브도메인이 명시적으로 다른 주소가 없으면 **같은 정보로 해결**됩니다. 이는 A IP 주소, CNAME 등이 될 수 있습니다.
+DNS 와일드카드가 도메인에 사용될 때, 해당 도메인의 요청된 서브도메인 중 다른 주소가 명시적으로 없으면 **같은 정보로 해결**됩니다. 이는 A IP 주소, CNAME 등이 될 수 있습니다.

-예를 들어, `*.testing.com`이 `1.1.1.1`로 와일드카드 처리되었다면, `not-existent.testing.com`은 `1.1.1.1`을 가리키게 됩니다.
+예를 들어, `*.testing.com`이 `1.1.1.1`로 와일드카드 처리되면, `not-existent.testing.com`은 `1.1.1.1`을 가리키게 됩니다.

-그러나 IP 주소를 가리키는 대신, 시스템 관리자가 **CNAME**을 통해 **제3자 서비스**를 가리키게 하면, 예를 들어 G**ithub 서브도메인**(`sohomdatta1.github.io`)과 같은 경우, 공격자는 **자신의 제3자 페이지**(이 경우 Gihub에서)를 생성하고 `something.testing.com`이 그곳을 가리킨다고 주장할 수 있습니다. 왜냐하면 **CNAME 와일드카드**가 공격자가 **피해자의 도메인에 대해 임의의 서브도메인을 생성하여 자신의 페이지를 가리키게 할 수 있도록 허용하기 때문입니다**.
+그러나 IP 주소를 가리키는 대신, 시스템 관리자가 이를 **CNAME을 통해 제3자 서비스**로 가리키게 하면, 예를 들어 G**ithub 서브도메인**(`sohomdatta1.github.io`)과 같은 경우, 공격자는 **자신의 제3자 페이지**(이 경우 Gihub에서)를 생성하고 `something.testing.com`이 그곳을 가리킨다고 주장할 수 있습니다. 왜냐하면, **CNAME 와일드카드**가 공격자가 **희생자의 도메인에 대해 임의의 서브도메인을 생성하여 자신의 페이지를 가리키게 할 수 있도록 허용하기 때문입니다**.

 이 취약점의 예시는 CTF 작성물에서 확인할 수 있습니다: [https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api)

-## 서브도메인 탈취 악용
+## Exploiting a subdomain takeover

-서브도메인 탈취는 본질적으로 특정 도메인에 대한 DNS 스푸핑으로, 공격자가 도메인에 대한 A 레코드를 설정하여 브라우저가 공격자의 서버에서 콘텐츠를 표시하도록 합니다. 이러한 **투명성**은 브라우저에서 도메인을 피싱에 취약하게 만듭니다. 공격자는 이를 위해 [_타이포스쿼팅_](https://en.wikipedia.org/wiki/Typosquatting) 또는 [_도플갱어 도메인_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger)을 사용할 수 있습니다. 특히 피싱 이메일의 URL이 합법적으로 보이는 도메인은 사용자들을 속이고 도메인의 본질적인 신뢰로 인해 스팸 필터를 회피하는 데 취약합니다.
+서브도메인 탈취는 본질적으로 특정 도메인에 대한 DNS 스푸핑으로, 공격자가 도메인에 대한 A 레코드를 설정하여 브라우저가 공격자의 서버에서 콘텐츠를 표시하도록 합니다. 이러한 **투명성**은 브라우저에서 도메인을 피싱에 취약하게 만듭니다. 공격자는 이를 위해 [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) 또는 [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger)를 사용할 수 있습니다. 특히 피싱 이메일의 URL이 합법적으로 보이는 도메인은 사용자들을 속이고 도메인의 본질적인 신뢰로 인해 스팸 필터를 회피하는 데 취약합니다.

 자세한 내용은 이 [게시물](https://0xpatrik.com/subdomain-takeover/)을 확인하세요.

-### **SSL 인증서**
+### **SSL Certificates**

-SSL 인증서는 공격자가 [_Let's Encrypt_](https://letsencrypt.org/)와 같은 서비스를 통해 생성할 경우, 이러한 가짜 도메인의 신뢰성을 높여 피싱 공격을 더욱 설득력 있게 만듭니다.
+SSL 인증서는 공격자가 [_Let's Encrypt_](https://letsencrypt.org/)와 같은 서비스를 통해 생성한 경우, 이러한 가짜 도메인의 신뢰성을 높여 피싱 공격을 더욱 설득력 있게 만듭니다.

-### **쿠키 보안 및 브라우저 투명성**
+### **Cookie Security and Browser Transparency**

-브라우저의 투명성은 쿠키 보안에도 확장되며, 이는 [동일 출처 정책](https://en.wikipedia.org/wiki/Same-origin_policy)과 같은 정책에 의해 관리됩니다. 쿠키는 종종 세션을 관리하고 로그인 토큰을 저장하는 데 사용되며, 서브도메인 탈취를 통해 악용될 수 있습니다. 공격자는 **손상된 서브도메인으로 사용자를 유도하여 세션 쿠키를 수집**할 수 있어 사용자 데이터와 개인 정보가 위험에 처할 수 있습니다.
+브라우저의 투명성은 쿠키 보안에도 확장되며, 이는 [Same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy)와 같은 정책에 의해 관리됩니다. 쿠키는 종종 세션을 관리하고 로그인 토큰을 저장하는 데 사용되며, 서브도메인 탈취를 통해 악용될 수 있습니다. 공격자는 **손상된 서브도메인으로 사용자를 유도하여 세션 쿠키를 수집**할 수 있어 사용자 데이터와 개인 정보가 위험에 처할 수 있습니다.

-### **이메일 및 서브도메인 탈취**
+### CORS Bypass

-서브도메인 탈취의 또 다른 측면은 이메일 서비스와 관련이 있습니다. 공격자는 **MX 레코드**를 조작하여 합법적인 서브도메인에서 이메일을 수신하거나 발송할 수 있어 피싱 공격의 효율성을 높입니다.
+모든 서브도메인이 메인 도메인 또는 다른 서브도메인에서 CORS 리소스에 접근할 수 있도록 허용될 수 있습니다. 이는 공격자가 CORS 요청을 악용하여 **민감한 정보에 접근**할 수 있게 할 수 있습니다.

-### **고위험**
+### CSRF - Same-Site Cookies bypass

-추가적인 위험으로는 **NS 레코드 탈취**가 있습니다. 공격자가 도메인의 하나의 NS 레코드를 제어하게 되면, 그들은 자신의 제어 하에 있는 서버로 일부 트래픽을 유도할 수 있습니다. 공격자가 DNS 레코드에 대해 높은 **TTL(생존 시간)**을 설정하면 공격의 지속 시간이 연장되어 위험이 증가합니다.
+서브도메인이 `Same-Site` 속성으로 인해 도메인 또는 다른 서브도메인에 쿠키를 전송하는 것이 허용될 수 있습니다. 그러나, 올바르게 구현된 경우 anti-CSRF 토큰이 여전히 이 공격을 방지할 것입니다.

-### CNAME 레코드 취약점
+### OAuth tokens redirect

-공격자는 더 이상 사용되지 않거나 폐기된 외부 서비스로 가리키는 청구되지 않은 CNAME 레코드를 악용할 수 있습니다. 이를 통해 신뢰할 수 있는 도메인 아래에 페이지를 생성하여 피싱 또는 악성 소프트웨어 배포를 더욱 용이하게 할 수 있습니다.
+손상된 서브도메인이 OAuth 흐름의 `redirect_uri` URL에서 사용될 수 있는 경우가 있을 수 있습니다. 이는 공격자가 **OAuth 토큰을 훔치는** 데 악용될 수 있습니다.

-### **완화 전략**
+### CSP Bypass
+
+손상된 서브도메인(또는 모든 서브도메인)이 CSP의 `script-src`와 같은 곳에서 사용될 수 있는 경우가 있을 수 있습니다. 이는 공격자가 **악성 스크립트를 주입하고 잠재적인 XSS 취약점을 악용**할 수 있게 할 수 있습니다.
+
+### **Emails and Subdomain Takeover**
+
+서브도메인 탈취의 또 다른 측면은 이메일 서비스입니다. 공격자는 **MX 레코드**를 조작하여 합법적인 서브도메인에서 이메일을 수신하거나 발송할 수 있어 피싱 공격의 효율성을 높일 수 있습니다.
+
+### **Higher Order Risks**
+
+추가적인 위험으로는 **NS 레코드 탈취**가 있습니다. 공격자가 도메인의 하나의 NS 레코드를 제어하게 되면, 그들은 자신의 제어 하에 있는 서버로 트래픽의 일부를 유도할 수 있습니다. 공격자가 DNS 레코드에 대해 높은 **TTL (Time to Live)**을 설정하면 공격의 지속 시간이 늘어나 이 위험이 증가합니다.
+
+### CNAME Record Vulnerability
+
+공격자는 더 이상 사용되지 않거나 폐기된 외부 서비스로 가리키는 미청구 CNAME 레코드를 악용할 수 있습니다. 이를 통해 신뢰할 수 있는 도메인 아래에 페이지를 생성하여 피싱 또는 악성 소프트웨어 배포를 더욱 용이하게 할 수 있습니다.
+
+### **Mitigation Strategies**

 완화 전략에는 다음이 포함됩니다:

 1. **취약한 DNS 레코드 제거** - 서브도메인이 더 이상 필요하지 않은 경우 효과적입니다.
 2. **도메인 이름 주장** - 해당 클라우드 제공업체에 리소스를 등록하거나 만료된 도메인을 재구매합니다.
-3. **취약점에 대한 정기적인 모니터링** - [aquatone](https://github.com/michenriksen/aquatone)와 같은 도구가 취약한 도메인을 식별하는 데 도움이 될 수 있습니다. 조직은 또한 DNS 레코드 생성이 리소스 생성의 마지막 단계이자 리소스 파괴의 첫 번째 단계가 되도록 인프라 관리 프로세스를 검토해야 합니다.
+3. **취약점에 대한 정기적인 모니터링** - [aquatone](https://github.com/michenriksen/aquatone)와 같은 도구가 취약한 도메인을 식별하는 데 도움이 될 수 있습니다. 조직은 또한 DNS 레코드 생성이 리소스 생성의 마지막 단계이자 리소스 파괴의 첫 번째 단계가 되도록 인프라 관리 프로세스를 재검토해야 합니다.

-클라우드 제공업체의 경우, 서브도메인 탈취를 방지하기 위해 도메인 소유권 확인이 중요합니다. [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/)과 같은 일부는 이 문제를 인식하고 도메인 확인 메커니즘을 구현했습니다.
+클라우드 제공업체의 경우, 도메인 소유권 확인은 서브도메인 탈취를 방지하는 데 중요합니다. [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/)과 같은 일부는 이 문제를 인식하고 도메인 확인 메커니즘을 구현했습니다.

-## 참고 문헌
+## References

 - [https://0xpatrik.com/subdomain-takeover/](https://0xpatrik.com/subdomain-takeover/)
 - [https://www.stratussecurity.com/post/subdomain-takeover-guide](https://www.stratussecurity.com/post/subdomain-takeover-guide)
+- [https://www.hackerone.com/blog/guide-subdomain-takeovers-20](https://www.hackerone.com/blog/guide-subdomain-takeovers-20)

 {{#include ../banners/hacktricks-training.md}}
--- a/src/pentesting-web/hacking-with-cookies/README.md
+++ b/src/pentesting-web/hacking-with-cookies/README.md
@ -35,14 +35,14 @@
 쿠키를 구성할 때 이러한 속성을 이해하면 다양한 시나리오에서 예상대로 동작하도록 보장할 수 있습니다.

 | **요청 유형** | **예제 코드**                   | **쿠키 전송 시** |
-| ---------------- | ---------------------------------- | --------------------- |
-| 링크             | \<a href="...">\</a>               | NotSet\*, Lax, None   |
-| 프리렌더        | \<link rel="prerender" href=".."/> | NotSet\*, Lax, None   |
-| 폼 GET         | \<form method="GET" action="...">  | NotSet\*, Lax, None   |
-| 폼 POST        | \<form method="POST" action="..."> | NotSet\*, None        |
-| iframe           | \<iframe src="...">\</iframe>      | NotSet\*, None        |
-| AJAX             | $.get("...")                       | NotSet\*, None        |
-| 이미지            | \<img src="...">                   | NetSet\*, None        |
+| -------------- | -------------------------------- | ----------------- |
+| 링크           | \<a href="...">\</a>            | NotSet\*, Lax, None   |
+| 프리렌더링     | \<link rel="prerender" href=".."/> | NotSet\*, Lax, None   |
+| 폼 GET        | \<form method="GET" action="...">  | NotSet\*, Lax, None   |
+| 폼 POST       | \<form method="POST" action="..."> | NotSet\*, None        |
+| iframe         | \<iframe src="...">\</iframe>      | NotSet\*, None        |
+| AJAX           | $.get("...")                       | NotSet\*, None        |
+| 이미지        | \<img src="...">                   | NetSet\*, None        |

 표는 [Invicti](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/)에서 가져온 것이며 약간 수정되었습니다.\
 _**SameSite**_ 속성이 있는 쿠키는 **CSRF 공격을 완화**합니다.
@ -59,8 +59,8 @@ _**SameSite**_ 속성이 있는 쿠키는 **CSRF 공격을 완화**합니다.
 #### **우회 방법**

 - 페이지가 요청의 응답으로 쿠키를 **전송하는 경우** (예: **PHPinfo** 페이지에서), XSS를 악용하여 이 페이지에 요청을 보내고 응답에서 **쿠키를 훔칠 수 있습니다** (예제는 [여기](https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/)에서 확인하세요).
- **TRACE** **HTTP** 요청으로 우회할 수 있습니다. 서버의 응답은 전송된 쿠키를 반영합니다 (이 HTTP 메서드가 사용 가능한 경우). 이 기술은 **교차 사이트 추적**이라고 합니다.
- 이 기술은 **현대 브라우저에서 JS로 TRACE** 요청을 보내는 것을 허용하지 않음으로써 회피됩니다. 그러나 IE6.0 SP2에서 `TRACE` 대신 `\r\nTRACE`를 보내는 등의 특정 소프트웨어에서 우회 방법이 발견되었습니다.
+- **TRACE** **HTTP** 요청으로 우회할 수 있습니다. 서버의 응답은 전송된 쿠키를 반영합니다 (이 HTTP 메서드가 사용 가능한 경우). 이 기술은 **Cross-Site Tracking**이라고 합니다.
+- 이 기술은 **모던 브라우저에서 JS로 TRACE 요청을 전송하는 것을 허용하지 않음으로써 방지됩니다**. 그러나 IE6.0 SP2와 같은 특정 소프트웨어에서 `TRACE` 대신 `\r\nTRACE`를 전송하여 우회하는 방법이 발견되었습니다.
 - 또 다른 방법은 브라우저의 제로/데이 취약점을 악용하는 것입니다.
 - 쿠키 항아리 오버플로우 공격을 수행하여 **HttpOnly 쿠키를 덮어쓸 수 있습니다**:

@ -76,11 +76,11 @@ cookie-jar-overflow.md

 ## 쿠키 접두사

-`__Secure-`로 접두사가 붙은 쿠키는 HTTPS로 보호된 페이지에서 `secure` 플래그와 함께 설정되어야 합니다.
+`__Secure-`로 접두사가 붙은 쿠키는 HTTPS로 보호된 페이지와 함께 `secure` 플래그가 설정되어야 합니다.

 `__Host-`로 접두사가 붙은 쿠키는 여러 조건을 충족해야 합니다:

- `secure` 플래그와 함께 설정되어야 합니다.
+- `secure` 플래그가 설정되어야 합니다.
 - HTTPS로 보호된 페이지에서 유래해야 합니다.
 - 도메인을 지정할 수 없으며, 하위 도메인으로의 전송을 방지합니다.
 - 이러한 쿠키의 경로는 `/`로 설정되어야 합니다.
@ -89,17 +89,17 @@ cookie-jar-overflow.md

 ### 쿠키 덮어쓰기

-따라서 `__Host-` 접두사가 붙은 쿠키의 보호 중 하나는 하위 도메인에서 덮어쓰는 것을 방지하는 것입니다. 예를 들어 [**쿠키 토스 공격**](cookie-tossing.md)을 방지합니다. [**쿠키 크럼블: 웹 세션 무결성 취약점 공개**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**논문**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf))에서 하위 도메인에서 \_\_HOST- 접두사가 붙은 쿠키를 설정할 수 있는 방법이 제시되었습니다. 파서를 속여서, 예를 들어 시작 부분이나 끝에 "="를 추가하는 방식입니다:
+따라서 `__Host-` 접두사가 붙은 쿠키의 보호 중 하나는 하위 도메인에서 덮어쓰는 것을 방지하는 것입니다. 예를 들어 [**쿠키 토스 공격**](cookie-tossing.md)을 방지합니다. [**쿠키 크럼블: 웹 세션 무결성 취약점 공개**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**논문**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf))에서 하위 도메인에서 __HOST- 접두사가 붙은 쿠키를 설정할 수 있는 방법이 제시되었습니다. 예를 들어, 시작 부분이나 끝 부분에 "="를 추가하여 파서를 속이는 방법입니다:

 <figure><img src="../../images/image (6) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

-또는 PHP에서는 쿠키 이름의 시작 부분에 **다른 문자를 추가**하여 **밑줄** 문자로 대체되도록 하여 `__HOST-` 쿠키를 덮어쓸 수 있었습니다:
+또한 PHP에서는 쿠키 이름의 시작 부분에 **다른 문자를 추가하여** **밑줄** 문자로 대체되도록 하여 `__HOST-` 쿠키를 덮어쓸 수 있었습니다:

 <figure><img src="../../images/image (7) (1) (1) (1) (1).png" alt="" width="373"><figcaption></figcaption></figure>

 ## 쿠키 공격

-사용자 정의 쿠키에 민감한 데이터가 포함되어 있는 경우 확인하세요 (특히 CTF를 진행 중이라면), 취약할 수 있습니다.
+사용자 정의 쿠키에 민감한 데이터가 포함되어 있는 경우 확인하세요 (특히 CTF를 진행 중인 경우), 취약할 수 있습니다.

 ### 쿠키 디코딩 및 조작

@ -111,7 +111,7 @@ cookie-jar-overflow.md

 ### 세션 고정

-이 시나리오에서 공격자는 피해자를 특정 쿠키를 사용하여 로그인하도록 속입니다. 애플리케이션이 로그인 시 새 쿠키를 할당하지 않으면, 원래 쿠키를 가진 공격자는 피해자를 가장할 수 있습니다. 이 기술은 피해자가 공격자가 제공한 쿠키로 로그인하는 데 의존합니다.
+이 시나리오에서 공격자는 피해자를 특정 쿠키를 사용하여 로그인하도록 속입니다. 애플리케이션이 로그인 시 새로운 쿠키를 할당하지 않으면, 원래 쿠키를 가진 공격자는 피해자를 가장할 수 있습니다. 이 기술은 피해자가 공격자가 제공한 쿠키로 로그인하는 데 의존합니다.

 하위 도메인에서 **XSS를 발견했거나** 하위 도메인을 **제어하는 경우**, 읽어보세요:

@ -147,7 +147,7 @@ document.cookie = "a=v1"
 document.cookie = "=test value;" // Setting an empty named cookie
 document.cookie = "b=v2"
 ```
-전송된 쿠키 헤더의 결과는 `a=v1; test value; b=v2;`입니다. 흥미롭게도, 이는 빈 이름 쿠키가 설정되면 쿠키를 조작할 수 있게 하며, 빈 쿠키를 특정 값으로 설정함으로써 다른 쿠키를 제어할 수 있는 가능성을 제공합니다:
+전송된 쿠키 헤더의 결과는 `a=v1; test value; b=v2;`입니다. 흥미롭게도, 이는 빈 이름 쿠키가 설정되면 쿠키를 조작할 수 있게 하며, 빈 쿠키를 특정 값으로 설정함으로써 다른 쿠키를 제어할 수 있습니다:
 ```js
 function setCookie(name, value) {
 document.cookie = `${name}=${value}`
@ -173,30 +173,56 @@ RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";
 ```
 #### 쿠키 주입 취약점

-(Check further details in the[original research](https://blog.ankursundara.com/cookie-bugs/)) 서버가 쿠키를 잘못 파싱하는 경우, 특히 Undertow, Zope 및 Python의 `http.cookie.SimpleCookie`와 `http.cookie.BaseCookie`를 사용하는 경우 쿠키 주입 공격의 기회를 제공합니다. 이러한 서버는 새로운 쿠키의 시작을 제대로 구분하지 못해 공격자가 쿠키를 스푸핑할 수 있게 합니다:
+(자세한 내용은 [원본 연구](https://blog.ankursundara.com/cookie-bugs/)를 참조하세요) 서버가 쿠키를 잘못 파싱하는 경우, 특히 Undertow, Zope 및 Python의 `http.cookie.SimpleCookie`와 `http.cookie.BaseCookie`를 사용하는 경우 쿠키 주입 공격의 기회를 제공합니다. 이러한 서버는 새로운 쿠키의 시작을 제대로 구분하지 못하여 공격자가 쿠키를 스푸핑할 수 있게 합니다:

 - Undertow는 세미콜론 없이 인용된 값 바로 뒤에 새로운 쿠키가 올 것으로 기대합니다.
 - Zope는 다음 쿠키를 파싱하기 위해 쉼표를 찾습니다.
 - Python의 쿠키 클래스는 공백 문자에서 파싱을 시작합니다.

-이 취약점은 쿠키 기반 CSRF 보호에 의존하는 웹 애플리케이션에서 특히 위험합니다. 공격자는 스푸핑된 CSRF 토큰 쿠키를 주입하여 보안 조치를 우회할 수 있습니다. 이 문제는 Python이 중복 쿠키 이름을 처리하는 방식으로 인해 악화되며, 마지막 발생이 이전 것을 덮어씁니다. 또한 불안전한 컨텍스트에서 `__Secure-` 및 `__Host-` 쿠키에 대한 우려를 불러일으키며, 쿠키가 스푸핑에 취약한 백엔드 서버로 전달될 때 권한 우회를 초래할 수 있습니다.
+이 취약점은 쿠키 기반 CSRF 보호에 의존하는 웹 애플리케이션에서 특히 위험합니다. 공격자는 스푸핑된 CSRF 토큰 쿠키를 주입하여 보안 조치를 우회할 수 있습니다. 이 문제는 Python의 중복 쿠키 이름 처리로 인해 악화되며, 마지막 발생이 이전 것을 덮어씁니다. 또한 불안전한 컨텍스트에서 `__Secure-` 및 `__Host-` 쿠키에 대한 우려를 불러일으키며, 쿠키가 스푸핑에 취약한 백엔드 서버로 전달될 때 권한 우회를 초래할 수 있습니다.

-### 쿠키 $version 및 WAF 우회
+### 쿠키 $version

-According to [**this blogpost**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie), **`$Version=1`** 쿠키 속성을 사용하여 백엔드가 **RFC2109**로 인해 쿠키를 파싱하는 오래된 논리를 사용할 수 있을 가능성이 있습니다. 또한 **`$Domain`** 및 **`$Path`**와 같은 다른 값을 사용하여 쿠키와 함께 백엔드의 동작을 수정할 수 있습니다.
+#### WAF 우회

-#### 인용 문자열 인코딩을 통한 우회 값 분석
+[**이 블로그 포스트**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie)에 따르면, **`$Version=1`** 쿠키 속성을 사용하여 백엔드가 쿠키를 파싱하는 오래된 논리를 사용할 수 있을지도 모릅니다. 이는 **RFC2109** 때문입니다. 또한 **`$Domain`** 및 **`$Path`**와 같은 다른 값들도 쿠키와 함께 백엔드의 동작을 수정하는 데 사용될 수 있습니다.

-이 파싱은 쿠키 내부의 이스케이프된 값을 언이스케이프하도록 지시하므로, "\a"는 "a"가 됩니다. 이는 WAF를 우회하는 데 유용할 수 있습니다:
+#### 쿠키 샌드위치 공격
+
+[**이 블로그 포스트**](https://portswigger.net/research/stealing-httponly-cookies-with-the-cookie-sandwich-technique)에 따르면, 쿠키 샌드위치 기법을 사용하여 HttpOnly 쿠키를 훔칠 수 있습니다. 다음은 요구 사항 및 단계입니다:
+
+- 응답에 명백히 쓸모없는 **쿠키가 반영되는 장소를 찾습니다**
+- **값이 `1`인 `$Version`이라는 쿠키를 생성합니다** (JS에서 XSS 공격으로 이 작업을 수행할 수 있습니다) 더 구체적인 경로를 설정하여 초기 위치를 차지하게 합니다 (일부 프레임워크는 이 단계를 필요로 하지 않습니다)
+- **반영되는 쿠키를 생성**하고 값에 **열린 큰따옴표**를 남기며, 이전 쿠키(`$Version`) 뒤에 위치하도록 특정 경로를 설정합니다
+- 그러면 합법적인 쿠키가 순서상 다음에 오게 됩니다
+- **큰따옴표를 닫는 더미 쿠키를 생성**합니다
+
+이렇게 하면 피해자 쿠키가 새로운 쿠키 버전 1 안에 갇히게 되고, 반영될 때마다 반영됩니다.
+예: 포스트에서:
+```javascript
+document.cookie = `$Version=1;`;
+document.cookie = `param1="start`;
+// any cookies inside the sandwich will be placed into param1 value server-side
+document.cookie = `param2=end";`;
+```
+### WAF 우회
+
+#### Cookies $version
+
+이전 섹션을 확인하세요.
+
+#### 인용 문자열 인코딩을 통한 값 분석 우회
+
+이 구문 분석은 쿠키 내에서 이스케이프된 값을 언이스케이프하도록 지시하므로, "\a"는 "a"가 됩니다. 이는 WAF를 우회하는 데 유용할 수 있습니다:

 - `eval('test') => forbidden`
 - `"\e\v\a\l\(\'\t\e\s\t\'\)" => allowed`

 #### 쿠키 이름 차단 목록 우회

-RFC2109에서는 **쉼표가 쿠키 값 사이의 구분자로 사용될 수 있다고 명시되어 있습니다**. 또한 **등호 앞뒤에 공백과 탭을 추가하는 것이 가능합니다**. 따라서 `$Version=1; foo=bar, abc = qux`와 같은 쿠키는 `"foo":"bar, admin = qux"`라는 쿠키를 생성하지 않고 `foo":"bar"`와 `"admin":"qux"`라는 쿠키를 생성합니다. 두 개의 쿠키가 생성되는 방식과 admin이 등호 앞뒤의 공백이 제거된 방식을 주목하세요.
+RFC2109에서는 **쿠키 값 사이에 쉼표를 구분자로 사용할 수 있다고 명시되어 있습니다**. 또한 **등호 앞뒤에 공백과 탭을 추가하는 것이 가능합니다**. 따라서 `$Version=1; foo=bar, abc = qux`와 같은 쿠키는 `"foo":"bar, admin = qux"`라는 쿠키를 생성하지 않고, `foo":"bar"`와 `"admin":"qux"`라는 쿠키를 생성합니다. 두 개의 쿠키가 생성되는 방식과 admin의 등호 앞뒤 공백이 제거된 방식을 주목하세요.

-#### 쿠키 분할을 통한 우회 값 분석
+#### 쿠키 분할을 통한 값 분석 우회

 마지막으로, 서로 다른 백도어는 서로 다른 쿠키 헤더에서 전달된 서로 다른 쿠키를 문자열로 결합할 수 있습니다:
 ```
@ -217,10 +243,10 @@ Resulting cookie: name=eval('test//, comment') => allowed
 #### **기본 검사**

 - **로그인**할 때마다 **쿠키**가 **같은**지 확인합니다.
- 로그아웃하고 동일한 쿠키를 사용해 보세요.
- 두 개의 장치(또는 브라우저)로 동일한 계정에 동일한 쿠키로 로그인해 보세요.
+- 로그아웃하고 같은 쿠키를 사용해 보세요.
+- 두 개의 장치(또는 브라우저)로 같은 계정에 같은 쿠키로 로그인해 보세요.
 - 쿠키에 정보가 있는지 확인하고 수정해 보세요.
- 거의 동일한 사용자 이름으로 여러 계정을 생성하고 유사성을 확인해 보세요.
+- 거의 같은 사용자 이름으로 여러 계정을 생성하고 유사성을 확인해 보세요.
 - "**기억하기**" 옵션이 존재하는지 확인하고 어떻게 작동하는지 살펴보세요. 존재하고 취약할 수 있다면, 다른 쿠키 없이 항상 **기억하기** 쿠키를 사용하세요.
 - 비밀번호를 변경한 후에도 이전 쿠키가 작동하는지 확인하세요.

@ -229,7 +255,7 @@ Resulting cookie: name=eval('test//, comment') => allowed
 로그인할 때 쿠키가 동일하게 유지되거나 거의 동일하다면, 이는 쿠키가 귀하의 계정의 일부 필드(아마도 사용자 이름)와 관련이 있음을 의미합니다. 그러면 다음을 시도할 수 있습니다:

 - 매우 **유사한** 사용자 이름으로 많은 **계정**을 생성하고 알고리즘이 어떻게 작동하는지 **추측**해 보세요.
- **사용자 이름을 브루트포스**해 보세요. 쿠키가 사용자 이름에 대한 인증 방법으로만 저장된다면, 사용자 이름 "**Bmin**"으로 계정을 생성하고 쿠키의 모든 **비트**를 **브루트포스**할 수 있습니다. 시도할 쿠키 중 하나는 "**admin**"에 속하는 쿠키가 될 것입니다.
+- **사용자 이름을 브루트포스**해 보세요. 쿠키가 사용자 이름에 대한 인증 방법으로만 저장된다면, 사용자 이름 "**Bmin**"으로 계정을 생성하고 쿠키의 모든 **비트**를 **브루트포스**할 수 있습니다. 왜냐하면 시도할 쿠키 중 하나는 "**admin**"에 속하는 쿠키일 것이기 때문입니다.
 - **패딩** **오라클**을 시도해 보세요(쿠키의 내용을 복호화할 수 있습니다). **패드버스터**를 사용하세요.

 **패딩 오라클 - 패드버스터 예제**