diff --git a/src/pentesting-web/domain-subdomain-takeover.md b/src/pentesting-web/domain-subdomain-takeover.md index 1c5798a8e..cd9f22907 100644 --- 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}} diff --git a/src/pentesting-web/hacking-with-cookies/README.md b/src/pentesting-web/hacking-with-cookies/README.md index 68acfc3fe..5da8b8714 100644 --- a/src/pentesting-web/hacking-with-cookies/README.md +++ b/src/pentesting-web/hacking-with-cookies/README.md @@ -35,14 +35,14 @@ 쿠키를 구성할 때 이러한 속성을 이해하면 다양한 시나리오에서 예상대로 동작하도록 보장할 수 있습니다. | **요청 유형** | **예제 코드** | **쿠키 전송 시** | -| ---------------- | ---------------------------------- | --------------------- | -| 링크 | \\ | NotSet\*, Lax, None | -| 프리렌더 | \ | NotSet\*, Lax, None | -| 폼 GET | \
| NotSet\*, Lax, None | -| 폼 POST | \ | NotSet\*, None | -| iframe | \ | NotSet\*, None | -| AJAX | $.get("...") | NotSet\*, None | -| 이미지 | \ | NetSet\*, None | +| -------------- | -------------------------------- | ----------------- | +| 링크 | \\ | NotSet\*, Lax, None | +| 프리렌더링 | \ | NotSet\*, Lax, None | +| 폼 GET | \ | NotSet\*, Lax, None | +| 폼 POST | \ | NotSet\*, None | +| iframe | \ | NotSet\*, None | +| AJAX | $.get("...") | NotSet\*, None | +| 이미지 | \ | 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- 접두사가 붙은 쿠키를 설정할 수 있는 방법이 제시되었습니다. 예를 들어, 시작 부분이나 끝 부분에 "="를 추가하여 파서를 속이는 방법입니다:
-또는 PHP에서는 쿠키 이름의 시작 부분에 **다른 문자를 추가**하여 **밑줄** 문자로 대체되도록 하여 `__HOST-` 쿠키를 덮어쓸 수 있었습니다: +또한 PHP에서는 쿠키 이름의 시작 부분에 **다른 문자를 추가하여** **밑줄** 문자로 대체되도록 하여 `__HOST-` 쿠키를 덮어쓸 수 있었습니다:
## 쿠키 공격 -사용자 정의 쿠키에 민감한 데이터가 포함되어 있는 경우 확인하세요 (특히 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**"에 속하는 쿠키일 것이기 때문입니다. - **패딩** **오라클**을 시도해 보세요(쿠키의 내용을 복호화할 수 있습니다). **패드버스터**를 사용하세요. **패딩 오라클 - 패드버스터 예제**