hacktricks/pentesting-web/http-response-smuggling-desync.md

# HTTP 응닑 스머글링 / 디싱크

<details>

<summary><strong>htARTE (HackTricks AWS Red Team Expert)를 통해 AWS 해킹을 제로부터 전문가까지 배우세요</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

HackTricks를 지원하는 다른 방법:

* **회사를 HackTricks에서 광고하거나 HackTricks를 PDF로 다운로드**하려면 [**구독 요금제**](https://github.com/sponsors/carlospolop)를 확인하세요!
* [**공식 PEASS & HackTricks 스웨그**](https://peass.creator-spring.com)를 구매하세요
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)를 발견하세요, 당사의 독점 [**NFTs**](https://opensea.io/collection/the-peass-family) 컬렉션
* **💬 [**Discord 그룹**](https://discord.gg/hRep4RUj7f) 또는 [**텔레그램 그룹**](https://t.me/peass)에 가입하거나** 트위터** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**를 팔로우하세요**.
* **HackTricks** 및 **HackTricks Cloud** github 저장소에 PR을 제출하여 **해킹 트릭을 공유하세요**.

</details>

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

## HTTP 요청 큐 디싱크로나이제이션

먼저, 이 기술은 **HTTP 요청 스머글링 취약점을 악용**하므로 이를 알아야 합니다:

이 기술과 일반적인 HTTP 요청 스머글링의 **주요 차이점**은 **피해자의 요청에 접두사를 추가하여 공격하는 대신**, **피해자가 받는 응닑을 유출하거나 수정**한다는 것입니다. 이는 HTTP 요청 스머글링을 악용하기 위해 1개의 요청과 반을 보내는 대신, **2개의 완전한 요청을 보내어 프록시 응닑 큐를 디싱크로나이즈**하는 것입니다.

이는 **응닑 큐를 디싱크로나이즈**하여 **피해자의 정당한 요청의 응닑이 공격자에게 전송되거나, 응답에 공격자가 제어하는 콘텐츠를 주입**할 수 있기 때문입니다.

### HTTP 파이프라인 디싱크

HTTP/1.1은 **이전 것을 기다리지 않고도 다른 리소스를 요청**할 수 있도록 합니다. 따라서 **중간에 프록시가 있는 경우**, 백엔드로 보낸 요청과 그에 대한 응답을 **동기화된 매치로 유지**하는 것이 프록시의 역할입니다.

그러나 응닑 큐를 디싱크로나이즈하는 문제가 있습니다. 공격자가 HTTP 응닑 스머글링 공격을 보내고 **초기 요청과 스머글된 요청에 대한 응답이 즉시 도착하는 경우**, 스머글된 응닑은 피해자 응답 큐에 삽입되지 않고 **오류로 처리**됩니다.

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

따라서 **스머글된 요청이 백엔드 서버에서 처리되기까지 더 많은 시간이 필요**합니다. 따라서 스머글된 요청이 처리될 때까지 공격자와의 통신이 끝나게 됩니다.

특정 상황에서 **피해자가 요청을 보내고** **스머글된 요청이 정당한 요청보다 먼저 응답되는 경우**, **스머글된 응답이 피해자에게 전송**됩니다. 따라서 공격자는 **피해자가 "수행한" 요청을 제어**하게 됩니다.

또한, **공격자가 요청을 수행하고** **피해자에 대한 정당한 응답이** **공격자의 요청보다 먼저 응답되는 경우** **피해자에 대한 응답이 공격자에게 전송**되어 **피해자의 응답을 탈취**할 수 있습니다(예: **Set-Cookie** 헤더가 포함될 수 있음).

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

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

### 다중 중첩 주입

일반적인 **HTTP 요청 스머글링**과의 **흥미로운 차이점**은, 일반적인 스머글링 공격에서 **피해자 요청의 시작 부분을 수정**하여 예상치 못한 작업을 수행하는 것이 목표입니다. **HTTP 응닑 스머글링 공격**에서는 **전체 요청을 보내므로 한 번의 페이로드에 수십 개의 응답을 주입**하여 **수십 명의 사용자를 디싱크로나이즈**하고 **주입된 응답을 받게** 할 수 있습니다.

합법적인 사용자들에게 **더 쉽게 수십 개의 악용을 분배**할 수 있을 뿐만 아니라 서버에 **DoS**를 유발할 수도 있습니다.

### 악용 조직

이 기술을 악용하기 위해서는 **서버로 보내는 첫 번째 스머글된 메시지가 처리되기까지 많은 시간이 필요**합니다.

이 **시간 소모적인 요청은 피해자의 응답을 탈취하려는 경우에 충분**합니다. 그러나 더 복잡한 악용을 수행하려면 이것이 악용의 일반적인 구조가 될 것입니다.

먼저 **HTTP 요청 스머글링을 악용하는 초기 요청**, 그런 다음 **시간 소모적인 요청**, 그리고 **페이로드 요청 1개 이상**이 피해자에게 전송될 응답입니다.

## HTTP 응닑 큐 디싱크 악용

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

알려진 HTTP 요청 스머글링 페이로드와 마찬가지로, 이 경우 **피해자의 요청을 탈취**할 수 있지만 중요한 차이점이 있습니다: 이 경우 **응답에 반영될 내용을 보내기만 하면 되며, 지속적인 저장소가 필요하지 않습니다**.

먼저, 공격자는 **마지막 POST 요청에 반영된 매개변수가 포함된 페이로드**를 보내고 큰 Content-Length를 포함합니다.

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

그런 다음, **초기 요청**(파란색)이 **처리**되고 **sleepy** 요청(노란색)이 처리되는 동안 **피해자로부터 도착한 다음 요청**이 **반영된 매개변수 바로 뒤에 큐에 추가**됩니다:

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

그런 다음 **피해자**는 **sleepy** 요청에 대한 **응답을 받게** 되며, 그 사이에 **공격자가 다른 요청을 보냈다면**, **반영된 내용 요청에 대한 응답이 그에게 전송**됩니다.

## 응답 디싱크로나이제이션

지금까지 HTTP 요청 스머글링 공격을 악용하여 **클라이언트가 받을 요청을 제어**하고, 그 후 **피해자를 위해 응답을 탈취**하는 방법을 배웠습니다.

그러나 **응답을 더욱 더 디싱크로나이즈**할 수 있습니다.

**HEAD** 요청과 같이 **응답 본문에 어떤 내용도 포함되어서는 안 되는** 흥미로운 요청이 있습니다. 이 요청은 **GET 요청인 것처럼 Content-Length을 포함**해야 합니다.

따라서 공격자가 이러한 이미지와 같이 **HEAD** 요청을 주입하면:

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

그런 다음 **파란색 요청이 공격자에게 응답된 후**, 다음 피해자 요청이 큐에 추가됩니다:

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

그런 다음 **피해자**는 **HEAD** 요청에 대한 **응답을 받게** 되며, 이 응답은 **Content-Length는 포함하지만 내용이 전혀 없을 것**입니다. 따라서 프록시는 이 응답을 피해자에게 보내지 않고 **일부 내용을 기다리게 되며, 실제로는 공격자가 주입한 노란색 요청에 대한 응답**이 될 것입니다:

![](<../.gitbook/assets/image (735).png>)
### 내용 혼란

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

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

### 캐시 독려

이전에 설명한 응답 비동기화 내용 혼란 공격을 악용하면 **캐시가 희생자가 수행한 요청에 대한 응답을 저장하고 이 응답이 XSS를 유발하는 주입된 응답인 경우, 그러면 캐시가 독려된다**.

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

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

캐시에 응답을 저장하도록 지시하는 헤더를 포함하는 희생자에 대한 악의적인 응답:

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

{% hint style="warning" %}
이 경우 **"희생자"가 공격자인 경우** 이제 **악의적인 응답으로 캐시될 URL을 제어**할 수 있기 때문에 **임의의 URL에 대해 캐시 독려**를 수행할 수 있습니다.
{% endhint %}

### 웹 캐시 속임수

이 공격은 이전 공격과 유사하지만 **캐시 내에 피해자 정보를 캐싱하는 대신 공격자가 피해자 정보를 캐싱**합니다:

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

### 응답 분할

이 공격의 **목표**는 다시 한 번 **응답 비동기화를 악용하여 프록시가 100% 공격자가 생성한 응답을 보내도록 하는 것**입니다.

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

그는 다음과 같은 **exploit**을 보낼 것입니다:

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

첫 번째 요청이 해결되고 공격자에게 다시 보내지면 **희생자의 요청이 대기열에 추가**됩니다:

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

희생자는 **HEAD 응답 + 두 번째 요청 응답의 내용(반영된 데이터 일부를 포함)**을 응답으로 받게 될 것입니다:

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

그러나 **반영된 데이터가 HEAD 응답의 Content-Length에 따라 크기가 있었음**을 주목하십시오. 이는 **응답 대기열에서 유효한 HTTP 응답을 생성**했습니다.

따라서 **두 번째 희생자의 다음 요청**은 **공격자가 완전히 조작한 응답을 받게 될 것**입니다. 응답이 공격자에 의해 완전히 조작되었기 때문에 **프록시가 응답을 캐시**할 수도 있습니다.