Влияние SQL-инъекции
SQL-инъекция (SQLi) позволяет злоумышленнику вмешиваться в запросы, которые приложение отправляет в свою базу данных [S1]. Основное воздействие включает несанкционированный доступ к конфиденциальным данным, таким как пароли пользователей, данные кредитных карт и личная информация [S1].
Помимо кражи данных, злоумышленники часто могут изменять или удалять записи базы данных, что приводит к постоянным изменениям в поведении приложений или потере данных. [S1]. В особо серьезных случаях SQLi может быть передан на эскалацию для компрометации внутренней инфраструктуры, включения атак типа «отказ в обслуживании» или обеспечения постоянного бэкдора в системах организации. [S1][S2].
Основная причина: небезопасная обработка ввода
Основной причиной SQL-инъекции является неправильная нейтрализация специальных элементов, используемых в SQL-команде [S2]. Это происходит, когда приложение создает запросы SQL путем объединения входных данных, находящихся под внешним влиянием, непосредственно в строку запроса [S1][S2].
Поскольку входные данные не изолированы должным образом от структуры запроса, интерпретатор базы данных может выполнять части пользовательского ввода как код SQL, а не обрабатывать их как литеральные данные [S2]. Эта уязвимость может проявляться в различных частях запроса, включая инструкции SELECT, значения INSERT или инструкции UPDATE [S1].
Конкретные исправления и смягчения последствий
Используйте параметризованные запросы
Самый эффективный способ предотвратить SQL-инъекцию — использование параметризованных запросов, также известных как подготовленные операторы [S1]. Вместо объединения строк разработчикам следует использовать структурированные механизмы, обеспечивающие разделение данных и кода [S2].
Принцип наименьших привилегий
Приложения должны подключаться к базе данных, используя самые низкие привилегии, необходимые для их задач [S2]. Учетная запись веб-приложения не должна иметь административных привилегий и должна быть ограничена определенными таблицами или операциями, необходимыми для ее работы [S2].
Проверка ввода и кодирование
Хотя проверка ввода не заменяет параметризацию, она обеспечивает глубокую защиту [S2]. Приложения должны использовать стратегию принятия заведомо годных данных, проверяя соответствие входных данных ожидаемым типам, длинам и форматам [S2].
Как FixVibe проверяет это
FixVibe уже охватывает внедрение SQL через закрытый модуль сканера active.sqli. Активное сканирование запускается только после проверки и аттестации владения доменом. Проверка сканирует конечные точки GET одного и того же происхождения с параметрами запроса, устанавливает базовый ответ, ищет логические аномалии, специфичные для SQL, и сообщает о результатах только после подтверждения времени для нескольких длин задержки. Сканирование репозитория также помогает выявить основную причину на более раннем этапе с помощью code.web-app-risk-checklist-backfill, который помечает необработанные вызовы SQL, созданные с использованием интерполяции шаблона.