# HTTP Response Smuggling / Desync
Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!
Інші способи підтримки HackTricks:
* Якщо ви хочете побачити вашу **компанію рекламовану в HackTricks** або **завантажити HackTricks у форматі PDF**, перевірте [**ПЛАНИ ПІДПИСКИ**](https://github.com/sponsors/carlospolop)!
* Отримайте [**офіційний PEASS & HackTricks мерч**](https://peass.creator-spring.com)
* Відкрийте для себе [**Сім'ю PEASS**](https://opensea.io/collection/the-peass-family), нашу колекцію ексклюзивних [**NFT**](https://opensea.io/collection/the-peass-family)
* **Приєднуйтесь до** 💬 [**групи Discord**](https://discord.gg/hRep4RUj7f) або [**групи telegram**](https://t.me/peass) або **слідкуйте** за нами на **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Поділіться своїми хакерськими трюками, надсилайте PR до** [**HackTricks**](https://github.com/carlospolop/hacktricks) та [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) репозиторіїв GitHub.
**Техніка цього посту була взята з відео:** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)
## Десинхронізація черги HTTP-запитів
По-перше, ця техніка **зловживає вразливістю HTTP-запиту на підмішування**, тому вам потрібно знати, що це таке:
**Основна** **відмінність** між цією технікою та звичайним підмішуванням HTTP-запитів полягає в тому, що **замість атаки запиту жертви, додавши до нього префікс**, ми збираємося **витікати або змінювати відповідь, яку отримує жертва**. Це робиться шляхом відправлення не 1 запиту та півтора для зловживання підмішуванням HTTP-запитів, а **відправлення 2 повних запитів для десинхронізації черги відповідей проксі**.
Це тому, що ми зможемо **десинхронізувати чергу відповідей**, так що **відповідь від законного запиту жертви буде відправлена зловмиснику**, або шляхом **впровадження контенту, керованого зловмисником, відповідь буде відправлена жертві**.
### Десинхронізація черги HTTP-каналів
HTTP/1.1 дозволяє запитувати **різні ресурси без очікування попередніх**. Тому, якщо є **проксі** посередині, це завдання проксі - **підтримувати синхронізоване відповідність відправлених запитів до сервера та отриманих від нього відповідей**.
Однак є проблема десинхронізації черг відповідей. Якщо зловмисник відправить атаку підмішування HTTP-відповідей і відповіді на **початковий запит та підмішаний запит будуть відповідати негайно**, підмішана відповідь не буде вставлена в чергу відповідей жертви, а **просто буде відкинута як помилка**.
 (1) (1) (1).png>)
Тому потрібно, щоб **підмішаний запит займав більше часу для обробки** на сервері. Таким чином, до моменту обробки підмішаного запиту спілкування з зловмисником буде завершено.
Якщо в цій конкретній ситуації **жертва відправила запит**, а **підмішаний запит відповідає раніше**, ніж законний запит, **підмішана відповідь буде відправлена жертві**. Таким чином, зловмисник буде **контролювати запит, "виконаний" жертвою**.
Більше того, якщо **зловмисник виконує запит**, а **легітимна відповідь на запит жертви відповідає раніше** **запиту зловмисника**, **відповідь жертві буде відправлена зловмиснику**, **викрадаючи** відповідь жертві (яка може містити, наприклад, заголовок **Set-Cookie**).
 (1).png>)
 (1) (1) (1).png>)
### Кілька Вкладених Впроваджень
Ще одна **цікава відмінність** від звичайного **підмішування HTTP-запитів** полягає в тому, що в звичайній атакі підмішування, **мета** полягає в **зміні початку запитів жертви**, щоб вони виконали неочікувану дію. У **атаках підмішування HTTP-відповідей**, оскільки ви **відправляєте повні запити**, ви можете **впроваджувати в одному пакеті десятки відповідей**, які будуть **десинхронізувати десятки користувачів**, які будуть **отримувати** **впроваджені** **відповіді**.
Крім можливості **розподілити більш легко десятки експлойтів** серед законних користувачів, це також може бути використано для спричинення **DoS** на сервері.
### Організація Експлойтів
Як пояснено раніше, для зловживання цією технікою потрібно, щоб **перше підмішане повідомлення** на сервері **вимагало багато часу для обробки**.
Цей **запит, який займає багато часу для обробки**, достатній, якщо ми просто хочемо **спробувати вкрасти відповідь жертви**. Але якщо ви хочете виконати більш складний експлойт, це буде загальною структурою для експлойту.
По-перше **початковий** запит, який зловживає **підмішуванням HTTP-запитів**, потім **запит, який займає багато часу**, і потім **1 або більше запитів з вмістом**, відповіді на які будуть відправлені жертвам.
## Зловживання десинхронізацією черги відповідей HTTP
### Захоплення запитів інших користувачів
Як і з відомими пакетами для підмішування HTTP-запитів, ви можете **вкрасти запити жертви** з однією важливою відмінністю: у цьому випадку вам просто потрібно, щоб **відправлений вміст відображався в відповіді**, **не потрібно постійного зберігання**.
Спочатку зловмисник відправляє пакет, що містить **останній POST-запит з відображеним параметром** в кінці та великим Content-Length
.png>)
Потім, коли **початковий запит** (синій) був **оброблений**, і **поки** **сплячий** запит обробляється (жовтий), **наступний запит, який надходить від жертви**, буде **доданий в чергу відразу після відображеного параметра**:
 (1).png>)
Потім **жертва** отримає **відповідь на сплячий** запит, і якщо за цей час **зловмисник відправить інший запит**, **відповідь на запит з відображеним вмістом буде відправлена йому**.
## Десинхронізація відповідей
До цього моменту ми вивчили, як зловживати атаками підмішування HTTP-запитів, щоб **контролювати запит**, **відповідь на який клієнт отримає**, і як ви можете потім **вкрасти відповідь, яка була призначена для жертви**.
Але все ще можливо **ще більше десинхронізувати відповіді**.
Є цікаві запити, такі як **HEAD**, які вказують, що **в тілі відповіді не повинно бути жодного вмісту**, і вони повинні (мають) **містити Content-Length** запиту, як **у випадку GET-запиту**.
Тому, якщо зловмисник **впроваджує** **HEAD**-запит, як на цих зображеннях:
.png>)
Тоді, **після того, як синій запит відповів зловмиснику**, наступний запит жертви буде введений в чергу:
 (1) (1) (1) (1) (1) (1).png>)
Потім **жертва** отримає **відповідь** на **HEAD**-запит, яка **буде містити Content-Length, але жодного вмісту** взагалі. Тому проксі **не відправить цю відповідь** жертві, а **почекає на якийсь вміст**, який фактично буде **відповіддю на жовтий запит** (також введений зловмисником):
 (1).png>)
### Плутанина контенту
Відомо, що ви можете **контролювати тіло** запиту, відповідь на який отримає жертва, і що **HEAD** **відповідь** зазвичай містить у своїх заголовках **Content-Type та Content-Length**, ви можете **надіслати запит, подібний до наступного**, щоб **спричинити XSS** у жертви без того, щоб сторінка була вразливою до XSS:
%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\).png)
### Отруєння кешу
Зловживання раніше згаданою атакою плутанини контенту відповіді, **якщо кеш зберігає відповідь на запит, виконаний жертвою, і ця відповідь є впровадженою, що спричиняє XSS, то кеш отруєний**.
Зловмисний запит, що містить навантаження XSS:
 (1).png>)
Зловмисна відповідь жертві, яка містить заголовок, що вказує кешу зберегти відповідь:
 (1).png>)
{% hint style="warning" %}
Зверніть увагу, що в цьому випадку, якщо **"жертва" є атакуючим**, він тепер може виконувати **отруєння кешу в довільних URL** так, як він може **контролювати URL, який буде збережений в кеші** за допомогою зловмисної відповіді.
{% endhint %}
### Обман веб-кешу
Ця атака схожа на попередню, але **замість впровадження навантаження всередині кешу, атакуючий буде кешувати інформацію жертви всередині кешу:**
 (1) (1).png>)
### Розділення відповіді
**Мета** цієї атаки полягає в зловживанні знову **розділенням відповіді** для того, щоб **проксі відправив відповідь, яка була 100% згенерована атакуючим**.
Для досягнення цього атакуючому потрібно знайти кінцеву точку веб-застосунку, яка **відображає деякі значення всередині відповіді** та **знати довжину вмісту HEAD-відповіді**.
Він надішле **експлойт** такий:
 (1) (1) (1).png>)
Після того, як перший запит вирішено і відправлено атакуючому, **запит жертви додається в чергу**:
 (1) (1) (1).png>)
Жертва отримає відповідь у вигляді **HEAD-відповіді + вмісту відповіді другого запиту (що містить частину відображених даних):**
 (1).png>)
Проте, зверніть увагу, що **відображені дані мали розмір відповідно до Content-Length** **HEAD** відповіді, що **згенерувала дійсну HTTP-відповідь у черзі відповідей**.
Отже, **наступний запит другої жертви** буде **отримувати** як **відповідь щось повністю створене атакуючим**. Оскільки відповідь повністю створена атакуючим, він також може **змусити проксі кешувати відповідь**.