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 передбачає вставку символів CR та LF у введення, надане користувачем. Ця дія вводить в оману сервер, додаток або користувача, змушуючи їх інтерпретувати впроваджену послідовність як кінець однієї відповіді та початок іншої. Хоча ці символи не є inherently шкідливими, їхнє неналежне використання може призвести до розділення HTTP-відповідей та інших шкідливих дій.
Розгляньте файл журналу в адміністративній панелі, який має формат: IP - Час - Відвіданий шлях. Типовий запис може виглядати так:
Атакуючий може використати ін'єкцію 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)
