maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Translator 2025-08-20 19:28:14 +00:00
parent 4fd6a3ae52
commit 0cf390bdeb
1 changed files with 45 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

90
src/pentesting-web/http-request-smuggling/README.md
View File

@ -4,7 +4,7 @@
## What is
이 취약점은 **프론트엔드 프록시**와 **백엔드** 서버 간의 **비동기화**로 인해 **공격자**가 **HTTP 요청**을 **전송**할 수 있게 되며, 이 요청은 **프론트엔드** 프록시(로드 밸런스/리버스 프록시)에서는 **단일 요청**으로 해석되고 **백엔드** 서버에서는 **2개의 요청**으로 해석됩니다.\
이 취약점은 **프론트엔드 프록시**와 **백엔드** 서버 간의 **비동기화**로 인해 **공격자**가 **HTTP 요청**을 **전송**할 수 있게 되며, 이 요청은 **프론트엔드** 프록시(로드 밸런서/리버스 프록시)에서는 **단일 요청**으로 해석되고 **백엔드** 서버에서는 **2개의 요청**으로 해석됩니다.\
이로 인해 사용자는 자신의 요청 이후에 백엔드 서버에 도착하는 **다음 요청을 수정**할 수 있습니다.
### Theory
@ -20,34 +20,34 @@
**Transfer-Encoding: chunked**
> Transfer-Encoding 헤더는 페이로드 본문을 사용자에게 안전하게 전송하는 데 사용되는 인코딩 형식을 지정합니다.\
> Chunked는 큰 데이터가 일련의 청크로 전송됨을 의미합니다.
> 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`
- **Connection**: 제 경험에 따르면 요청 스머글링의 첫 번째 요청에서 **`Connection: keep-alive`**를 사용하는 것이 좋습니다.
- **Transfer-Encoding:** 이 헤더는 본문에서 **16진수**를 사용하여 **다음 청크의 바이트 수**를 나타냅니다. **청크**는 **새 줄**로 **끝나야 하지만** 이 새 줄은 **길이 표시기**에 포함되지 않습니다. 이 전송 방법은 **크기 0의 청크와 2개의 새 줄**로 끝나야 합니다: `0`
- **Connection**: 제 경험에 따르면 요청 스머글링의 첫 번째 요청에서는 **`Connection: keep-alive`**를 사용하는 것이 좋습니다.
## Basic Examples
> [!TIP]
> Burp Suite로 이를 악용하려고 할 때 **`Update Content-Length` 및 `Normalize HTTP/1 line endings`**를 리피터에서 비활성화하세요. 일부 도구는 새 줄, 캐리지 리턴 및 잘못된 content-length를 악용합니다.
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](../../images/EKi5edAUUAAIPIK.jpg)
> [!TIP]
> 이전 표에 TE.0 기술을 추가해야 합니다. CL.0 기술과 유사하지만 Transfer Encoding을 사용합니다.
> 이전 표에 TE.0 기술을 추가해야 하며, CL.0 기술과 유사하지만 Transfer Encoding을 사용합니다.
#### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
@ -57,7 +57,7 @@ HTTP 요청 스머글링 공격은 모호한 요청을 전송하여 프론트엔
- 공격자는 `Content-Length` 헤더의 값이 실제 콘텐츠 길이와 일치하지 않는 요청을 보냅니다.
- 프론트엔드 서버는 `Content-Length` 값을 기반으로 전체 요청을 백엔드로 전달합니다.
- 백엔드 서버는 `Transfer-Encoding: chunked` 헤더로 인해 요청을 청크로 처리하여 나머지 데이터를 별도의 후속 요청으로 해석합니다.
- 백엔드 서버는 `Transfer-Encoding: chunked` 헤더로 인해 요청을 청크로 처리하며, 나머지 데이터를 별도의 후속 요청으로 해석합니다.
- **예시:**
```
@ -104,12 +104,12 @@ x=
#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
- **서버:** 두 서버 모두 `Transfer-Encoding`을 지원하지만, 하나는 난독화를 통해 이를 무시하도록 속일 수 있습니다.
- **서버:** 둘 다 `Transfer-Encoding`을 지원하지만, 하나는 난독화를 통해 이를 무시하도록 속일 수 있습니다.
- **공격 시나리오:**
- 공격자는 난독화된 `Transfer-Encoding` 헤더가 있는 요청을 보냅니다.
- 어떤 서버(프론트엔드 또는 백엔드)가 난독화를 인식하지 못하는지에 따라 CL.TE 또는 TE.CL 취약점이 악용될 수 있습니다.
- 요청의 처리되지 않은 부분은 한 서버에서 후속 요청의 일부가 되어 스머글링으로 이어집니다.
- 요청의 처리되지 않은 부분은 한 서버에서 보았을 때 후속 요청의 일부가 되어 스머글링으로 이어집니다.
- **예시:**
```
@ -131,7 +131,7 @@ Transfer-Encoding
#### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**
- 두 서버 모두 `Content-Length` 헤더만을 기반으로 요청을 처리합니다.
- 두 서버는 요청을 오직 `Content-Length` 헤더만을 기반으로 처리합니다.
- 이 시나리오는 일반적으로 스머글링으로 이어지지 않으며, 두 서버가 요청 길이를 해석하는 방식이 일치합니다.
- **예시:**
@ -146,7 +146,7 @@ Normal Request
#### **CL.0 Scenario**
- `Content-Length` 헤더가 존재하고 0이 아닌 값을 가지며 요청 본문에 콘텐츠가 있음을 나타냅니다. 백엔드는 `Content-Length` 헤더를 무시하고(0으로 처리됨), 프론트엔드는 이를 파싱합니다.
- `Content-Length` 헤더가 존재하고 0이 아닌 값을 가지며 요청 본문에 콘텐츠가 있음을 나타내는 시나리오를 의미합니다. 백엔드는 `Content-Length` 헤더를 무시하고(0으로 처리됨), 프론트엔드는 이를 파싱합니다.
- 이는 스머글링 공격을 이해하고 구성하는 데 중요하며, 서버가 요청의 끝을 결정하는 방식에 영향을 미칩니다.
- **예시:**
@ -223,12 +223,12 @@ A
```
- **관찰:**
- 프론트엔드 서버는 `Content-Length`에 따라 요청을 처리하고 메시지를 조기에 차단합니다.
- 프론트엔드 서버는 `Content-Length`에 따라 요청을 처리하고 메시지를 조기에 잘라냅니다.
- 백엔드 서버는 청크 메시지를 기대하며 도착하지 않는 다음 청크를 기다려 지연이 발생합니다.
- **지표:**
- 응답의 타임아웃 또는 긴 지연.
- 때때로 상세한 서버 정보와 함께 백엔드 서버에서 400 Bad Request 오류를 수신합니다.
- 백엔드 서버로부터 400 Bad Request 오류를 수신하며, 때때로 상세한 서버 정보가 포함됩니다.
### 타이밍 기법을 사용한 TE.CL 취약점 찾기
@ -265,25 +265,25 @@ X
### HTTP 요청 스머글링 취약점 테스트
타이밍 기법의 효과를 확인한 후, 클라이언트 요청을 조작할 수 있는지 확인하는 것이 중요합니다. 간단한 방법은 요청을 오염시키는 것을 시도하는 것입니다. 예를 들어, `/`에 대한 요청이 404 응답을 생성하도록 합니다. 이전에 논의된 `CL.TE` 및 `TE.CL` 예시는 클라이언트의 요청을 오염시켜 404 응답을 유도하는 방법을 보여줍니다.
타이밍 기법의 효과를 확인한 후, 클라이언트 요청을 조작할 수 있는지 확인하는 것이 중요합니다. 간단한 방법은 요청을 오염시키는 것을 시도하는 것입니다. 예를 들어, `/`에 대한 요청이 404 응답을 생성하도록 합니다. 이전에 논의된 `CL.TE` 및 `TE.CL` 예시는 클라이언트의 요청을 오염시켜 404 응답을 유도하는 방법을 보여줍니다. 클라이언트는 다른 리소스에 접근하려고 했음에도 불구하고 말입니다.
**주요 고려사항**
다른 요청에 간섭하여 요청 스머글링 취약점을 테스트할 때 유의해야 할 사항:
- **별도의 네트워크 연결:** "공격" 요청과 "정상" 요청은 별도의 네트워크 연결을 통해 전송되어야 합니다. 두 요청 모두 동일한 연결을 사용하는 것은 취약점의 존재를 검증하지 않습니다.
- **구별된 네트워크 연결:** "공격" 요청과 "정상" 요청은 별도의 네트워크 연결을 통해 전송되어야 합니다. 두 요청 모두 동일한 연결을 사용하는 것은 취약점의 존재를 검증하지 않습니다.
- **일관된 URL 및 매개변수:** 두 요청 모두 동일한 URL 및 매개변수 이름을 사용하도록 합니다. 현대 애플리케이션은 종종 URL 및 매개변수에 따라 특정 백엔드 서버로 요청을 라우팅합니다. 이를 일치시키면 두 요청이 동일한 서버에서 처리될 가능성이 높아지며, 이는 성공적인 공격을 위한 전제 조건입니다.
- **타이밍 및 경합 조건:** "정상" 요청은 "공격" 요청의 간섭을 감지하기 위해 다른 동시 애플리케이션 요청과 경쟁합니다. 따라서 "공격" 요청 직후에 "정상" 요청을 전송합니다. 바쁜 애플리케이션은 취약점 확인을 위한 결론을 내리기 위해 여러 번의 시도가 필요할 수 있습니다.
- **로드 밸런싱 문제:** 로드 밸런서 역할을 하는 프론트엔드 서버는 요청을 다양한 백엔드 시스템에 분배할 수 있습니다. "공격" 요청과 "정상" 요청이 서로 다른 시스템에 도달하면 공격이 성공하지 않습니다. 이 로드 밸런싱 측면은 취약점을 확인하기 위해 여러 번의 시도가 필요할 수 있습니다.
- **의도치 않은 사용자 영향:** 공격이 다른 사용자의 요청(탐지를 위해 보낸 "정상" 요청이 아님)에 영향을 미치는 경우, 이는 공격이 다른 애플리케이션 사용자에게 영향을 미쳤음을 나타냅니다. 지속적인 테스트는 다른 사용자에게 방해가 될 수 있으므로 신중한 접근이 필요합니다.
- **타이밍 및 경합 조건:** "정상" 요청은 "공격" 요청으로 인한 간섭을 감지하기 위해 다른 동시 애플리케이션 요청과 경쟁합니다. 따라서 "정상" 요청은 "공격" 요청 직후에 전송해야 합니다. 바쁜 애플리케이션은 결론적인 취약점 확인을 위해 여러 번의 시도가 필요할 수 있습니다.
- **로드 밸런싱 문제:** 로드 밸런서 역할을 하는 프론트엔드 서버는 요청을 다양한 백엔드 시스템에 분배할 수 있습니다. "공격" 요청과 "정상" 요청이 서로 다른 시스템에 도착하면 공격은 성공하지 않습니다. 이 로드 밸런싱 측면은 취약점을 확인하기 위해 여러 번의 시도가 필요할 수 있습니다.
- **의도치 않은 사용자 영향:** 공격이 다른 사용자의 요청(탐지를 위해 보낸 "정상" 요청이 아님)에 의도치 않게 영향을 미친다면, 이는 공격이 다른 애플리케이션 사용자에게 영향을 미쳤음을 나타냅니다. 지속적인 테스트는 다른 사용자에게 방해가 될 수 있으므로 신중한 접근이 필요합니다.
## HTTP/1.1 파이프라이닝 아티팩트와 진짜 요청 스머글링 구분하기
연결 재사용(keep-alive) 및 파이프라이닝은 동일한 소켓에서 여러 요청을 전송하는 테스트 도구에서 "스머글링"의 환상을 쉽게 생성할 수 있습니다. 무해한 클라이언트 측 아티팩트를 실제 서버 측 비동기화와 구분하는 방법을 배우세요.
### 파이프라이닝이 고전적인 오탐지를 생성하는 이유
### 왜 파이프라이닝이 고전적인 허위 긍정 결과를 생성하는가
HTTP/1.1은 단일 TCP/TLS 연결을 재사용하고 동일한 스트림에서 요청과 응답을 연결합니다. 파이프라이닝에서 클라이언트는 여러 요청을 연속으로 전송하고 순서대로 응답을 기대합니다. 일반적인 오탐지 사례는 잘못된 CL.0 스타일 페이로드를 단일 연결에서 두 번 재전송하는 것입니다:
HTTP/1.1은 단일 TCP/TLS 연결을 재사용하고 동일한 스트림에서 요청과 응답을 연결합니다. 파이프라이닝에서 클라이언트는 여러 요청을 연속으로 전송하고 순서대로 응답을 기대합니다. 일반적인 허위 긍정 결과는 잘못된 CL.0 스타일 페이로드를 단일 연결에서 두 번 재전송하는 것입니다:
```
POST / HTTP/1.1
Host: hackxor.net
@ -365,20 +365,20 @@ Impact: 없음. 클라이언트를 서버 프레이밍에서 분리했습니다.
### 클라이언트 측 비동기화 제약
브라우저 기반/클라이언트 측 비동기화를 목표로 하는 경우, 악의적인 요청은 브라우저 크로스 오리진에 의해 전송 가능해야 합니다. 헤더 난독화 트릭은 작동하지 않습니다. 탐색/가져오기를 통해 도달할 수 있는 원시에 집중한 다음, 캐시 오염, 헤더 노출 또는 프론트 엔드 제어 우회로 pivot하십시오. 하류 구성 요소가 응답을 반영하거나 캐시하는 경우입니다.
브라우저 기반/클라이언트 측 비동기화를 목표로 하는 경우, 악의적인 요청은 브라우저를 통해 교차 출처로 전송 가능해야 합니다. 헤더 난독화 트릭은 작동하지 않습니다. 탐색/가져오기를 통해 도달할 수 있는 원시에 집중한 다음, 캐시 오염, 헤더 노출 또는 프론트 엔드 제어 우회로 pivot하십시오. 하류 구성 요소가 응답을 반영하거나 캐시하는 경우입니다.
배경 및 종단 간 워크플로에 대한 정보:
{{#ref}}
-browser-http-request-smuggling.md
browser-http-request-smuggling.md
{{#endref}}
### 결정에 도움이 되는 도구
- HTTP Hacker (Burp BApp Store): 저수준 HTTP 동작 및 소켓 연결을 노출합니다.
- "스머글링 또는 파이프라인?" Burp Repeater 사용자 정의 작업: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
- Turbo Intruder: `requestsPerConnection`을 통해 연결 재사용에 대한 정밀 제어를 제공합니다.
- Burp HTTP Request Smuggler: 첫 번째 요청 라우팅/검증을 감지하는 연결 상태 프로브를 포함합니다.
- Turbo Intruder: `requestsPerConnection`을 통해 연결 재사용에 대한 정밀한 제어를 제공합니다.
- Burp HTTP Request Smuggler: 첫 번째 요청 라우팅/검증을 감지하기 위한 연결 상태 프로브를 포함합니다.
> [!NOTE]
> 서버 측 비동기화를 증명하고 구체적인 영향을 연결할 수 없는 한 재사용 전용 효과를 비문제로 간주하십시오(오염된 캐시 아티팩트, 권한 우회를 가능하게 하는 내부 헤더 누출, 우회된 프론트 엔드 제어 등).
@ -430,7 +430,7 @@ a=x
### Revealing front-end request rewriting <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 매개변수를 찾습니다. 그런 다음, 이 매개변수를 마지막에 사용하여 다음과 유사한 요청을 작성합니다:
```
@ -449,13 +449,13 @@ Content-Length: 100
search=
```
이 구조에서 후속 요청 구성 요소는 `search=` 뒤에 추가되며, 이는 응답에 반영된 매개변수입니다. 이 반영은 후속 요청의 헤더를 노출시킵니다.
이 구조에서 후속 요청 구성 요소는 `search=` 뒤에 추가되며, 이는 응답에 반영되는 매개변수입니다. 이 반영은 후속 요청의 헤더를 노출시킵니다.
중요한 것은 중첩 요청의 `Content-Length` 헤더를 실제 콘텐츠 길이에 맞추는 것입니다. 작은 값으로 시작하고 점진적으로 증가시키는 것이 좋습니다. 너무 낮은 값은 반영된 데이터를 잘라내고, 너무 높은 값은 요청이 오류를 발생시킬 수 있습니다.
이 기술은 TE.CL 취약점의 맥락에서도 적용 가능하지만, 요청은 `search=\r\n0`으로 종료되어야 합니다. 줄 바꿈 문자와 관계없이 값은 검색 매개변수에 추가됩니다.
이 기술은 TE.CL 취약점의 맥락에서도 적용 가능하지만, 요청은 `search=\r\n0`으로 종료되어야 합니다. 개행 문자와 관계없이 값은 검색 매개변수에 추가됩니다.
이 방법은 주로 프론트엔드 프록시가 수행한 요청 수정 사항을 이해하는 데 사용되며, 본질적으로 자가 주도적인 조사를 수행합니다.
이 방법은 기본적으로 프론트엔드 프록시가 수행한 요청 수정 사항을 이해하는 데 사용되며, 본질적으로 자가 주도 조사를 수행합니다.
### 다른 사용자의 요청 캡처하기 <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
@ -485,11 +485,11 @@ csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40ema
그러나 이 기술에는 한계가 있습니다. 일반적으로, 이는 밀반입된 요청에서 사용된 매개변수 구분자까지의 데이터만 캡처합니다. URL 인코딩된 양식 제출의 경우, 이 구분자는 `&` 문자입니다. 이는 피해자 사용자의 요청에서 캡처된 내용이 첫 번째 `&`에서 멈춘다는 것을 의미하며, 이는 쿼리 문자열의 일부일 수도 있습니다.
또한, 이 접근 방식은 TE.CL 취약점에서도 유효하다는 점에 유의할 가치가 있습니다. 이러한 경우, 요청은 `search=\r\n0`으로 끝나야 합니다. 줄 바꿈 문자와 관계없이 값은 검색 매개변수에 추가됩니다.
또한, 이 접근 방식은 TE.CL 취약점에서도 유효하다는 점에 유의할 필요가 있습니다. 이러한 경우, 요청은 `search=\r\n0`으로 끝나야 합니다. 줄 바꿈 문자와 관계없이 값은 검색 매개변수에 추가됩니다.
### HTTP 요청 밀반입을 사용하여 반사된 XSS를 악용하기
### HTTP 요청 밀반입을 사용하여 반사된 XSS 공격하기
HTTP Request Smuggling은 **Reflected XSS**에 취약한 웹 페이지를 악용하는 데 활용될 수 있으며, 상당한 이점을 제공합니다:
HTTP Request Smuggling은 **Reflected XSS**에 취약한 웹 페이지를 공격하는 데 활용될 수 있으며, 상당한 이점을 제공합니다:
- 대상 사용자와의 상호작용이 **필요하지 않습니다**.
- HTTP 요청 헤더와 같이 **일반적으로 접근할 수 없는** 요청의 일부에서 XSS를 악용할 수 있습니다.
@ -518,10 +518,10 @@ A=
이 페이로드는 취약점을 악용하기 위해 다음과 같이 구조화되었습니다:
1. `Transfer-Encoding: chunked` 헤더가 있는 일반적인 `POST` 요청을 시작하여 밀반입의 시작을 나타냅니다.
2. 이어서 `0`을 추가하여 청크된 메시지 본문의 끝을 표시합니다.
2. 이어서 `0`을 사용하여 청크된 메시지 본문의 끝을 표시합니다.
3. 그런 다음, `User-Agent` 헤더에 `<script>alert(1)</script>` 스크립트를 주입한 밀반입된 `GET` 요청이 도입되어, 서버가 이 후속 요청을 처리할 때 XSS가 트리거됩니다.
`User-Agent`를 밀반입을 통해 조작함으로써, 페이로드는 정상 요청 제약을 우회하여 비표준이지만 효과적인 방식으로 반사된 XSS 취약점을 악용합니다.
밀반입을 통해 `User-Agent`를 조작함으로써, 페이로드는 정상 요청 제약을 우회하여 비표준이지만 효과적인 방식으로 반사된 XSS 취약점을 악용합니다.
#### HTTP/0.9
@ -530,7 +530,7 @@ A=
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로 요청을 밀반입하는 방식으로 악용되었습니다. 응답에 반영될 매개변수는 **유효한 헤더와 본체를 포함한 가짜 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>
@ -544,7 +544,7 @@ Host: normal-website.com
HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/
```
이 행동은 겉보기에는 무해해 보이지만, HTTP request smuggling을 사용하여 사용자를 외부 사이트로 리디렉션하는 데 조작될 수 있습니다. 예를 들어:
비록 무해해 보이지만, 이 행동은 HTTP request smuggling을 사용하여 사용자를 외부 사이트로 리디렉션하는 데 조작될 수 있습니다. 예를 들어:
```
POST / HTTP/1.1
Host: vulnerable-website.com
@ -574,11 +574,11 @@ Location: https://attacker-website.com/home/
### HTTP 요청 스머글링을 통한 웹 캐시 오염 활용 <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
웹 캐시 오염은 **프론트엔드 인프라의 콘텐츠를 캐시**하는 어떤 구성 요소라도 실행될 수 있으며, 일반적으로 성능 향상을 위해 사용됩니다. 서버의 응답을 조작함으로써 **캐시를 오염**시킬 수 있습니다.
웹 캐시 오염은 **프론트엔드 인프라의 콘텐츠를 캐시**하는 어떤 구성 요소라도 있을 경우 실행될 수 있으며, 일반적으로 성능 향상을 위해 사용됩니다. 서버의 응답을 조작함으로써 **캐시를 오염**시킬 수 있습니다.
이전에 서버 응답을 변경하여 404 오류를 반환하는 방법을 관찰했습니다 (참조: [Basic Examples](#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`의 캐시 콘텐츠를 변경하는 것입니다:
```
@ -604,14 +604,14 @@ x=1
그 후, `/static/include.js`에 대한 모든 요청은 공격자의 스크립트의 캐시된 내용을 제공하여 광범위한 XSS 공격을 효과적으로 시작합니다.
### HTTP request smuggling을 사용하여 웹 캐시 기만 수행하기 <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
### 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>
> **웹 캐시 오염과 웹 캐시 기만의 차이점은 무엇인가요?**
>
> - **웹 캐시 오염**에서는 공격자가 애플리케이션이 악성 콘텐츠를 캐시에 저장하도록 유도하고, 이 콘텐츠가 다른 애플리케이션 사용자에게 캐시에서 제공됩니다.
> - **웹 캐시 기만**에서는 공격자가 애플리케이션이 다른 사용자의 민감한 콘텐츠를 캐시에 저장하도록 유도하고, 공격자는 이후 이 콘텐츠를 캐시에서 검색합니다.
공격자는 민감한 사용자 특정 콘텐츠를 가져오는 밀반입 요청을 작성합니다. 다음 예를 고려해 보세요:
공격자는 민감한 사용자 특정 콘텐츠를 가져오는 밀반입 요청을 작성합니다. 다음 예를 고려하세요:
```markdown
`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
@ -622,7 +622,7 @@ x=1
`GET /private/messages HTTP/1.1`\
`Foo: X`
```
이 스머글링된 요청이 정적 콘텐츠(예: `/someimage.png`)를 위한 캐시 항목을 오염시키면, 피해자의 `/private/messages`의 민감한 데이터가 정적 콘텐츠의 캐시 항목 아래에 캐시될 수 있습니다. 결과적으로, 공격자는 이러한 캐시된 민감한 데이터를 검색할 수 있습니다.
이 스머글링된 요청이 정적 콘텐츠(예: `/someimage.png`)를 위한 캐시 항목을 오염시키면, 피해자의 민감한 데이터가 `/private/messages`에서 정적 콘텐츠의 캐시 항목 아래에 캐시될 수 있습니다. 결과적으로, 공격자는 이러한 캐시된 민감한 데이터를 검색할 수 있습니다.
### HTTP 요청 스머글링을 통한 TRACE 남용 <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
@ -632,7 +632,7 @@ TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>
```
I'm ready to assist you with the translation. Please provide the text you would like me to translate.
I'm ready to assist you with the translation. Please provide the text you would like to have translated.
```
HTTP/1.1 200 OK
Content-Type: message/http
@ -643,7 +643,7 @@ Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx
```
이 동작을 악용하는 예는 **먼저 HEAD 요청을 밀어넣는 것**입니다. 이 요청은 GET 요청의 **헤더**만 응답받게 됩니다 (**`Content-Type`** 포함). 그리고 **HEAD 요청 직후에 TRACE 요청을 밀어넣는 것**인데, 이 요청은 **전송된 데이터를 반영하게 됩니다**.\
이 동작을 악용하는 예는 **먼저 HEAD 요청을 밀어넣는 것**입니다. 이 요청은 GET 요청의 **헤더**만 응답받게 됩니다 (**`Content-Type`** 포함). 그리고 **HEAD 요청 직후에 TRACE 요청을 밀어넣는 것**으로, 이는 **전송된 데이터를 반영하게 됩니다**.\
HEAD 응답에는 `Content-Length` 헤더가 포함되므로, **TRACE 요청의 응답은 HEAD 응답의 본문으로 처리되어 임의의 데이터를 반영하게 됩니다**.\
이 응답은 연결을 통해 다음 요청으로 전송되므로, 예를 들어 **캐시된 JS 파일에서 임의의 JS 코드를 주입하는 데 사용될 수 있습니다**.
@ -824,7 +824,7 @@ table.add(req)
- [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/)
- 잘못된 긍정 반응에 주의하세요: HTTP 파이프라이닝과 요청 스머글링을 구별하는 방법 – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
- 잘못된 잘못된 긍정 경고에 주의하세요: HTTP 파이프라이닝과 요청 스머글링을 구별하는 방법 – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
- [https://http1mustdie.com/](https://http1mustdie.com/)
- 브라우저 기반의 비동기 공격 – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
- PortSwigger Academy – 클라이언트 측 비동기 – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)