HTTP Connection Contamination

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

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

• Якщо ви хочете побачити вашу компанію в рекламі на HackTricks або завантажити HackTricks у PDF Перевірте ПЛАНИ ПІДПИСКИ!

• Отримайте офіційний PEASS & HackTricks мерч

• Відкрийте Сім'ю PEASS, нашу колекцію ексклюзивних NFT

• Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами на Twitter 🐦 @carlospolopm.

• Поділіться своїми хакерськими трюками, надсилайте PR до HackTricks та HackTricks Cloud репозиторіїв GitHub.

Це краткий огляд публікації: https://portswigger.net/research/http-3-connection-contamination. Перевірте його для отримання додаткових деталей!

Веб-браузери можуть використовувати одне HTTP/2+ з'єднання для різних веб-сайтів через забруднення HTTP-з'єднання, за умови спільних IP-адрес та спільного сертифіката TLS. Однак це може конфліктувати з маршрутизацією першого запиту в обернених проксі-серверах, де наступні запити спрямовані до бекенду, визначеного першим запитом. Це неправильне маршрутизування може призвести до вразливостей безпеки, особливо коли поєднано з універсальними сертифікатами TLS та доменами, такими як *.example.com.

Наприклад, якщо wordpress.example.com та secure.example.com обслуговуються одним оберненим проксі-сервером та мають спільний універсальний сертифікат, забруднення з'єднання браузера може призвести до того, що запити до secure.example.com неправильно обробляються бекендом WordPress, використовуючи вразливості, такі як XSS.

Для спостереження за забрудненням з'єднання можна використовувати вкладку Мережа Chrome або інструменти, такі як Wireshark. Ось фрагмент для тестування:

fetch('//sub1.hackxor.net/', {mode: 'no-cors', credentials: 'include'}).then(()=>{ fetch('//sub2.hackxor.net/', {mode: 'no-cors', credentials: 'include'}) })

Загроза наразі обмежена через рідкість маршрутизації першого запиту та складність HTTP/2. Однак запропоновані зміни в HTTP/3, які послаблюють вимогу відповідності IP-адрес, можуть розширити поверхню атаки, зробляючи сервери з універсальним сертифікатом більш вразливими без необхідності атаки MITM.

Найкращі практики включають уникання маршрутизації першого запиту в зворотних проксі-серверах та обережне використання універсальних TLS-сертифікатів, особливо з появою HTTP/3. Регулярне тестування та усвідомлення цих складних взаємопов'язаних вразливостей є важливими для забезпечення безпеки веб-сайту.