<summary><strong>Вивчайте хакінг AWS від нуля до героя з</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Якщо ви хочете побачити вашу **компанію рекламовану в HackTricks**або**завантажити HackTricks у форматі PDF**, перевірте [**ПЛАНИ ПІДПИСКИ**](https://github.com/sponsors/carlospolop)!
* Відкрийте для себе [**Сім'ю PEASS**](https://opensea.io/collection/the-peass-family), нашу колекцію ексклюзивних [**NFT**](https://opensea.io/collection/the-peass-family)
**Техніка цього посту була взята з відео:** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)
**Основна** **відмінність** між цією технікою та звичайним підмішуванням HTTP-запитів полягає в тому, що **замість атаки запиту жертви, додавши до нього префікс**, ми збираємося **витікати або змінювати відповідь, яку отримує жертва**. Це робиться шляхом відправлення не 1 запиту та півтора для зловживання підмішуванням HTTP-запитів, а**відправлення 2 повних запитів для десинхронізації черги відповідей проксі**.
Це тому, що ми зможемо **десинхронізувати чергу відповідей**, так що **відповідь від законного запиту жертви буде відправлена зловмиснику**, або шляхом **впровадження контенту, керованого зловмисником, відповідь буде відправлена жертві**.
HTTP/1.1 дозволяє запитувати **різні ресурси без очікування попередніх**. Тому, якщо є **проксі** посередині, це завдання проксі - **підтримувати синхронізоване відповідність відправлених запитів до сервера та отриманих від нього відповідей**.
Однак є проблема десинхронізації черг відповідей. Якщо зловмисник відправить атаку підмішування HTTP-відповідей і відповіді на **початковий запит та підмішаний запит будуть відповідати негайно**, підмішана відповідь не буде вставлена в чергу відповідей жертви, а**просто буде відкинута як помилка**.
Тому потрібно, щоб **підмішаний запит займав більше часу для обробки** на сервері. Таким чином, до моменту обробки підмішаного запиту спілкування з зловмисником буде завершено.
Якщо в цій конкретній ситуації **жертва відправила запит**, а**підмішаний запит відповідає раніше**, ніж законний запит, **підмішана відповідь буде відправлена жертві**. Таким чином, зловмисник буде **контролювати запит, "виконаний" жертвою**.
Більше того, якщо **зловмисник виконує запит**, а**легітимна відповідь на запит жертви відповідає раніше****запиту зловмисника**, **відповідь жертві буде відправлена зловмиснику**, **викрадаючи** відповідь жертві (яка може містити, наприклад, заголовок **Set-Cookie**).
Ще одна **цікава відмінність** від звичайного **підмішування HTTP-запитів** полягає в тому, що в звичайній атакі підмішування, **мета** полягає в **зміні початку запитів жертви**, щоб вони виконали неочікувану дію. У**атаках підмішування HTTP-відповідей**, оскільки ви **відправляєте повні запити**, ви можете **впроваджувати в одному пакеті десятки відповідей**, які будуть **десинхронізувати десятки користувачів**, які будуть **отримувати****впроваджені****відповіді**.
Крім можливості **розподілити більш легко десятки експлойтів** серед законних користувачів, це також може бути використано для спричинення **DoS** на сервері.
Цей **запит, який займає багато часу для обробки**, достатній, якщо ми просто хочемо **спробувати вкрасти відповідь жертви**. Але якщо ви хочете виконати більш складний експлойт, це буде загальною структурою для експлойту.
По-перше **початковий** запит, який зловживає **підмішуванням HTTP-запитів**, потім **запит, який займає багато часу**, і потім **1 або більше запитів з вмістом**, відповіді на які будуть відправлені жертвам.
Як і з відомими пакетами для підмішування HTTP-запитів, ви можете **вкрасти запити жертви** з однією важливою відмінністю: у цьому випадку вам просто потрібно, щоб **відправлений вміст відображався в відповіді**, **не потрібно постійного зберігання**.
Потім, коли **початковий запит** (синій) був **оброблений**, і**поки****сплячий** запит обробляється (жовтий), **наступний запит, який надходить від жертви**, буде **доданий в чергу відразу після відображеного параметра**:
Потім **жертва** отримає **відповідь на сплячий** запит, і якщо за цей час **зловмисник відправить інший запит**, **відповідь на запит з відображеним вмістом буде відправлена йому**.
До цього моменту ми вивчили, як зловживати атаками підмішування HTTP-запитів, щоб **контролювати запит**, **відповідь на який клієнт отримає**, і як ви можете потім **вкрасти відповідь, яка була призначена для жертви**.
Є цікаві запити, такі як **HEAD**, які вказують, що **в тілі відповіді не повинно бути жодного вмісту**, і вони повинні (мають) **містити Content-Length** запиту, як **у випадку GET-запиту**.
Потім **жертва** отримає **відповідь** на **HEAD**-запит, яка **буде містити Content-Length, але жодного вмісту** взагалі. Тому проксі **не відправить цю відповідь** жертві, а**почекає на якийсь вміст**, який фактично буде **відповіддю на жовтий запит** (також введений зловмисником):
Відомо, що ви можете **контролювати тіло** запиту, відповідь на який отримає жертва, і що **HEAD****відповідь** зазвичай містить у своїх заголовках **Content-Type та Content-Length**, ви можете **надіслати запит, подібний до наступного**, щоб **спричинити XSS**у жертви без того, щоб сторінка була вразливою до XSS:
Зловживання раніше згаданою атакою плутанини контенту відповіді, **якщо кеш зберігає відповідь на запит, виконаний жертвою, і ця відповідь є впровадженою, що спричиняє XSS, то кеш отруєний**.
Зверніть увагу, що в цьому випадку, якщо **"жертва" є атакуючим**, він тепер може виконувати **отруєння кешу в довільних URL** так, як він може **контролювати URL, який буде збережений в кеші** за допомогою зловмисної відповіді.
**Мета** цієї атаки полягає в зловживанні знову **розділенням відповіді** для того, щоб **проксі відправив відповідь, яка була 100% згенерована атакуючим**.
Для досягнення цього атакуючому потрібно знайти кінцеву точку веб-застосунку, яка **відображає деякі значення всередині відповіді** та **знати довжину вмісту HEAD-відповіді**.
Проте, зверніть увагу, що **відображені дані мали розмір відповідно до Content-Length****HEAD** відповіді, що **згенерувала дійсну HTTP-відповідь у черзі відповідей**.
Отже, **наступний запит другої жертви** буде **отримувати** як **відповідь щось повністю створене атакуючим**. Оскільки відповідь повністю створена атакуючим, він також може **змусити проксі кешувати відповідь**.
