Как защититься от SQL-инъекций в веб-приложении

Содержание

Введение

Представьте себе: вы разработали веб-приложение, запустили его на радость пользователям, и дело пошло в гору. Но однажды утром вы заходите на сайт и видите хаос — данные пропали, база пустая, в журнале запросов красуется подозрительная команда DROP TABLE. Что произошло? Скорее всего, ваш проект пал жертвой SQL-инъекции — коварной атаки на веб-приложения.

В статье рассказали, как избежать страшных последствий SQL-инъекций. Показали, как использовать подготовленные запросы, проверять ввод, ограничивать права и выстраивать дополнительные уровни защиты.

Аренда VPS/VDS — от ₽219/месяц

Почему выбирают VPS от AdminVPS:

✓ Дешевле физического сервера

✓ Более гибкий и мощный, чем обычный хостинг

✓ Бесплатная защита от DDoS и техподдержка 24/7

✓ Масштабируется под любые задачи

Виртуальный сервер VPS/VDS — ваш личный сервер для сайтов, магазинов, ботов и других проектов.

Чем опасна SQL-инъекция

Представьте форму поиска книги по ID: пользователь вводит номер, и приложение строит SQL-запрос вроде:

SELECT * FROM books WHERE id = 'ID_ПОЛЬЗОВАТЕЛЯ';

Если ввести 42, запрос получит книгу с ID 42. Но что если ввести в поле не число, а хитрый фрагмент:

42'; DROP TABLE books; --?

Ваш SQL превратится в два последовательных запроса:

SELECT * FROM books WHERE id = '42';
DROP TABLE books; --

Сначала база выберет книгу 42, а потом выполнит команду DROP TABLE books;, которая безвозвратно удалит таблицу со всеми книгами. Оставшаяся часть после -- будет проигнорирована как комментарий. В итоге злоумышленник одним вводом может уничтожить вашу базу. Это и есть классический пример SQL-инъекции.

К счастью, существуют проверенные практики и инструменты, которые помогают захлопнуть дверь перед носом SQL-инъекций. Ниже привели пошаговый план настройки защиты веб-приложения.

Параметризованные запросы

Параметризованные запросы — первый и главный щит против SQL-инъекций. Суть метода в том, что SQL-код отделяется от данных. Вы заранее подготавливаете SQL-запрос с плейсхолдерами (специальными метками вместо реальных значений), а потом передаёте пользовательские данные отдельно. База данных выполнит запрос, подставив параметры только в отведённые места, и воспримет их только как данные, а не как часть команды.

Это как заранее оформленный заказ в ресторане: вы говорите официанту, что у вас есть заказ с двумя позициями, а сами названия блюд сообщаете отдельно. Даже если вместо названия блюда вы попытаетесь подсунуть команду вроде DROP TABLE menu — официант (то есть база) воспримет это просто как имя очень странного блюда и не выйдет за рамки меню. Запрос останется цел и невредим, а вредоносная команда не выполнится.

На практике параметризованные запросы реализуются через подготовленные выражения в языках программирования. Например, в PHP для этого обычно используют расширения PDO или MySQLi. Представьте, что у вас был уязвимый фрагмент кода на PHP:

// НЕБЕЗОПАСНО: напрямую вставляем данные в запрос!
$login = $_POST['login'];
$password = $_POST['password'];
$query = "SELECT * FROM users WHERE login='$login' AND password='$password'";
$result = mysqli_query($conn, $query);

Этот код соединяет строку запроса прямо с логином и паролем. Хакеру ничего не мешает передать вместо пароля фрагмент ' OR '1'='1, чтобы обойти авторизацию.

Вот как можно переписать этот код, используя подготовленный запрос PDO:

// БЕЗОПАСНО: используем подготовленный запрос с параметрами
$pdo = new PDO($dsn, $user, $pass);
$sql = "SELECT * FROM users WHERE login = :login AND password = :password";
$stmt = $pdo->prepare($sql);
$stmt->execute(['login' => $_POST['login'], 'password' => $_POST['password']]);
$users = $stmt->fetchAll();

Сначала вызывается prepare(), передав SQL с плейсхолдерами :login и :password на месте данных. Затем методом execute() отправлены реальные значения параметров в виде массива. База данных получила команду и данные отдельно: она выполнит запрос, подставив значения только в предусмотренные места, и никакой вредоносный SQL-код не просочится в команду. Даже если пользователь умышленно введёт в поле пароль что-то вроде anything' OR 'x'='x, эти кавычки и операторы не сломают запрос. Они сохранятся внутри значения параметра и не повлияют на логику SQL.

Проверка и фильтрация входных данных

Следующий уровень защиты — тщательная проверка всех данных, которые вводит пользователь, прежде чем использовать их в базе. Принцип прост: нельзя доверять даже самому безобидному на вид вводу. Убедитесь, что данные соответствуют ожидаемому формату, и при необходимости очищайте их. Такая валидация не только мешает SQL-инъекциям, но и снижает риск сбоев и ошибок.

Начните с проверки типа и диапазона: если поле должно принимать число, гарантируйте, что там действительно число. Например, ID пользователя — целое положительное. При получении $_GET['id'] проверьте, что это строка из цифр. В PHP подойдут filter_var($id, FILTER_VALIDATE_INT) или ctype_digit(). Если приходит что-то вроде 123abc или тем более 123 OR 1=1 — сразу отклоняйте такой ввод. Для e-mail используйте FILTER_VALIDATE_EMAIL, а для сложных форматов регулярные выражения. Регулярка задаёт жёсткие рамки, например, строка пароля должна содержать только разрешённые символы нужной длины.

Помимо формата полезно чистить и экранировать специальные символы. Даже с подготовленными запросами не помешает убрать пробелы с краёв и преобразовать HTML-угроз. Если вы всё же вставляете строку в SQL вручную, как минимум экранируйте спецсимволы через mysqli_real_escape_string() и аналоги. Но помните: экранирование легко сделать неправильно. Не пользуйтесь чёрными списками, их обойти проще, чем кажется. Лучше использовать белые списки и готовые функции.

Одна валидация не поможет, если дальше идёт прямое склеивание SQL. Всё должно работать вместе, как тандем безопасности. Всегда исходите из параноидального принципа: любой ввод опасен, пока не доказано обратное.

Ограничение доступов к базе данных

Продумайте, с какими правами ваше приложение подключается к базе. Частая ошибка — использовать учётку администратора (root) для всех действий. В случае SQL-инъекции злоумышленник получит полный контроль: удаление таблиц, создание новых, доступ ко всему подряд.

Создайте отдельного пользователя БД, которому выданы строго необходимые права. Например, если сайту нужно лишь читать и записывать данные в одной таблице, не давайте ему доступ на удаление, изменение структуры или управление другими базами. Пусть выполняет только SELECT, INSERT, UPDATE и только в рамках своей схемы.

Если SQL-инъекция всё же произойдёт, ограниченные права помогут смягчить последствия. Представьте, что взломщик проник внутрь, но у него в руках лишь гостевой ключ, а не полная связка от всей крепости. В худшем случае он что-то прочитает или повредит, но не сотрёт базу и не получит доступ к другим сервисам. Конечно, лучше вообще не допустить взлома, но принцип least privilege (минимально достаточные права) работает как страховка.

Дополнительные меры безопасности: WAF, обновления, бекапы

Когда базовые меры защиты настроены, подумайте о дополнительных уровнях. Один из них — веб-файрвол (WAF). Это фильтр между приложением и внешним миром, который отслеживает подозрительные запросы. Хороший WAF по шаблонам распознаёт попытки SQL-инъекций и блокирует их ещё до приближения к вашему коду. Например, если в параметрах появится последовательность «'; DROP», файрвол сразу определит атаку и остановит запрос. WAF бывает облачным, как услуга Cloudflare, или модулем на сервере, например ModSecurity для Apache/Nginx.

Разработчики баз данных, фреймворков и серверного ПО постоянно выпускают патчи безопасности. Уязвимости, включая SQL-инъекции, могут появляться даже на популярных платформах — патчи закрывают эти дыры. Поддерживайте в актуальном состоянии MySQL/PostgreSQL, движок сайта, CMS и библиотеки. Так вы не дадите злоумышленникам шанс воспользоваться известной уязвимостью.

Не забывайте про резервные копии (бекапы). Они не предотвратят саму атаку, но если случится беда, помогут быстро восстановить данные. Лучший план на случай ЧП — это возможность вернуть базу из свежего бекапа с минимальными потерями. Чтобы немного разгрузить голову, настройте автоматическое создание копий — хостер AdminVPS предлагает готовые решения для бекапов на всех VPS.

Используйте проверенные фреймворки и ORM. Современные платформы (Django, Laravel, .NET и другие) изначально ориентированы на безопасность и почти всегда применяют параметризацию запросов. ORM автоматически защищают от большинства тривиальных инъекций, подставляя параметры безопасно. Но если пишете сырые SQL-запросы даже внутри фреймворка, используйте подготовленные выражения и фильтрацию данных.

Полезно регулярно проверять приложение на уязвимости. Есть много сканеров безопасности, включая бесплатные. Они анализируют сайт и ищут инъекции. Такие тесты помогут найти слабые места до того, как их заметят злоумышленники. Также включите логирование SQL-ошибок и подозрительных запросов, это позволит оперативно отреагировать на попытки взлома.

Заключение

SQL-инъекция — это не хакерская магия, а вполне приземлённая проблема, которую можно решить раз и навсегда, если соблюдать описанные практики. Настройка защиты от SQL-инъекций — это привычка, которую стоит выработать с первых дней работы над проектом. Да, поначалу может казаться, что и так сойдёт и можно обойтись без всех этих проверок, но каждая лишняя минута, потраченная на безопасность, сэкономит часы (а то и дни) на ликвидацию последствий атаки.

Читайте в блоге:

Защита веб-приложения от SQL-инъекций: подготовленные запросы и другие меры безопасности