У HTTP і в заголовках листів рядки розділяються символами CR LF (\r\n). Якщо дані користувача потрапляють у заголовок без перевірки, зловмисник вставляє \r\n і додає власні заголовки або навіть тіло відповіді.
У відповідях HTTP:
// вразливо при «сирому» формуванні заголовків
header('Location: /profile?lang=' . $_GET['lang']);
// lang = "uk\r\nSet-Cookie: session=attacker"
Наслідки - встановлення cookie жертві (фіксація сесії), підробка заголовків, у крайньому разі «розщеплення відповіді» (response splitting) з власним HTML.
Сучасний PHP уже захищає функцію header(): вона відхиляє значення з переносом рядка і видає попередження. Symfony/Laravel Response теж не дозволяє переносів у заголовках. Тому в сучасних застосунках проблема виникає рідше, але трапляється:
- у власних обгортках над сокетами, проксі, генерації сирих відповідей;
- у логах: перенос рядка у введенні дозволяє дописати фальшивий рядок журналу (log injection) - заплутати розслідування інциденту.
У листах - класична ін'єкція заголовків пошти: форма зворотного зв'язку бере email відправника в заголовок:
email = "user@example.com\r\nBcc: spam1@example.com, spam2@example.com"
Сервер стає розсильником спаму від вашого домену - а домен потрапляє в чорні списки.
Захист:
- валідувати значення, що йдуть у заголовки: email - правилом
email, мова - білим списком; - використовувати бібліотеки, що формують заголовки самі: Laravel Mail (Symfony Mailer) кодує й перевіряє адреси й теми, не дозволяючи переносів;
- відправник листа - ваша адреса, а email користувача - у
Reply-Toпісля валідації, а не вFrom; - логи у структурованому форматі (JSON) - переноси рядків екрануються автоматично;
- ніколи не будувати заголовки конкатенацією з сирих даних - навіть у «внутрішніх» скриптах.
Загальний принцип ін'єкцій: щоразу, коли дані вставляються в текст, який інша система розбирає (SQL, shell, HTML, заголовки, логи), потрібне кодування під цей конкретний формат або API, що розділяє код і дані.
