SQL инъекция один из базовых и по прежнему массовых видов уязвимостей веб приложений. Через уязвимость формы или параметров ввода данных злоумышленник специально подготовленным запросом изменяет выполняемый приложением SQL запрос и получает возможности чтения изменения и удаления данных и обхода аутентификации. Причина в том что строка запроса строится сложением фрагментов, где часть берется из форм и параметров URL без параметризации без строгого отделения кода от данных.
Перечень видов SQL инъекций
Для понимания уязвимости и анализа полезно различать типы SQL инъекций которые отличаются каналом обратной связи и поведением приложения при обработке вредоносного ввода. В данном перечне представлены все основные типы SQL инфекций, знание который упростит вам классификацию и поможет эффективный противодействовать угрозе в веб приложениях.
- Error based. Приложение возвращает пользователю сырые сообщения об ошибках СУБД. Достаточно спровоцировать синтаксическую ошибку через лишнюю кавычку или некорректное выражение чтобы в ответе появилось сообщение с именами таблиц типами столбцов и фрагментами исходного запроса. Такой тип инъекции часто используется как первая ступень разведки структуры базы данных и особенностей конкретного SQL диалекта.
- Union based. Атакующий добавляет к исходному запросу оператор UNION который, объединяет легитимный результат с произвольной выборкой например из таблицы пользователей. Важная особенность оба запроса должны возвращать одинаковое число столбцов и совместимые типы данных поэтому на этапе тестирования подбираются варианты конструкции UNION пока приложение не начнет выводить дополнительные строки. При успешной эксплуатации чувствительные данные попадают напрямую в область вывода страницы.
- Boolean based blind. Приложение не показывает ошибки и не выводит результаты запросов, но изменяет содержимое страницы в зависимости от истинности выражения в условии. Тестировщик отправляет пару запросов например с добавлением AND 1=1 и AND 1=2 и сравнивает ответ. Если в одном случае часть содержимого исчезает или меняется статус ответа, значит параметр влияет на условие выборки и можно по шагам восстанавливать значения интересующих полей задавая вопросы базе в виде логических выражений.
- Time based blind. Используется в ситуациях когда содержимое ответа стабильно и не меняется даже при разных условиях. В этом случае в инъекцию добавляют вызовы функций задержки выполнения запроса. Если условие истинно база ждет заданное время перед отправкой результата, если ложно ответ приходит сразу. Измеряя время ответа для последовательности таких запросов, что дает возможность по битам или символам извлекать данные хотя процесс занимает больше времени и создает дополнительную нагрузку на систему.
- Out of band. Приложение не дает ни содержательных ошибок ни заметных различий во времени ответа, но СУБД или расширения позволяют инициировать внешние сетевые взаимодействия. Вредоносный запрос заставляет базу выполнить DNS запрос или HTTP обращение к домену контролируемому исследователем и факт такого обращения становится подтверждением инъекции. Через параметры этих запросов можно передавать небольшие фрагменты данных например хэши или части конфигурации, что особенно актуально для ограниченных и сильно фильтруемых сред.
- Вторичная SQL инъекция. Опасность появляется не в момент первоначального ввода, а позже когда сохраненные данные используются в другом контексте. Приложение принимает пользовательскую строку и записывает ее в базу как обычные данные и на этом этапе явных признаков уязвимости нет. На последующих шагах эта строка без экранирования подставляется в новый SQL запрос или в динамически формируемую часть отчета и начинает интерпретироваться как код. Такие инъекции сложно обнаружить простыми сканерами поэтому для их предотвращения особенно важны строгая параметризация и единые политики обработки данных на всех этапах жизненного цикла веб приложения.
Механизм формирования уязвимого запроса
В простейшей схеме аутентификации приложение ожидает логин и пароль и строит запрос к таблице пользователей примерно так как представлено в примере:
login = request["login"]
password = request["password"]
query = "SELECT * FROM users WHERE login = '" + login + "' AND pass_hash = '" + password + "'" Если вместо логина ввести строку ' OR 1=1 -- условие в секции WHERE становится всегда истинным и приложение может авторизовать первого пользователя в таблице или вернуть все записи. Таким образом пользовательский ввод превращается во фрагмент языка SQL, и оставляет брешь, открывая доступ к конфиденциальной информации практически каждому, кто обладает минимальным знанием применения SQL inj..
Инструменты и лучшие практики обнаружения с помощью sqlmap
Ручное тестирование на наличие SQL inj. начинается с отправки одиночных кавычек измененных чисел и простых логических выражений в параметры запросов с анализом ошибок и изменений в ответах. Для облегчения процесса и создания контролируемой среды при модификации запросов используют прокси Burp Suite или OWASP ZAP которые перехватывают и переотправляют запросы.
В реальных тестированиях на проникновение широко применяют инструмент sqlmap. Инструмент автоматически подбирает полезные нагрузки, определяет тип инъекции и при наличии разрешения перечисляет структуру базы данных. Установка в среде на базе Unix выполняется из официального репозитория проекта:
git clone https://github.com/sqlmapproject/sqlmap.git
cd sqlmap
python3 sqlmap.py -u "https://target.example/item?id=1" --batch --risk=1 --level=1
Запуск с минимальными настройками отражает аккуратную начальную проверку, он задает цель через параметр "id" и ограничивает глубину и риск чтобы не нагружать систему.
При необходимости и условии, что известна СУБД можно сузить область исследования указывают тип используемой базы данных, а так же имя целевой базы данных:
python3 sqlmap.py -u "https://target.example/item?id=1" --batch --dbms=PostgreSQL -D app_db --tablesДальнейшие шаги использования инструментария зависят от цели тестирования. Однако первое, что получают после успешной эксплуатации уязвимости, это список баз данных:
python3 sqlmap.py -u "https://target.example/item?id=1" --batch --dbsОбратите внимание: К лучшим практикам при тестировании относится запуск sqlmap через настроенный прокси чтобы действия фиксировались в журналах безопасности осознанный выбор параметров level и risk и строгая правовая рамка тестирование допустимо только по согласованию с владельцем ресурса.
