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

# 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 Request Queue Desynchronisation

По-перше, ця техніка **зловживає вразливістю HTTP Request Smuggling**, тому вам потрібно знати, що це таке:

**Головна** **різниця** між цією технікою та звичайним HTTP Request smuggling полягає в тому, що **замість** **атаки** на **запит** **жертви** **додаванням префікса до нього**, ми будемо **викрадати або модифікувати відповідь, яку отримує жертва**. Це робиться шляхом, замість того, щоб надіслати 1 запит і півтора для зловживання HTTP Request smuggling, **надіслати 2 повних запити для десинхронізації черги відповідей проксі**.

Це тому, що ми зможемо **десинхронізувати чергу відповідей**, так що **відповідь** від **легітимного** **запиту** **жертви буде надіслана атакуючому**, або шляхом **впровадження контролюваного атакуючим вмісту у відповідь жертві**.

### HTTP Pipeline Desync

HTTP/1.1 дозволяє запитувати **різні ресурси без необхідності чекати на попередні**. Тому, якщо в середині є **проксі**, це завдання проксі - **підтримувати синхронізовану відповідність запитів, надісланих на бекенд, і відповідей, що надходять з нього**.

Однак є проблема з десинхронізацією черги відповідей. Якщо атакуючий надішле атаку HTTP Response smuggling і відповіді на **початковий запит і на контрабандний** будуть надані негайно, контрабандна відповідь не буде вставлена в чергу відповідей жертви, а просто **буде відкинута як помилка**.

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

Отже, потрібно, щоб **контрабандний** **запит** **потребував більше часу для обробки** на бекенд-сервері. Таким чином, до моменту обробки контрабандного запиту зв'язок з атакуючим буде завершено.

Якщо в цій конкретній ситуації **жертва надіслала запит** і **контрабандний запит отримав відповідь раніше** легітимного запиту, **контрабандна відповідь буде надіслана жертві**. Таким чином, атакуючий буде **контролювати запит, "виконаний" жертвою**.

Більше того, якщо **атакуючий потім виконає запит** і **легітимна відповідь** на **запит жертви** буде **надана** **раніше** запиту атакуючого. **Відповідь жертви буде надіслана атакуючому**, **викрадаючи** відповідь жертви (яка може містити, наприклад, заголовок **Set-Cookie**).

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

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

### Multiple Nested Injections

Ще одна **цікава різниця** з звичайним **HTTP Request Smuggling** полягає в тому, що в звичайній атаці на контрабанду **мета** полягає в тому, щоб **модифікувати початок запиту жертви**, щоб він виконував несподівану дію. У **HTTP Response smuggling attack**, оскільки ви **надсилаєте повні запити**, ви можете **впроваджувати в один корисний вантаж десятки відповідей**, які будуть **десинхронізувати десятки користувачів**, які будуть **отримувати** **впроваджені** **відповіді**.

Окрім можливості **легше розподілити десятки експлойтів** серед легітимних користувачів, це також може бути використано для виклику **DoS** на сервері.

### Exploit Organisation

Як було пояснено раніше, щоб зловживати цією технікою, потрібно, щоб **перше контрабандне повідомлення** на сервер **потребувало багато часу для обробки**.

Цей **часомісткий запит є достатнім**, якщо ми просто хочемо **спробувати вкрасти відповідь жертви**. Але якщо ви хочете виконати більш складний експлойт, це буде звичайна структура для експлойту.

По-перше, **початковий** запит, що зловживає **HTTP** **Request** **smuggling**, потім **часомісткий запит**, а потім **1 або більше запитів з корисним вантажем**, відповіді на які будуть надіслані жертвам.

## Abusing HTTP Response Queue Desynchronisation

### Capturing other users' requests <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>)

Потім **жертва** отримає **відповідь** на **сонний** запит, і якщо в цей час **атакуючий** **надіслав** **інший** **запит**, **відповідь на запит з відображеним вмістом буде надіслана йому**.

## Response Desynchronisation

На даний момент ми дізналися, як зловживати атаками HTTP Request Smuggling, щоб **контролювати** **запит**, **відповідь** на який **клієнт** збирається **отримати**, і як ви можете потім **вкрасти відповідь, яка була призначена жертві**.

Але все ще можливо **десинхронізувати навіть** більше відповідей.

Є цікаві запити, такі як **HEAD** запит, які вказані, щоб не мати **жодного вмісту всередині тіла відповіді** і які повинні (повинні) **містити Content-Length** запиту, як **якщо це був GET запит**.

Отже, якщо атакуючий **впроваджує** **HEAD** запит, як на цих зображеннях:

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

Тоді, **як тільки синій запит буде наданий атакуючому**, наступний запит жертви буде введено в чергу:

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

Тоді **жертва** отримає **відповідь** з **HEAD** запиту, яка **міститиме Content-Length, але жодного вмісту**. Отже, проксі **не надішле цю відповідь** жертві, а **чекатиме** на деякий **вміст**, який насправді буде **відповіддю на жовтий запит** (також впроваджений атакуючим):

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

### Content Confusion

Слідуючи попередньому прикладу, знаючи, що ви можете **контролювати тіло** запиту, відповідь на який отримає жертва, і що **HEAD** **відповідь** зазвичай містить у своїх заголовках **Content-Type і Content-Length**, ви можете **надіслати запит, подібний до наступного**, щоб **викликати XSS** у жертви, не роблячи сторінку вразливою до XSS:

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

### Cache Poisoning

Зловживаючи раніше обговореною десинхронізацією відповіді Content Confusion атаки, **якщо кеш зберігає відповідь на запит, виконаний жертвою, і ця відповідь є впровадженою, що викликає XSS, тоді кеш отруєний**.

Зловмисний запит, що містить корисний вантаж XSS:

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

Зловмисна відповідь жертві, що містить заголовок, який вказує кешу зберігати відповідь:

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

> [!WARNING]
> Зверніть увагу, що в цьому випадку, якщо **"жертва" є атакуючим**, він тепер може виконувати **отруєння кешу на довільних URL-адресах**, оскільки він може **контролювати URL-адресу, яка буде кешована** з зловмисною відповіддю.

### Web Cache Deception

Ця атака схожа на попередню, але **замість впровадження корисного вантажу всередині кешу, атакуючий буде кешувати інформацію жертви всередині кешу:**

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

### Response Splitting

**Мета** цієї атаки полягає в тому, щоб знову зловживати **десинхронізацією** **відповіді** для того, щоб **змусити проксі надіслати 100% відповідь, згенеровану атакуючим**.

Щоб досягти цього, атакуючий повинен знайти кінцеву точку веб-додатку, яка **відображає деякі значення у відповіді** і **знати довжину вмісту відповіді HEAD**.

Він надішле **експлойт** на зразок:

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

Після того, як перший запит буде вирішено і надіслано назад атакуючому, **запит жертви буде додано в чергу**:

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

Жертва отримає у відповідь **HEAD відповідь + вміст відповіді другого запиту (що містить частину відображених даних):**

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

Однак зверніть увагу, як **відображені дані мали розмір відповідно до Content-Length** **HEAD** відповіді, яка **згенерувала дійсну HTTP відповідь у черзі відповідей**.

Отже, **наступний запит другого жертви** отримає у відповідь щось, повністю створене атакуючим. Оскільки відповідь повністю створена атакуючим, він також може **змусити проксі кешувати відповідь**.

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