Атака, яку ніхто не бачить, приходить через форму контактів твого сайту

Усі захищають вхід до системи. Ніхто не дивиться на форму контактів. А проте вона приймає введення від будь-кого, без автентифікації, без тертя, часто навіть без ліміту надсилань.

Саме цієї асиметрії шукає зловмисник. Текстове поле, що розмовляє з твоїм поштовим сервером, з твоєю базою даних або з внутрішнім вебхуком. Ти бачиш поле «повідомлення». Він бачить командний рядок.

Чому ця ціль така спокуслива

Форма контактів поєднує три рідкісні властивості в одному місці. Приймає ненадійне введення. Виконує логіку на сервері. І майже ніколи не проходить аудит. Розробник перевірив, що повідомлення доходить на пошту. На цьому й зупинився.

Проблема в тому, що «повідомлення доходить на пошту» ховає цілий шлях. Текст користувача збирається всередині заголовка SMTP, склеюється в запит або надсилається до стороннього сервісу. Кожна з цих меж — це можливість для ін'єкції.

Ін'єкція поштових заголовків

Класичний випадок називається email header injection. Якщо ти береш поле «тема» чи «відправник» і вставляєш його прямо в заголовок повідомлення, зловмисник пише розрив рядка й додає власні заголовки. Наприклад, Bcc на тисячу адрес.

Раптом твій сервер розсилає спам. Не від твого імені випадково, а буквально через твою інфраструктуру, з твоїм IP і твоїм доменом. Результат передбачуваний: великі провайдери позначають твій домен як джерело спаму, і твоя робоча пошта перестає доходити хоч кудись.

Текст, що стає кодом

Далі йдуть гірші сценарії. Якщо ти зберігаєш повідомлення в базу даних без параметризації запиту, ти відчиняєш двері SQL injection. Якщо показуєш повідомлення в адмін-панелі без екранування HTML, зловмисник садить скрипт, що виконується в браузері твоєї команди, коли вона відкриває лід. Це збережений XSS, і це один із найбільш недооцінених векторів, що існують.

Зверни увагу на закономірність. У жодному з цих випадків зловмисник нічого не «зламав». Він скористався формою рівно так, як вона задумана для використання. Уразливість — це не якийсь екзотичний збій. Це відсутність одного простого правила: ніколи не довіряй тому, що надходить.

Що робити, за порядком пріоритету

Тобі не потрібен WAF чи консультант з безпеки, щоб закрити 90 відсотків цього. Тобі потрібна дисципліна в чотирьох пунктах.

• Перевіряй на сервері, ніколи лише в браузері. Валідація на фронтенді — це зручність для користувача, а не безпека. Зловмисник не користується твоєю формою, він робить POST прямо на ендпоінт.
• Екрануй на виході, завжди. Записуючи в базу даних, використовуй параметризовані запити. Показуючи в панелі, екрануй HTML. Стався до кожного повідомлення як до ворожого, доки не доведено протилежне.
• Відхиляй розриви рядків у полях заголовків. Тема, ім'я та email не мають підстав містити \r чи \n. Відфільтруй їх, перш ніж торкатися SMTP.
• Обмеж частоту надсилань і додай невидимий виклик. Rate limiting за IP і honeypot чи hCaptcha зупиняють автоматичних ботів, не псуючи досвід тим, хто є людиною.

І та частина, про яку майже всі забувають

Форма контактів збирає персональні дані. Ім'я, email, часто телефон і зміст повідомлення. Це ставить тебе всередину GDPR, подобається тобі це чи ні. Тобі потрібна правова підстава для обробки цих даних, а згода має бути поінформованою.

На практиці це означає три конкретні речі. Чітку примітку про приватність, прив'язану до форми. Визначену правову підставу, зазвичай легітимний інтерес зі статті 6 або явну згоду. І політику зберігання, бо тримати ліди назавжди — це не стратегія, а накопичена відповідальність. Якщо в тебе вкрадуть базу лідів, проблема перестане бути технічною й стане регуляторною.

Безпека форми — це не дорогий firewall. Це твоя відмова довіряти тексту, який написав незнайомець.— Krivar Diário

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