Пошук уроків, статей та іншого контенту
Дізнайтеся, як Web Application Firewall фільтрує HTTP-трафік і захищає застосунки від поширених атак.
Web Application Firewall (WAF) — це спеціалізований компонент безпеки, який аналізує HTTP-запити та відповіді й блокує ті, що схожі на атаки проти вебзастосунку.
WAF працює на рівні вебтрафіку:
HTTP та HTTPS;
URL і query-параметрів;
HTTP-заголовків;
cookies;
тіла запиту;
іноді — відповіді сервера.
Його основна мета — захистити вебзастосунок від поширених атак без необхідності змінювати код самого застосунку.
Типовий потік запиту виглядає так:
Клієнт
↓
WAF
↓
Reverse proxy або load balancer
↓
Вебзастосунок
↓
База даних та інші сервісиWAF перевіряє запит до того, як він потрапить до застосунку.
WAF зазвичай використовують для виявлення та блокування таких атак:
SQL injection;
Cross-Site Scripting (XSS);
path traversal;
command injection;
небезпечних HTTP-методів;
некоректних або підозрілих заголовків;
спроб завантаження шкідливих файлів;
надто великих або аномальних запитів;
деяких видів бот-активності;
масових запитів до окремих endpoint-ів.
Наприклад, запит із параметром:
/search?q=' OR '1'='1може бути ознакою SQL injection. WAF може заблокувати його ще до того, як запит буде оброблений застосунком.
Інший приклад:
/download?file=../../../../etc/passwdмістить спробу path traversal — виходу за межі дозволеної директорії.
Важливо: WAF не гарантує захист від усіх атак. Він є додатковим шаром захисту, а не заміною безпечного коду, автентифікації, авторизації та валідації даних.
WAF аналізує запит за допомогою набору правил. Правило може перевіряти:
HTTP-метод;
шлях запиту;
query-параметри;
заголовки;
cookies;
тіло запиту;
IP-адресу;
частоту запитів;
репутацію джерела;
попередні порушення з боку клієнта.
Спрощена модель обробки має такий вигляд:
1. Прийняти HTTP-запит
2. Нормалізувати його
3. Перевірити базові обмеження
4. Застосувати правила безпеки
5. Дозволити, заблокувати або записати подіюАтакувальник може намагатися приховати шкідливий фрагмент за допомогою кодування:
%2e%2e%2fПісля декодування це може відповідати:
../Тому WAF часто спочатку нормалізує дані:
декодує URL;
приводить деякі значення до єдиного формату;
обробляє повторне кодування;
перевіряє різні варіанти написання символів.
Без нормалізації правило може не розпізнати атаку.
Найпоширеніші режими WAF:
WAF виявляє підозрілі запити, але не блокує їх. Подія лише записується в журнал.
Цей режим корисний під час початкового налаштування, оскільки дозволяє побачити кількість помилкових спрацьовувань.
Підозрілий запит блокується. Клієнт зазвичай отримує відповідь 403 Forbidden або іншу відповідь, налаштовану оператором.
Перехід до цього режиму варто робити після аналізу журналів і налаштування винятків.
У WAF часто використовують два типи правил.
Це готові набори правил для поширених атак. Вони можуть перевіряти:
ознаки SQL injection;
ознаки XSS;
path traversal;
небезпечні команди;
аномальні заголовки;
некоректні параметри.
Поширеним прикладом набору правил є OWASP Core Rule Set, який використовується разом із сумісними WAF-рішеннями.
Готові правила зменшують обсяг ручної роботи, але можуть створювати false positives — блокувати легітимні запити.
Власні правила враховують особливості конкретного застосунку. Наприклад:
дозволити тільки GET і POST для певного endpoint-а;
обмежити розмір тіла запиту;
вимагати конкретний заголовок;
дозволити певний формат параметра;
блокувати доступ до службового шляху.
Власне правило має бути якомога конкретнішим. Загальне правило на кшталт «заблокувати всі запити зі словом select» може ламати звичайний пошук або текстовий контент.
Нижче наведено навчальний приклад HTTP-сервера на Node.js. Він перевіряє шлях і query-параметри перед передаванням запиту до обробника.
Це не повноцінний production WAF. Його мета — показати загальний принцип: нормалізація, перевірки, журналювання та блокування.
const http = require("node:http");
const { URL } = require("node:url");
const blockedPatterns = [
/<script\b/i, // Ознака простого XSS
/\.\.(?:%2f|\/)/i, // Спроба path traversal
/\bunion\s+select\b/i, // Поширений шаблон SQL injection
/\bor\s+1\s*=\s*1\b/i // Поширений шаблон SQL injection
];
function containsAttackPattern(value) {
return blockedPatterns.some((pattern) => pattern.test(value));
}
const server = http.createServer((request, response) => {
const requestUrl = new URL(
request.url,
`http://${request.headers.host || "localhost"}`
);
const normalizedTarget = decodeURIComponent(
`${requestUrl.pathname}?${requestUrl.searchParams.toString()}`
);
if (request.method !== "GET") {
response.writeHead(405, { "Content-Type": "text/plain; charset=utf-8" });
response.end("Метод не дозволено");
return;
}
if (normalizedTarget.length > 2048) {
response.writeHead(414, { "Content-Type": "text/plain; charset=utf-8" });
response.end("URL задовгий");
return;
}
if (containsAttackPattern(normalizedTarget)) {
console.warn("WAF заблокував запит:", {
method: request.method,
path: requestUrl.pathname,
ip: request.socket.remoteAddress
});
response.writeHead(403, { "Content-Type": "text/plain; charset=utf-8" });
response.end("Запит заблоковано");
return;
}
response.writeHead(200, { "Content-Type": "text/plain; charset=utf-8" });
response.end("Запит дозволено");
});
server.listen(3000, () => {
console.log("Навчальний WAF слухає http://localhost:3000");
});Запустити приклад можна командою:
node server.jsЛегітимний запит:
http://localhost:3000/search?q=javascriptПідозрілий запит:
http://localhost:3000/search?q=%3Cscript%3Ealert(1)%3C%2Fscript%3EУ реальному WAF не варто покладатися на кілька регулярних виразів. Повноцінні рішення враховують контекст, правила нормалізації, винятки, ліміти та журнали подій.
WAF може бути розміщений у кількох місцях.
Запит спочатку потрапляє до хмарного сервісу, а потім пересилається до інфраструктури застосунку.
Переваги:
не потрібно самостійно підтримувати інфраструктуру фільтрації;
легко масштабувати обробку трафіку;
можна централізовано захищати кілька застосунків;
часто доступні готові правила та аналітика.
Важливо правильно налаштувати доступ до origin-сервера. Якщо origin доступний напряму з Інтернету, атакувальник може обійти WAF.
WAF працює перед застосунком на власній інфраструктурі.
Переваги:
повний контроль над правилами;
можливість інтеграції з внутрішнім reverse proxy;
зручне розміщення поруч із сервісами.
Недоліки:
потрібно самостійно забезпечувати масштабування;
оновлювати правила;
моніторити продуктивність і доступність;
планувати відмовостійкість.
У великій системі WAF часто розташовують перед балансувальником:
Клієнти
↓
WAF
↓
Load balancer
↓
Група application serversУ такій схемі WAF централізовано застосовує правила до всього зовнішнього трафіку.
False positive — це легітимний запит, який WAF помилково визначив як атаку.
Наприклад, застосунок може легально приймати:
HTML у редакторі статей;
SQL-подібний текст у навчальному сервісі;
спеціальні символи у пошуковому запиті;
великі JSON-документи;
файли зі складним вмістом.
Без налаштування WAF такі запити можуть блокуватися.
Правильний процес налаштування:
Увімкнути режим журналювання.
Зібрати реальні приклади запитів.
Знайти правила, які спричиняють блокування.
Перевірити, чи справді запит безпечний.
Створити вузький виняток для конкретного endpoint-а або параметра.
Перевести правило в режим блокування.
Продовжити моніторинг.
Не варто повністю вимикати набір правил через одну проблему. Краще обмежити виняток:
Погано:
вимкнути всі правила для всього застосунку
Краще:
не застосовувати конкретне правило лише до POST /articles
для параметра body.contentЯкщо трафік зашифрований через HTTPS, WAF має бачити розшифрований HTTP-запит, щоб проаналізувати його вміст.
Зазвичай TLS завершується на одному з компонентів:
хмарному WAF;
reverse proxy;
load balancer.
Після цього WAF може аналізувати URL, заголовки та тіло запиту. Між WAF і застосунком також можна використовувати HTTPS, якщо цього вимагають вимоги до захисту внутрішнього трафіку.
Важливо правильно передавати інформацію про початковий клієнтський IP. Для цього часто використовують спеціальні proxy-заголовки, але застосунок має довіряти їм лише від відомого проксі. Інакше клієнт зможе підробити IP-адресу в заголовку.
WAF має записувати достатньо інформації для розслідування, але не повинен безконтрольно зберігати секрети.
Корисні поля події:
час;
HTTP-метод;
шлях;
статус рішення;
причина блокування;
ідентифікатор правила;
IP-адреса або ідентифікатор клієнта;
User-Agent;
ідентифікатор запиту;
latency обробки.
У журналах не слід зберігати у відкритому вигляді:
паролі;
токени доступу;
session cookies;
повні номери платіжних карток;
інші секрети.
Варто відстежувати метрики:
кількість дозволених запитів;
кількість заблокованих запитів;
кількість спрацьовувань кожного правила;
частоту помилкових блокувань;
затримку, яку додає WAF;
помилки самого WAF;
кількість запитів за IP або endpoint-ом.
WAF не вирішує всі проблеми безпеки.
Він може не захистити від:
помилок авторизації;
неправильних бізнес-правил;
викрадення облікових даних;
зловживання легітимним API;
вразливостей, які не мають помітного шаблону в HTTP-запиті;
шкідливих дій автентифікованого користувача;
атак на внутрішні сервіси, якщо трафік не проходить через WAF;
компрометації самого застосунку або залежностей.
Наприклад, запит:
POST /api/transferможе бути повністю синтаксично коректним і не містити жодного відомого шаблону атаки. Але якщо користувач переказує кошти з чужого рахунку через помилку в авторизації, WAF зазвичай цього не визначить.
Тому захист має бути багаторівневим:
безпечний код;
валідація вхідних даних;
параметризовані SQL-запити;
коректна авторизація;
обмеження доступу;
оновлення залежностей;
логування;
моніторинг;
WAF як додатковий периметровий шар.
WAF може зменшити ризик атаки, але не виправляє вразливість у застосунку. SQL-запити все одно мають бути параметризованими, а права доступу — перевірятися кодом.
Надто агресивні правила можуть блокувати нормальних користувачів. Спочатку перевіряйте правила в режимі журналювання.
Якщо сервер застосунку доступний напряму, клієнт може обійти WAF. Origin має приймати зовнішній трафік лише від дозволених компонентів.
Виняток для всього домену або всіх endpoint-ів значно зменшує користь WAF. Обмежуйте винятки конкретним шляхом, методом, параметром або правилом.
Без аналізу журналів неможливо зрозуміти, які атаки відбуваються та які легітимні запити блокуються.
IP-адреси можуть бути спільними для багатьох користувачів, змінюватися або приховуватися через проксі. IP-фільтри корисні, але не повинні бути єдиним механізмом захисту.
WAF фільтрує HTTP-трафік перед тим, як він потрапляє до вебзастосунку.
Він виявляє ознаки поширених атак: SQL injection, XSS, path traversal та інших аномалій.
WAF працює за правилами, які можуть бути вбудованими або спеціально налаштованими.
Режим журналювання допомагає знайти false positives до ввімкнення блокування.
Винятки мають бути вузькими та обмеженими конкретним endpoint-ом або параметром.
Origin-сервер не повинен дозволяти обхід WAF.
WAF не замінює безпечну розробку, авторизацію та валідацію даних.
Ефективність WAF залежить від правильних правил, журналювання, моніторингу та регулярного перегляду конфігурації.