Недовірений ввід: валідація, honeypot, екранування XSS

Що робимо сьогодні

Модуль I · IT Skills (Cloud Services & Cyber Security) · тема 2, урок 2 з 2 · 120 хвилин

На минулому уроці ти зібрав ланцюжок «форма → Apps Script → твій сервер». І навчив ~/www/api/inbox.php питати токен. Тепер туди летить те, що ти не контролюєш. Чужі браузери, чужі скрипти, боти. І однокласник, який дуже хоче побачити своє ім’я в чужому вікні alert().

Головне правило уроку. Дані, що прийшли ззовні, — ворожі, доки не доведено протилежне. Не «підозрілі», не «можливо неправильні», а ворожі. Доводить протилежне не форма в браузері, а твій код на сервері.

Після уроку ти вмієш

• перевіряти кожне поле на сервері: чи прийшло, який тип, яка довжина;
• виводити чуже ім’я на сторінку так, щоб тег у ньому лишився текстом;
• ставити у формі поле-пастку, яке заповнюють тільки боти;
• обмежувати довжину, розмір тіла й частоту запитів і відповідати 413, 422, 429;
• ламати власний обробник шістьма атаками й записувати, що вийшло.

Слова «валідація», XSS, «екранування» і honeypot поки нічого не означають — розберемо їх по черзі.

Хід уроку

Ввід приходить не з форми. Він приходить з мережі

Найдорожча ілюзія початківця — «у формі стоїть required, отже поле не буде порожнім»

Твій inbox.php не бачить форми. Він бачить HTTP-запит: метод, заголовки, тіло. Форма в браузері — лише один із багатьох способів такий запит зібрати. Інші способи не менш законні й доступні кожному:

• curl у терміналі — три секунди, жодного браузера;
• DevTools: правий клік по полю → «Edit as HTML» → maxlength зникає;
• вкладка Network → «Copy as cURL» → редагуєш тіло → відправляєш знову;
• скрипт на Python або Apps Script, який шле тисячу запитів за хвилину;
• чужа сторінка, яка шле форму на твій URL.

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

Ні required, ні type="email", ні maxlength тут не брали участі. Єдине, що стоїть між цим запитом і твоїм файлом даних, — чотири перевірки на сервері.

Шість питань до кожного поля

Валідація — не «почистити рядок», а відповісти «так» або «ні» і не мати третього варіанта

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

Білий список проти чорного

Чорний список перелічує заборонене: «викидаємо <script>, слово alert, символ <». Такий список завжди неповний. Перелічити всі шкідливі варіанти неможливо. А обійти конкретний варіант легко:

Білий список перелічує дозволене. «Клас — одне з трьох значень». «Вік — ціле від 6 до 120». «Ім’я — від 2 до 60 символів». Усе інше відсікається без розбору. Вгадувати, що придумає атакувальник, не треба. Ти описуєш скінченну множину доброго, а не нескінченну множину поганого.

Дві пастки саме в PHP

Перша: strlen() рахує байти, а не символи. У UTF-8 кожна українська літера — це два байти. Тому strlen('Олена') дає 10, а mb_strlen('Олена') — 5. Постав ліміт довжини через strlen — і половина класу не впише своє прізвище. А англомовний спамер пройде вільно.

Друга: власна регулярка для email. Повний формат адреси описаний у RFC 5322, і він дуже складний. «Коротка регулярка» або відсікає живі адреси, або пропускає сміття. У PHP уже є перевірка, яку супроводжують за тебе:

// ✗ рахує байти: «Олена» = 10, «Володимир» = 18
if (strlen($name) > 60) { ... }

// ✓ рахує символи
if (mb_strlen($name, 'UTF-8') > 60) { ... }

// ✗ своя регулярка: відкидає живі адреси, пропускає сміття
if (!preg_match('/^\w+@\w+\.\w+$/', $email)) { ... }

// ✓ фільтр, який супроводжує спільнота PHP
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) { ... }

Максимальна довжина адреси теж не вигадана. RFC 5321 обмежує шлях відправника 256 октетами разом із кутовими дужками. На саму адресу лишається 254 символи. Це і є розумний max для поля email.

Конструктор валідації

Задай правила для полів — отримай готовий фрагмент inbox.php і одразу побач, що крізь нього проходить, а що ні

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

Згенерований фрагмент

Прогін тестових значень

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

XSS: чому чужий текст стає твоїм кодом

Браузер не бачить різниці між розміткою, яку написав ти, і розміткою, яка приїхала з чужої форми

Сторінка /leads/ будується просто: беремо рядок з файлу й вставляємо в HTML. Для браузера немає «даних» і «коду». Є один потік символів, який він читає зліва направо. Побачив <, за ним літеру — почався тег. Тег script — виконати вміст. Атрибут onerror — виконати при помилці завантаження.

Візьмімо рядок <img src=x onerror=alert(1)> у полі «Ім’я». Потрапив у HTML без екранування — і він уже не ім’я. Він елемент сторінки. Картинки x не існує, тож спрацьовує onerror. Чужий JavaScript виконується у твоєму домені.

Це і є суть XSS (cross-site scripting). Чужий скрипт виконується на твоїй сторінці — отже, має всі права твоєї сторінки. Він читає її cookie, якщо на них не стоїть HttpOnly. Бачить, що на екрані. І робить запити від імені відвідувача, який зараз залогінений.

Два різні сценарії

Екранувати при виводі, а не при вводі

Це не стильова вподоба, а різниця між цілими даними й зіпсованими

Деякі символи щось означають для браузера. Екранування — це заміна таких символів на записи, які означають просто себе. < стає <. Браузер малює на екрані знак «менше», а не початок тега.

Чому саме на виході

Пісочниця XSS

Одне поле — дві панелі. Ліворуч видно, що рядок став частиною розмітки; праворуч — що він лишився текстом

Порівняй дві панелі уважно. У сховищі — однаковий рядок. Різниця виникає рівно в одному рядку коду сторінки /leads/: чи пройшло значення через htmlspecialchars() перед тим, як стати HTML.

Один рядок — чотири різні екранування

«Я ж поставив htmlspecialchars» — цього достатньо рівно в одному з чотирьох місць

Екранування залежить від того, куди ти вставляєш значення. Браузер читає текст сторінки за одними правилами, атрибут — за іншими. Ще інші правила в URL і всередині <script>. Тому й «небезпечні символи» в кожному місці свої.

Як це виглядає у твоєму leads/index.php

<?php
// єдине місце, де народжується HTML-екранування
function h(?string $s): string {
    return htmlspecialchars((string)$s, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
}
?>
<li>
  <!-- 1. текст сторінки -->
  <b><?= h($r['name'] ?? '') ?></b>

  <!-- 2. значення атрибута: лапки обов’язкові -->
  <span title="<?= h($r['class'] ?? '') ?>"><?= h($r['class'] ?? '') ?></span>

  <!-- 3. частина URL: інший кодувальник -->
  <a href="/leads/?class=<?= rawurlencode($r['class'] ?? '') ?>">такі самі</a>
</li>

Honeypot: поле, яке заповнюють тільки боти

Найдешевший фільтр у всьому ланцюжку — і найтихіший

Спамерський бот не дивиться на сторінку очима. Він завантажує HTML, знаходить усі <input> і заповнює їх підряд. Причина проста: порожнє поле може виявитись обов’язковим, і форма не відправиться. На цьому й будується пастка. Додаємо поле, якого людина фізично не бачить, і чекаємо. Порожнє — швидше за все людина. Заповнене — точно не вона.

Як зробити правильно

Чому не type="hidden"

Приховане поле — це штатний механізм HTML для службових значень: CSRF-токен, ідентифікатор форми, крок майстра. Бот це знає. Такі поля він відправляє назад як є, не чіпаючи. Інакше зламає половину форм в інтернеті. Тому пастка з type="hidden" ніколи не спрацює. А ось <input type="text">, прихований класом, для бота — звичайне текстове поле, яке треба заповнити.

/* у зовнішньому style.css, не інлайном */
.hp { position: absolute; left: -9999px; width: 1px; height: 1px;
      overflow: hidden; }

<!-- у формі -->
<div class="hp" aria-hidden="true">
  <label for="website">Не заповнюйте це поле</label>
  <input type="text" id="website" name="website"
         tabindex="-1" autocomplete="off">
</div>

// в inbox.php — одразу після розбору JSON
if (trim((string)($data['website'] ?? '')) !== '') {
    // та сама відповідь, що й при успіху
    http_response_code(200);
    header('Content-Type: application/json');
    echo '{"ok":true}';
    exit;                     // але в leads.jsonl нічого не пішло
}

Ліміти: довжина, розмір тіла, частота

Валідація захищає дані. Ліміти захищають сам сервер — диск, пам’ять і твою квоту

Поле без обмеження довжини — це запрошення надіслати мегабайт. Адреса без обмеження частоти — запрошення надіслати мільйон запитів. Жоден із них не «зламає» код. Вони просто заповнять диск і з’їдять процесор. І покладуть твій сабдомен разом із сусідами по серверу.

Дещо обмежено вже до тебе. nginx за замовчуванням не пропускає тіло більше 1 МБ (client_max_body_size 1m) і сам віддає 413. Типовий php.ini ставить post_max_size = 8M і max_input_vars = 1000. Це страховка від зовсім грубих речей, а не твій ліміт. Мегабайт у полі «Ім’я» — усе одно катастрофа.

Що означають ці коди

Різниця 400 і 422 варта окремого речення. 400 — «я не зміг це прочитати». 422 — «я прочитав, зрозумів, і воно не годиться». Разом із 422 корисно віддавати перелік полів із помилками, щоб фронтенд підсвітив саме їх.

<?php
declare(strict_types=1);

// 0. те саме, що на уроці 3: __DIR__ = ~/www/api, два рівні вгору = ~
$home  = dirname(__DIR__, 2);
$env   = @parse_ini_file($home . '/.env');
$token = $env['WEBHOOK_TOKEN'] ?? '';

function fail(int $code, string $why): never {
    http_response_code($code);
    header('Content-Type: application/json');
    echo json_encode(['ok' => false, 'error' => $why], JSON_UNESCAPED_UNICODE);
    exit;
}

// 1. метод — одне порівняння рядків
if (($_SERVER['REQUEST_METHOD'] ?? '') !== 'POST') { fail(405, 'only POST'); }

// 2. розмір тіла — до того, як щось читати
if ((int)($_SERVER['CONTENT_LENGTH'] ?? 0) > 65536) { fail(413, 'body too large'); }

// 3. токен із ~/.env; hash_equals не «зливає» відповідь через час порівняння
$got = $_SERVER['HTTP_X_AUTH_TOKEN'] ?? '';
if ($got === '')                  { fail(401, 'no token'); }
if (!hash_equals($token, $got))   { fail(403, 'bad token'); }

// 4. ліміт частоти: 20 запитів з одного IP за годину
$ip   = $_SERVER['REMOTE_ADDR'] ?? '0.0.0.0';
$file = $home . '/data/rate/' . hash('sha256', $ip) . '.txt';
$now  = time();
$hits = is_readable($file)
      ? array_filter(explode(',', trim(file_get_contents($file))),
                     fn($t) => $now - (int)$t < 3600)
      : [];
if (count($hits) >= 20) {
    header('Retry-After: 600');
    fail(429, 'too many requests');
}
$hits[] = $now;
file_put_contents($file, implode(',', $hits), LOCK_EX);

// 5. і тільки тепер розбираємо тіло
$data = json_decode(file_get_contents('php://input'), true);
if (!is_array($data)) { fail(400, 'not json'); }

Журнал атак: tests.md

«Я перевірив, усе працює» — це не перевірка. Перевірка — це список рядків «що робив → що очікував → що сталося»

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

Третя колонка — найважливіша, і саме її найчастіше підганяють під другу. Якщо очікував 422, а отримав 200 — так і пиши, а поруч додай рядок про те, що виправив. Розбіжність між очікуваним і фактичним — це і є результат роботи; журнал без жодної розбіжності зазвичай означає, що тестів не було.

Обидві частини важливі: код відповіді і те, що сталося з файлом. Обробник, який чесно віддає 422, а рядок усе одно дописує, — найгірший із можливих варіантів, бо виглядає він бездоганно.

Практика: захистити й зламати

Кроки 1—11 — у редакторі на твоєму комп’ютері, 12—14 — проти живого сабдомена. Галочки зберігаються, сторінку можна закрити.

Автоперевірка

Чекер робить із твоїм ендпойнтом рівно те саме, що робив ти сам: шле погані запити й дивиться на код відповіді та на файл даних. Спроби не обмежені.

Демонстраційний режим: результат згенеровано для показу. На сервері ця кнопка викликає POST /api/check, який запускає /opt/lessons/04/check.sh від імені учня.

Що вчитель дивиться на твоєму екрані

• DevTools на твоїй формі: поле-пастка справді існує в розмітці, приховане класом із зовнішнього CSS, а не type="hidden" і не інлайновим стилем;
• при звичайному надсиланні форми в цьому полі порожньо — видно у вкладці Network, у тілі запиту;
• сторінка /leads/ з реальним записом, що містить тег: учитель дивиться «View source» і бачить <script>;
• tests.md відкрито поруч із терміналом: будь-який тест із журналу повторюється просто зараз і дає той самий код;
• ти пояснюєш своїми словами кожен рядок, який згенерував Antigravity, — насамперед порядок перевірок і чому honeypot стоїть після токена, а не перед ним.

Шкала виконання

Це те, що бачить учитель, коли виставляє оцінку.

Чотири речення, які варто запам’ятати

• клієнтська перевірка — це зручність для чесного користувача, захист живе тільки на сервері;
• білий список описує скінченну множину дозволеного, чорний — нескінченну множину поганого, і завжди програє;
• екранують при виводі, і саме тим кодувальником, якого вимагає контекст;
• honeypot відповідає таким самим 200, як і успіх, — інакше він сам себе видає.

Де найчастіше помиляються

• вся валідація лишилась у HTML (required, type="email") — прямий POST проходить її наскрізь;
• екранування зроблено на вході: у leads.jsonl лежить <, дані зіпсовані, а при повторному виводі з’являється <;
• довжина рахується через strlen — українські імена «задовгі» вдвічі;
• honeypot названо honeypot і сховано інлайновим display:none;
• боту повертається 403 з поясненням — фактично інструкція, як обійти пастку;
• перевірка токена стоїть після розбору JSON — найдорожча робота робиться для запитів, які й так буде відкинуто;
• обробник повертає 422 і все одно дописує рядок: забули exit.

Домашнє завдання

Дописати в ~/www/api/tests.md ще три власні негативні тести з фактичними кодами відповіді — такі, яких сьогодні на уроці не було. Наприклад: поле class зі значенням 10Ж; тіло, яке взагалі не є JSON; двадцять п’ять запитів поспіль і перевірка 429.

Для кожного — три рядки: команда, очікуваний код, фактичний результат разом із кількістю рядків у leads.jsonl до і після.

Звідки взяті правила й числа

Усе на цій сторінці — з офіційної документації, стандартів і матеріалів OWASP. Перевіряти дозволено й корисно.

• OWASP · Cross Site Scripting Prevention Cheat Sheet — правило «екранувати при виводі» і різні кодувальники для тексту, атрибута, URL і JavaScript. cheatsheetseries.owasp.org
• OWASP · Input Validation Cheat Sheet — білий список проти чорного, перелік того, що перевіряють у кожному полі. cheatsheetseries.owasp.org
• OWASP · Cross Site Scripting (XSS) — збережений, відбитий і DOM-based. owasp.org/www-community/attacks/xss
• PHP · htmlspecialchars — перелік символів, прапорці ENT_QUOTES, ENT_SUBSTITUTE і зміна типових прапорців у 8.1. php.net/htmlspecialchars
• PHP · filter_var і FILTER_VALIDATE_EMAIL. php.net/filter.filters.validate
• PHP · mb_strlen — чому символи, а не байти. php.net/mb_strlen
• PHP · hash_equals — порівняння рядків за сталий час. php.net/hash_equals
• RFC 9110 · HTTP Semantics — коди 400, 401, 405, 413 Content Too Large, 422 Unprocessable Content. datatracker.ietf.org/rfc9110
• RFC 6585 · Additional HTTP Status Codes — 429 Too Many Requests і заголовок Retry-After. datatracker.ietf.org/rfc6585
• RFC 5321 · SMTP — обмеження шляху 256 октетами, звідки береться максимум 254 символи для адреси. datatracker.ietf.org/rfc5321
• nginx · client_max_body_size — типове значення 1m і відповідь 413. nginx.org/docs
• PHP · post_max_size і max_input_vars. php.net/ini.core
• MDN · Content Security Policy — другий рубіж після екранування. developer.mozilla.org/CSP
• MDN · aria-hidden — чому пастку треба ховати і від екранного диктора теж. developer.mozilla.org/aria-hidden
• Кримінальний кодекс України, стаття 361 — несанкціоноване втручання в роботу інформаційних (автоматизованих), електронних комунікаційних, інформаційно-комунікаційних систем. zakon.rada.gov.ua

Повний розбір із поясненнями, що саме звідки взято, — у файлі urok-04-джерела.md поруч із цією сторінкою.