SQL-ін'єкція: чим небезпечна і як закрити
SQL-ін'єкція — уразливість, при якій введений відвідувачем текст потрапляє в запит до бази даних не як значення, а як частина команди. В результаті сторонній може прочитати, змінити або видалити те, до чого в нього не повинно бути доступу.
Аналогія для власника сайту
Є архів і бланк: «принесіть справу номер ___». Якщо в графу з номером хтось допише «…а заодно винесіть весь шафу і залиште двері відкритими», а співробітник прочитає бланк цілком як доручення — він це зробить. Уразливий не архів, а звичка склеювати доручення з чужого тексту. Рішення — форма, де номер справи завжди залишається номером і ніколи не читається як команда.
Що при цьому можна втратити
| Що відбувається | Чим обертається |
|---|---|
| Читання чужих таблиць | Витік бази клієнтів і замовлень — а з нею повідомлення людям і питання регулятора |
| Доступ до облікових записів | Хеші паролів адміністраторів, вхід в адмінку, контроль над сайтом |
| Запис стороннього коду в базу | Зараження, яке повертається навіть після очищення файлів — див. шкідливий код на сайті |
Як це б'є по SEO
Прямого фактора ранжування тут немає — б'є наслідок. Через ін'єкцію в базу заливають спам-контент і приховані посилання на чужі теми. Далі типова схема: пошук переоцінює тематику сайту, позиції просідають, частина сторінок випадає з індексу, а при потраплянні домену в бази небезпечних сайтів браузери показують попередження і трафік обривається.
Як це виглядає в звіті Security Shield
Сканер відправляє один безпечний пробний запит до знайдених параметрів і дивиться, чи не поверне сайт текст помилки бази даних. Якщо повернув — з'являється знахідка «Признак SQL-ін'єкції (помилка БД)»: висока серйозність, клас CWE-89, категорія OWASP A03:2021. У доказі видно фрагмент помилки, а позначка «вимагає перевірки» означає, що сервіс фіксує симптом, а не зламує базу.
Проба виконується тільки в платних режимах і на підтвердженому домені. Сканер дивиться ззовні і бачить лише ті параметри, які знайшов на сторінках, — відсутність знахідки не означає, що ін'єкцій немає ніде. Що саме перевіряється — в статті про Security Shield.
Помилка бази в відповіді означає, що чужий текст дійшов до запиту. Передайте розробнику адресу сторінки і ім'я параметра з звіту. Ручне екранування лапок і «чорні списки» слів тут не рішення.
Як закрити
- Параметризовані запити. Головне рішення: текст запиту задається заздалегідь, а значення передаються окремо — підготовленим виразом. Тоді вміст поля фізично не може стати частиною команди.
- ORM або запитний шар фреймворка. Сучасні бібліотеки роблять це за замовчуванням; проблеми виникають там, де запит зібрали рядком вручну.
- Мінімальні права користувача бази. Обліковій запису сайту майже ніколи не потрібні права на видалення таблиць і роботу з файлами.
- Сховати технічні помилки від відвідувача — налагоджувальний вивід повинен йти в лог, а не на сторінку.
- Оновіть CMS і розширення. На типових сайтах ін'єкція частіше приходить з уразливим плагіном, ніж з вашого коду.
Як не допустити повторно
Домовтеся з розробником, що запити, зібрані конкатенацією рядків, не проходять рев'ю. Файрвол перед сайтом — міра на час правки, а не заміна підготовленим виразам. Після правки повторіть глибоке сканування. Корисно звіритися і з аудитом сайту — він покаже сторонні сторінки і посилання, якщо щось вже потрапило в базу.