ProSvet
от Pentest-Tools

SQL-инъекции (SQLi)

SQL-инъекции известны с конца 1990-х годов и до сих пор приводят к кражам баз данных — включая случаи на миллионы записей.

01

Что такое SQL-инъекция

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

Класс формально описал Rain Forest Puppy ещё в 1998 году (Phrack #54, доклад об атаках на веб-приложения). С 2003–2005 годов, с появлением автоматических сканеров, SQLi превратилась из «хакерского трюка» в массовый инструмент: одна уязвимая форма поиска могла отдать всю таблицу клиентов за пару секунд.

В OWASP Top 10 2021 SQLi входит в категорию A03:2021 «Injection». Несмотря на зрелость защиты (параметризованные запросы, ORM), инъекции регулярно встречаются в самописных API, легаси-модулях и «быстрых» интеграциях с базами.

02

Как устроен запрос и где ломается граница

Типичная проверка логина на PHP 5.x выглядела так: $q = "SELECT id FROM users WHERE login='" . $_GET['login'] . "' AND pass='" . $_GET['pass'] . "'". Если в поле login подставить admin'--, остаток условия (включая проверку пароля) «комментируется».

Важно понимать: атакуется не сама СУБД. Атакуется приложение, которое доверяет строке как данным и при этом исполняет её как код запроса.

03

Пример: чтение чужих заказов

Представьте интернет-магазин: GET /order?id=1024. Бэкенд: SELECT * FROM orders WHERE id = 1024 AND user_id = SESSION_USER.

Если id подставляется без параметров, атакующий передаёт 1024 OR 1=1 — условие user_id становится неважным, и выдаётся первая строка. Ещё типичнее UNION-конструкция: … UNION SELECT credit_card FROM customers-- — уже «на экране» оказываются чужие поля.

В проде злоумышленники не тыкают вручную: sqlmap, Havij, Burp Intruder перебирают типы инъекций (boolean, time-based blind, error-based, stacked queries) и дампят схему. Замер по исследованию Veracode State of Software Security: доля приложений хотя бы с одной Injection-проблемой десятилетиями держится в районе десятков процентов среди легаси-портфелей.

04

Реальный инцидент: TalkTalk (2015)

Британский телеком TalkTalk потерял данные порядка 157 тысяч клиентов. Компания прямо указала, что вектором была SQL-инъекция в веб-форме. По разным оценкам, совокупные потери (штрафы, расследования, компенсации, отток) превысили десятки миллионов фунтов. Показательно другое: атаковали не «суперсложным» APT-сценарием — школьники использовали давно известный класс уязвимости.

Ещё раньше, в 2008–2009 годах, серия взломов Heartland Payment Systems и ряда ритейлеров строилась вокруг инъекций и позволила выгрузить миллионы платёжных карточек — кейс, который до сих пор цитируют в курсах по PCI DSS.

05

Техники эксплуатации (кратко)

  • Boolean-based blind: подмена условия, по разнице ответов восстанавливается содержимое посимвольно.
  • Time-based blind: вызов функций задержки (SLEEP, WAITFOR, pg_sleep) — работает, когда вывод экранирован.
  • Error-based: СУБД «проговаривается» в сообщениях об ошибках (типичная проблема debug-режима на проде).
  • UNION / stacked queries: чтение произвольных таблиц или выполнение дополнительных инструкций при поддержке драйвером.
06

Как защититься — по слоям

Код. Только параметризованные запросы или ORM с безопасными билдерами. Никогда — конкатенация SQL со значениями. Даже «числа» и «id» стоит передавать параметрами.

Архитектура. Отдельная учётная запись БД с минимальными правами: приложение не должно иметь DROP/TRUNCATE, если бизнес-процесс этого не требует.

Гигиена. Отключение детальных ошибок СУБД на проде, обновление драйверов и СУБД, отключение лишних расширений.

Проверка. Автоматическое сканирование (OWASP ZAP, sqlmap в контрольном режиме, commercial DAST) + ручная проверка критичных форм и API.

WAF как вторая линия. Сигнатуры снижают массовые эксплойты, но не заменяют исправление в коде — это принципиально.

Мониторинг. Аномальный объём выборок, необычные SQL-паттерны в логах приложения, всплеск 500-х ответов на конкретной форме.

07

Что проверяют на аудите

На ручном аудите ProSvet проходят не только «голые» точки входа: проверяются фильтры, которые «частично» нормализуют ввод, JSON/XML-бэкенды, отчётные выгрузки, админские формы и мобильные API. Именно «тихо защищённые» участки чаще всего остаются уязвимыми.

Нужна проверка именно вашего контура?

Запустите автоматическое сканирование или закажите ручной аудит с заключением — с приоритетами и планом устранения.

Начать сканирование