# HTTP Response Smuggling / Desync

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

**이 게시물의 기술은 다음 비디오에서 가져왔습니다:** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](https://www.youtube.com/watch?v=suxDcYViwao&t=1343s)

## HTTP 요청 대기열 비동기화

우선, 이 기술은 **HTTP Request Smuggling 취약점**을 **악용**하므로, 그것이 무엇인지 알아야 합니다:

이 기술과 일반적인 HTTP Request Smuggling의 **주요 차이점**은 **희생자의 요청에 접두사를 추가하여 공격하는 대신**, 우리는 **희생자가 받는 응답을 유출하거나 수정할 것**이라는 점입니다. 이는 HTTP Request Smuggling을 악용하기 위해 1.5개의 요청을 보내는 대신, **프록시 응답 대기열을 비동기화하기 위해 2개의 완전한 요청을 보냄으로써** 이루어집니다.

이는 우리가 **응답 대기열을 비동기화**할 수 있기 때문에 **희생자의 정당한 요청의 응답이 공격자에게 전송되거나**, **희생자에게 응답하는 내용에 공격자가 제어하는 콘텐츠를 주입**할 수 있기 때문입니다.

### HTTP 파이프라인 비동기화

HTTP/1.1은 **이전 요청을 기다리지 않고도 다양한 리소스를 요청할 수** 있습니다. 따라서, **중간에 프록시**가 있다면, 프록시의 작업은 **백엔드에 전송된 요청과 그로부터 오는 응답을 동기화된 상태로 유지하는 것**입니다.

그러나 응답 대기열을 비동기화하는 데 문제가 있습니다. 공격자가 HTTP Response Smuggling 공격을 보내고 **초기 요청과 밀반입된 요청에 대한 응답이 즉시 응답**되면, 밀반입된 응답은 희생자의 응답 대기열에 삽입되지 않고 **단순히 오류로 폐기**됩니다.

![](<../images/image (633).png>)

따라서, **밀반입된 요청이 백엔드 서버에서 처리되는 데 더 많은 시간이 걸리도록** 해야 합니다. 따라서 밀반입된 요청이 처리될 때쯤에는 공격자와의 통신이 종료될 것입니다.

특정 상황에서 **희생자가 요청을 보냈고** **밀반입된 요청이 정당한 요청보다 먼저 응답**되면, **밀반입된 응답이 희생자에게 전송**됩니다. 따라서 공격자는 **희생자가 "수행한" 요청을 제어하게 됩니다**.

게다가, **공격자가 요청을 수행하고** **희생자 요청에 대한 정당한 응답이** **공격자의 요청보다 먼저 응답**되면, **희생자에 대한 응답이 공격자에게 전송**되어 **희생자에 대한 응답을 훔치게 됩니다** (예를 들어, **Set-Cookie** 헤더를 포함할 수 있습니다).

![](<../images/image (1020).png>)

![](<../images/image (719).png>)

### 다중 중첩 주입

일반적인 **HTTP Request Smuggling**과의 또 다른 **흥미로운 차이점**은, 일반적인 밀반입 공격에서는 **목표가 희생자의 요청 시작 부분을 수정하여 예상치 못한 행동을 수행하게 하는 것**입니다. **HTTP Response Smuggling 공격**에서는 **전체 요청을 보내기 때문에**, **하나의 페이로드에 수십 개의 응답을 주입**하여 **수십 명의 사용자를 비동기화**할 수 있습니다.

정당한 사용자에게 수십 개의 익스플로잇을 **더 쉽게 배포**할 수 있을 뿐만 아니라, 이는 서버에 **DoS**를 유발하는 데도 사용될 수 있습니다.

### 익스플로잇 조직

앞서 설명한 바와 같이, 이 기술을 악용하기 위해서는 **서버에 밀반입된 첫 번째 메시지가 처리되는 데 많은 시간이 걸리도록** 해야 합니다.

이 **시간 소모 요청은** 우리가 **희생자의 응답을 훔치려고 할 때 충분합니다.** 그러나 더 복잡한 익스플로잇을 수행하려면, 이는 익스플로잇의 일반적인 구조가 될 것입니다.

우선 **HTTP Request Smuggling**을 악용한 **초기** 요청, 그 다음 **시간 소모 요청**, 그리고 **희생자에게 전송될 응답을 포함하는 1개 이상의 페이로드 요청**입니다.

## HTTP 응답 대기열 비동기화 악용

### 다른 사용자의 요청 캡처 <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>

HTTP Request Smuggling의 알려진 페이로드와 마찬가지로, **희생자의 요청을 훔칠 수 있습니다**. 한 가지 중요한 차이점은: 이 경우 **응답에 반영될 콘텐츠를 보내기만 하면 되며**, **지속적인 저장소**가 필요하지 않습니다.

먼저, 공격자는 **반영된 매개변수를 포함한 최종 POST 요청**을 포함하는 페이로드를 보내고, 큰 Content-Length를 설정합니다.

![](<../images/image (1053).png>)

그런 다음, **초기 요청**(파란색)이 **처리되고** **수면 중인** 요청이 처리되는 동안(노란색) **희생자로부터 도착하는 다음 요청이 반영된 매개변수 바로 뒤에 대기열에 추가**됩니다:

![](<../images/image (794).png>)

그 후, **희생자**는 **수면 중인** 요청에 대한 **응답을 받게 되고**, 그 사이에 **공격자가 또 다른 요청을 보냈다면**, **반영된 콘텐츠 요청의 응답이 그에게 전송**됩니다.

## 응답 비동기화

지금까지 우리는 HTTP Request Smuggling 공격을 악용하여 **클라이언트가 받을 응답을 제어**하는 방법과, 그 후 **희생자를 위한 응답을 훔치는 방법**을 배웠습니다.

하지만 여전히 응답을 **더 비동기화**할 수 있는 방법이 있습니다.

**HEAD** 요청과 같은 흥미로운 요청이 있으며, 이는 **응답 본문에 아무 콘텐츠도 포함하지 않아야 하며**, **GET 요청인 것처럼 요청의 Content-Length를 포함해야 합니다**.

따라서 공격자가 **HEAD** 요청을 **주입**하면, 다음과 같은 이미지와 같이:

![](<../images/image (1107).png>)

그런 다음, **파란색 요청이 공격자에게 응답**되면, 다음 희생자의 요청이 대기열에 추가됩니다:

![](<../images/image (999).png>)

그 후, **희생자**는 **HEAD** 요청의 **응답을 받게 되며**, 이는 **Content-Length는 포함하지만 콘텐츠는 전혀 포함하지 않을 것입니다**. 따라서 프록시는 **이 응답을 희생자에게 전송하지 않고**, **어떤 콘텐츠**를 기다리게 되며, 이는 실제로 **노란색 요청에 대한 응답**이 될 것입니다(공격자가 주입한):

![](<../images/image (735).png>)

### 콘텐츠 혼란

이전 예제를 따라, **희생자가 받을 응답의 본문을 제어할 수 있고**, **HEAD** **응답**이 일반적으로 **Content-Type과 Content-Length**를 헤더에 포함한다는 것을 알고 있다면, 다음과 같은 요청을 **보내서 희생자에게 XSS를 유발**할 수 있습니다. 페이지가 XSS에 취약하지 않더라도:

![](<../images/image (688).png>)

### 캐시 오염

이전에 언급한 응답 비동기화 콘텐츠 혼란 공격을 악용하여, **캐시가 희생자가 수행한 요청에 대한 응답을 저장하고 이 응답이 XSS를 유발하는 주입된 것이라면, 캐시는 오염됩니다**.

XSS 페이로드를 포함한 악의적인 요청:

![](<../images/image (614).png>)

응답을 저장하라는 헤더를 포함한 희생자에 대한 악의적인 응답:

![](<../images/image (566).png>)

> [!WARNING]
> 이 경우 **"희생자"가 공격자라면**, 그는 이제 **악의적인 응답으로 캐시될 URL을 제어할 수 있으므로 임의의 URL에서 캐시 오염을 수행할 수 있습니다**.

### 웹 캐시 기만

이 공격은 이전 공격과 유사하지만, **캐시에 페이로드를 주입하는 대신 공격자는 캐시 내에 희생자 정보를 저장할 것입니다:**

![](<../images/image (991).png>)

### 응답 분할

이 공격의 **목표**는 다시 **응답 비동기화**를 악용하여 **프록시가 100% 공격자가 생성한 응답을 전송하게 만드는 것**입니다.

이를 달성하기 위해 공격자는 **응답 내에서 일부 값을 반영하는 웹 애플리케이션의 엔드포인트를 찾아야 하며**, **HEAD 응답의 콘텐츠 길이를 알아야 합니다**.

그는 다음과 같은 **익스플로잇**을 보낼 것입니다:

![](<../images/image (911).png>)

첫 번째 요청이 해결되고 공격자에게 전송된 후, **희생자의 요청이 대기열에 추가**됩니다:

![](<../images/image (737).png>)

희생자는 **HEAD 응답 + 두 번째 요청 응답의 콘텐츠(반영된 데이터의 일부 포함)**을 응답으로 받게 됩니다:

![](<../images/image (356).png>)

그러나 **반영된 데이터가 HEAD 응답의 Content-Length에 따라 크기가 조정되어** 응답 대기열에서 유효한 HTTP 응답을 생성했다는 점에 유의하십시오.

따라서 **두 번째 희생자의 다음 요청은** **공격자가 완전히 제작한 응답을 받게 됩니다**. 응답이 공격자에 의해 완전히 제작되었기 때문에, 그는 또한 **프록시가 응답을 캐시하도록 만들 수 있습니다**.

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