CRLF (%0D%0A) Injection
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Bug bounty tip: sign up for Intigriti, a premium bug bounty platform created by hackers, for hackers! Join us at https://go.intigriti.com/hacktricks today, and start earning bounties up to $100,000!
Перенос каретки (CR) та переведення рядка (LF), разом відомі як CRLF, є спеціальними послідовностями символів, які використовуються в протоколі HTTP для позначення кінця рядка або початку нового. Веб-сервери та браузери використовують CRLF для розрізнення між HTTP-заголовками та тілом відповіді. Ці символи універсально використовуються в комунікаціях HTTP/1.1 на різних типах веб-серверів, таких як Apache та Microsoft IIS.
Вразливість CRLF injection полягає у вставці символів CR та LF у введення, надане користувачем. Ця дія вводить в оману сервер, додаток або користувача, змушуючи їх інтерпретувати вставлену послідовність як кінець однієї відповіді та початок іншої. Хоча ці символи не є inherently шкідливими, їхнє неправильне використання може призвести до розділення HTTP-відповідей та інших шкідливих дій.
Розгляньте файл журналу в адміністративній панелі, який має формат: IP - Time - Visited Path. Типовий запис може виглядати так:
Атакуючий може використати CRLF-ін'єкцію для маніпуляції цим журналом. Впроваджуючи символи CRLF у HTTP-запит, атакуючий може змінити вихідний потік і підробити записи журналу. Наприклад, впроваджена послідовність може перетворити запис журналу на:
Тут %0d та %0a представляють URL-кодовані форми CR та LF. Після атаки журнал помилково відображатиме:
Атакуючий таким чином маскує свої зловмисні дії, змушуючи виглядати так, ніби localhost (суб'єкт, як правило, довірений у середовищі сервера) виконує ці дії. Сервер інтерпретує частину запиту, що починається з %0d%0a, як один параметр, тоді як параметр restrictedaction розбирається як інший, окремий вхід. Маніпульований запит ефективно імітує легітимну адміністративну команду: /index.php?page=home&restrictedaction=edit
HTTP Response Splitting — це вразливість безпеки, яка виникає, коли атакуючий експлуатує структуру HTTP-відповідей. Ця структура відокремлює заголовки від тіла за допомогою специфічної послідовності символів, Carriage Return (CR), за якою слідує Line Feed (LF), що разом називається CRLF. Якщо атакуючий зможе вставити послідовність CRLF у заголовок відповіді, він може ефективно маніпулювати наступним вмістом відповіді. Цей тип маніпуляції може призвести до серйозних проблем безпеки, зокрема Cross-site Scripting (XSS).
Додаток встановлює користувацький заголовок, наприклад: X-Custom-Header: UserInput
Додаток отримує значення для UserInput з параметра запиту, скажімо, "user_input". У сценаріях, де відсутня належна валідація та кодування вхідних даних, атакуючий може створити корисне навантаження, яке містить послідовність CRLF, за якою слідує зловмисний вміст.
Атакуючий створює URL з особливо підготовленим 'user_input': ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>
У цьому URL, %0d%0a%0d%0a є URL-кодованою формою CRLFCRLF. Це обманює сервер, змушуючи його вставити послідовність CRLF, змушуючи сервер сприймати наступну частину як тіло відповіді.
Сервер відображає введення атакуючого в заголовку відповіді, що призводить до ненавмисної структури відповіді, де зловмисний скрипт інтерпретується браузером як частина тіла відповіді.
Браузер до:
І сервер відповідає заголовком:
Інший приклад: (з https://www.acunetix.com/websitesecurity/crlf-injection/)
Ви можете надіслати payload всередині URL шляху, щоб контролювати відповідь від сервера (приклад з тут):
Check more examples in:
HTTP Header Injection, часто експлуатоване через CRLF (Carriage Return and Line Feed) injection, дозволяє зловмисникам вставляти HTTP заголовки. Це може підривати механізми безпеки, такі як фільтри XSS (Cross-Site Scripting) або SOP (Same-Origin Policy), що потенційно призводить до несанкціонованого доступу до чутливих даних, таких як CSRF токени, або маніпуляції сесіями користувачів через вставку cookie.
Зловмисник може вставити HTTP заголовки, щоб активувати CORS (Cross-Origin Resource Sharing), обходячи обмеження, накладені SOP. Цей злом дозволяє скриптам з шкідливих джерел взаємодіяти з ресурсами з іншого джерела, потенційно отримуючи доступ до захищених даних.
CRLF injection може бути використано для створення та вставки абсолютно нового HTTP запиту. Помітним прикладом цього є вразливість у класі SoapClient PHP, зокрема в параметрі user_agent. Маніпулюючи цим параметром, зловмисник може вставити додаткові заголовки та вміст тіла, або навіть вставити новий HTTP запит повністю. Нижче наведено приклад PHP, що демонструє цю експлуатацію:
Для отримання додаткової інформації про цю техніку та потенційні проблеми перевірте оригінальне джерело.
Ви можете інжектувати необхідні заголовки, щоб забезпечити, що бекенд зберігає з'єднання відкритим після відповіді на початковий запит:
Після цього можна вказати другий запит. Цей сценарій зазвичай включає HTTP request smuggling, техніку, де додаткові заголовки або елементи тіла, додані сервером після ін'єкції, можуть призвести до різних безпекових експлойтів.
Експлуатація:
Ін'єкція зловмисного префікса: Цей метод передбачає отруєння запиту наступного користувача або веб-кешу, вказуючи зловмисний префікс. Приклад цього:
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1
Створення префікса для отруєння черги відповідей: Цей підхід передбачає створення префікса, який, у поєднанні з залишковим сміттям, формує повний другий запит. Це може викликати отруєння черги відповідей. Приклад:
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1
Memcache є сховищем ключ-значення, яке використовує протокол у відкритому тексті. Більше інформації в:
11211 - Pentesting MemcacheДля отримання повної інформації прочитайте оригінальну статтю
Якщо платформа бере дані з HTTP запиту і використовує їх без очищення для виконання запитів до memcache сервера, зловмисник може зловживати цією поведінкою, щоб впроваджувати нові команди memcache.
Наприклад, у виявленій уразливості ключі кешу використовувалися для повернення IP-адреси та порту, до яких користувач повинен підключитися, і зловмисники змогли впроваджувати команди memcache, які отруювали кеш, щоб надсилати деталі жертв (включаючи імена користувачів та паролі) на сервери зловмисника:
Більше того, дослідники також виявили, що вони можуть десинхронізувати відповіді memcache, щоб надсилати IP-адреси та порти зловмисника користувачам, чиї електронні адреси зловмисник не знав:
Щоб зменшити ризики CRLF (перенос рядка та переведення каретки) або HTTP Header Injections у веб-додатках, рекомендуються такі стратегії:
Уникати прямого введення користувача в заголовках відповіді: Найбезпечніший підхід - утримуватися від включення введення, наданого користувачем, безпосередньо в заголовки відповіді.
Кодувати спеціальні символи: Якщо уникнути прямого введення користувача неможливо, обов'язково використовуйте функцію, призначену для кодування спеціальних символів, таких як CR (перенос рядка) і LF (переведення каретки). Ця практика запобігає можливості ін'єкції CRLF.
Оновити мову програмування: Регулярно оновлюйте мову програмування, що використовується у ваших веб-додатках, до останньої версії. Обирайте версію, яка за замовчуванням забороняє ін'єкцію символів CR і LF у функціях, призначених для встановлення HTTP заголовків.
Порада для баг-баунті: зареєструйтесь на Intigriti, преміум платформі для баг-баунті, створеній хакерами для хакерів! Приєднуйтесь до нас на https://go.intigriti.com/hacktricks сьогодні та почніть заробляти винагороди до $100,000!
Вчіться та практикуйте Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Вчіться та практикуйте Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
