Wiki · Вредоносные технологии

SQL-инъекция

5 мин чтенияАвтор: Станислав БарановСоавторы: Евгений Баев

SQL-инъекция – это уязвимость сайта, при которой данные от посетителя попадают в запрос к базе данных как часть команды. Через такую дыру посторонний может прочитать, изменить или удалить данные: заказы, учётные записи, контент.

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

Как возникает уязвимость

Представьте шаблон «покажи товар с номером ___». Программист подставляет в пропуск то, что пришло из адреса страницы. Пока там число, всё работает. Но если подставлять текст как есть, без проверки, вместо номера можно прислать продолжение команды, и база выполнит его вместе с основным запросом.

Разница между уязвимым и безопасным кодом видна на примере (условный код на PHP):

// Плохо: значение из адреса склеивается с текстом запроса
$sql = "SELECT name, price FROM products WHERE id = " . $_GET['id'];

// Хорошо: подготовленный запрос, значение передаётся отдельно
$stmt = $pdo->prepare('SELECT name, price FROM products WHERE id = ?');
$stmt->execute([$_GET['id']]);

Во втором случае база получает команду и значение раздельно. Что бы ни прислал посетитель, для базы это просто значение, а не часть команды.

Схема SQL-инъекции: при склейке строк ввод посетителя выполняется как команда, в подготовленном запросе база видит только значение — Как возникает SQL-инъекция

Какие бывают SQL-инъекции

Их различают по тому, как атакующий видит результат:

классическая: результат запроса выводится прямо на страницу, например в списке товаров;
через ошибки: сайт показывает текст ошибки базы, и по нему видно устройство таблиц;
слепая: на странице ничего не меняется, но сайт по-разному отвечает или медлит, и по этим отличиям данные вытягивают по кусочку.

Слепые инъекции самые неприятные: снаружи сайт работает как обычно, а данные уходят понемногу. Поэтому спрятать ошибки мало, исправлять нужно сам запрос.

Где уязвимость обычно находят

параметры в адресе: фильтры каталога, сортировка, номер страницы;
поле поиска по сайту;
формы входа, регистрации и восстановления пароля;
cookies и заголовки запроса, которые сайт записывает в базу;
самописные модули, старые плагины и доработки, которые никто не проверял после сдачи.

Ядро популярных CMS проверяют много людей, и найденные дыры закрывают обновлениями. Слабое место чаще в том, что дописано под конкретный проект: выгрузка из 1С, нестандартный фильтр, форма расчёта.

Схема мест, где на сайте обычно находят SQL-инъекции: параметры адреса, формы поиска и входа, cookies и заголовки, самописные модули — Где ищут SQL-инъекции

Что теряет владелец сайта при SQL-инъекции

Утечка базы: телефоны, почты, адреса доставки, история заказов. Для владельца это ещё и обязанности по 152-ФЗ, вплоть до сообщения в Роскомнадзор.
Вход в административную панель без пароля.
Подмена цен, текстов и ссылок, внедрение спама на страницы.
Удаление данных, если у сайта есть права на удаление.

Шесть правил безопасной работы с базой

Используйте подготовленные запросы или ORM. В 1С-Битрикс работайте через API и ORM, а если пишете запрос вручную, экранируйте значения штатными методами ядра.
Приводите типы на сервере. Номер товара или страницы должен быть числом, остальное отбрасывайте. Проверка в браузере тут не спасает: запрос к серверу можно отправить и в обход формы.
Поля сортировки проверяйте по белому списку. Имя столбца нельзя передать как параметр подготовленного запроса, поэтому допускайте только заранее известные значения.
Дайте сайту пользователя базы с минимальными правами. Работать под администратором СУБД нельзя.
Не показывайте посетителям ошибки базы данных. Они подсказывают структуру таблиц.
Обновляйте ядро и модули: многие известные уязвимости закрыты в свежих версиях.

Дополнительный слой защиты даёт WAF: он отсекает подозрительные запросы до того, как их обработает код сайта. В 1С-Битрикс его роль выполняет «Проактивный фильтр» в модуле «Проактивная защита». По документации он умеет делать опасные данные безопасными (например, разбивать слово select), удалять их или добавлять адрес атакующего в стоп-лист. Но WAF ловит известные шаблоны. Ошибку в коде он не исправляет.

Чек-лист защиты от SQL-инъекций: подготовленные запросы, приведение типов, белый список сортировки, минимальные права, скрытые ошибки, WAF — Как защитить сайт от SQL-инъекций

Битрикс, права в базе и временные заплатки: что уточняют про защиту

Чем SQL-инъекция отличается от XSS?

SQL-инъекция бьёт по базе данных на сервере, а XSS подсовывает скрипт в страницу, и он срабатывает в браузере посетителя. Поэтому и лечат их по-разному: от первой спасают подготовленные запросы, от второй экранирование при выводе и заголовок Content-Security-Policy.

Как 1С-Битрикс защищает от SQL-инъекций и где эта защита заканчивается?

Ядро закрывает типовые случаи: ORM и методы API передают значения в базу безопасно, а «Проактивный фильтр» отсекает подозрительные запросы. Граница проходит там, где разработчик сам склеил запрос из строк в своём компоненте, выгрузке или обработчике формы. Такой код фильтр прикрывает лишь частично, его проверяют и переписывают.

Какие права дать пользователю базы, под которым работает сайт?

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

Что делать, если уязвимость нашли, а быстро исправить код не получается?

Прикрыть её временно и параллельно чинить. Добавьте правило в WAF или «Проактивный фильтр» под конкретный адрес, а уязвимую функцию, например нестандартный фильтр каталога, на время отключите. Если данные могли уйти, смените пароли и посмотрите журнал вторжений. Это выигрывает время, но исправленный запрос всё равно нужен.

Как проверить код сайта на SQL-инъекции

Начните со штатных средств: в 1С-Битрикс есть «Сканер безопасности» и «Журнал вторжений», где видно, какие запросы отсёк фильтр. Затем пройдитесь по своему коду: найдите все места, где запрос к базе собирается из строк, и замените их подготовленными запросами или методами API. Самописные модули и интеграции стоит отдать на проверку человеку, который их не писал: автор обычно смотрит на код глазами того, кто знает, как он должен работать.

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

Проверить код и настройки на SQL-инъекции поможет услуга информационная безопасность сайтов. Исправить уязвимые модули и обновить ядро можно в доработке существующего сайта.