SQL-инъекции: основы - как ломают и защищают базы данных

Когда строка пользователя становится частью запроса

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

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

Допустим, приложение ищет пользователя по имени:

SELECT id, username
FROM users
WHERE username = 'ivan';

Сам запрос выглядит нормально. Но если значение ivan формируется из поля ввода и просто приклеивается к строке, пользователь получает возможность повлиять не только на значение, но и на структуру выражения.

Так возникает SQL-инъекция. База данных больше не видит чёткой границы между командой приложения и данными пользователя. Часть введённой строки начинает восприниматься как SQL-код.

Уязвимость существует не потому, что база данных работает неправильно. Напротив, она выполняет запрос именно так, как он был сформирован. Ошибку допускает приложение, которое доверяет вводу и позволяет ему менять синтаксис команды.

SQL - это язык, на котором приложение разговаривает с данными

SQL, или Structured Query Language, используется для чтения, добавления, изменения и удаления информации в реляционных базах данных. Через него приложение обращается к таблицам, фильтрует результаты, объединяет записи и управляет связями между объектами.

Простой запрос может выбрать пользователя по идентификатору:

SELECT id, username, email
FROM users
WHERE id = 15;

Здесь SELECT определяет, какие данные нужно получить, FROM указывает таблицу, а WHERE задаёт условие отбора.

Запрос авторизации может выглядеть так:

SELECT id
FROM users
WHERE username = 'ivan'
  AND password_hash = 'значение';

Если база возвращает запись, приложение считает, что учётные данные совпали.

Для специалиста по безопасности важно понимать не только отдельные команды SQL, но и то, как приложение строит запрос. Где начинаются и заканчиваются строки? Какие значения заключаются в кавычки? Что произойдёт, если пользователь введёт специальный символ? Меняется ли количество возвращаемых строк?

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

Конкатенация превращает данные в код

Небезопасный серверный код часто строит запрос через объединение строк:

$sql = "SELECT id, username
        FROM users
        WHERE username = '" . $_POST['username'] . "'
        AND password = '" . $_POST['password'] . "'";

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

База данных не знает, какая часть команды была написана разработчиком, а какая пришла из формы. Она получает уже готовую строку и выполняет её целиком.

Безопасный код должен передавать структуру запроса и значения отдельно:

$stmt = $pdo->prepare(
    "SELECT id, username
     FROM users
     WHERE username = :username
       AND password_hash = :password_hash"
);

$stmt->execute([
    'username' => $username,
    'password_hash' => $passwordHash,
]);

Здесь параметры больше не становятся частью SQL-синтаксиса. Даже если пользователь введёт кавычки или фрагменты команд, база данных обработает их как значение поля.

Подготовленные запросы защищают не потому, что удаляют опасные символы. Они изначально не позволяют данным изменить структуру команды.

Почему обход авторизации вообще возможен

Форма входа обычно проверяет, существует ли пользователь с указанной комбинацией логина и пароля. Если приложение строит запрос небезопасно, атакующий может попытаться изменить условие WHERE так, чтобы оно стало истинным независимо от введённых данных.

В учебных материалах этот принцип часто демонстрируют на выражении, которое добавляет к проверке условие, всегда возвращающее истину. Точный синтаксис зависит от базы данных, кавычек и структуры исходного запроса, поэтому одна и та же строка не работает повсюду.

Суть атаки заключается не в какой-то особенной последовательности символов. Она заключается в изменении логики:

WHERE username = 'введённое значение'
AND password = 'введённое значение'

превращается в конструкцию, где часть условия больше не ограничивает выборку так, как ожидал разработчик.

Если приложение просто проверяет наличие хотя бы одной строки, оно может принять результат за успешную авторизацию.

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

Даже при правильной проверке пароля небезопасный запрос поиска пользователя всё равно остаётся уязвимым. Защита должна охватывать весь путь данных.

Комментарии позволяют изменить окончание запроса

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

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

Конкретные обозначения комментариев различаются между MySQL, PostgreSQL, Microsoft SQL Server и другими системами. Имеет значение даже наличие пробела или перевода строки.

Это хорошо показывает, почему SQL-инъекции нельзя сводить к запоминанию нескольких популярных строк. Успешная проверка зависит от конкретного диалекта SQL, контекста параметра и того, как приложение формирует запрос.

Исследователь сначала выясняет структуру, а уже затем проверяет гипотезу в контролируемой среде.

Сообщения об ошибках раскрывают устройство запроса

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

Особенно полезны подробные сообщения базы данных:

You have an error in your SQL syntax

или:

Unterminated quoted string

Такая ошибка показывает, что пользовательское значение повлияло на синтаксис запроса.

Иногда ответ раскрывает название таблицы, столбца, драйвера или самой СУБД. Эти сведения помогают понять внутреннюю структуру приложения и подобрать правильную методику дальнейшей проверки.

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

Поэтому специалист смотрит не только на текст. Важны код HTTP-ответа, размер страницы, количество записей, время выполнения и различия между запросами.

Error-based инъекция использует ошибки как канал данных

Некоторые базы данных включают в сообщение об ошибке результат вычисления или преобразования. Если приложение выводит текст исключения пользователю, атакующий может попытаться заставить СУБД показать внутри ошибки определённые данные.

Такой подход называют error-based SQL injection.

Он особенно эффективен в системах с подробной отладкой, где исключения базы без обработки попадают прямо в HTML. Вместо обычного сообщения о синтаксисе страница может раскрыть версию СУБД, имя текущей базы или другие сведения.

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

Сокрытие ошибок не исправляет инъекцию, но значительно уменьшает объём информации, которую приложение отдаёт наружу. Основной защитой всё равно остаются параметризованные запросы.

UNION позволяет объединить результаты двух выборок

Оператор UNION объединяет результаты нескольких запросов SELECT. Разработчики используют его, когда нужно получить данные из разных источников в одном наборе.

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

Допустим, страница ожидает результат вида:

SELECT title, description
FROM products
WHERE id = 10;

Для объединения дополнительного запроса количество столбцов и совместимость их типов должны совпадать с исходной выборкой. Если приложение выводит два столбца, добавленная часть тоже должна возвращать два значения.

Поэтому UNION-инъекция обычно начинается с восстановления структуры запроса. Исследователь определяет количество столбцов, места их отображения и типы данных.

Это не магический способ «выгрузить всю базу». Он работает только при определённых условиях и требует точного понимания ответа приложения.

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

Не все SQL-инъекции показывают данные напрямую

Иногда приложение никак не отображает результат запроса. Оно возвращает только два состояния: страница существует или нет, операция выполнена или отклонена.

В такой ситуации уязвимость может оставаться доступной через косвенные признаки.

При boolean-based подходе исследователь сравнивает ответы на условия, которые должны быть истинными и ложными. Если поведение страницы меняется предсказуемо, можно сделать вывод о логике запроса.

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

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

Важно не путать реальное различие с нестабильностью приложения. Кэширование, балансировщики, динамическое содержимое и защитные системы могут менять размер и время ответа. Любой сигнал нужно перепроверять несколько раз.

Время ответа тоже может стать сигналом

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

Некоторые СУБД позволяют намеренно задержать ответ. Если задержка появляется только при выполнении определённого условия, это может указывать на blind SQL injection.

Такой метод называют time-based SQL injection.

Он особенно чувствителен к сетевой нестабильности. Высокая задержка сама по себе ничего не доказывает. Сервер может быть перегружен, база выполнять фоновую задачу, а защитный сервис - замедлять подозрительные запросы.

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

В реальном пентесте такие тесты выполняются осторожно. Большое количество тяжёлых запросов способно создать дополнительную нагрузку на базу. Цель заключается в подтверждении уязвимости, а не в извлечении максимального объёма информации.

SQL-инъекция встречается не только в форме входа

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

На практике уязвимым может оказаться любое значение, которое участвует в запросе к базе.

Это идентификатор товара, поисковая строка, фильтр каталога, сортировка, параметр API, cookie, HTTP-заголовок или скрытое поле формы. Иногда пользователь не видит значение в интерфейсе, но может изменить его через перехваченный запрос.

Особенно опасны числовые параметры. Разработчик считает, что идентификатор всегда будет числом, и вставляет его в SQL без кавычек и параметризации:

$sql = "SELECT * FROM orders WHERE id = " . $_GET['id'];

Отсутствие строковых кавычек не делает запрос безопасным. Пользователь всё равно контролирует часть SQL-выражения.

Уязвимости также встречаются в динамической сортировке:

ORDER BY пользовательское_значение

Названия столбцов и направлений сортировки сложнее передавать как обычные параметры. Здесь применяется белый список разрешённых значений, а не прямая подстановка.

Вторая стадия может сработать спустя время

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

Такой сценарий называют second-order SQL injection.

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

Уязвимость проявляется не в момент ввода, а во время повторного использования данных.

Это ещё раз показывает, почему нельзя считать информацию из собственной базы автоматически доверенной. Она могла прийти от пользователя, стороннего API, импортированного файла или старой версии приложения.

Параметризация нужна при каждом формировании SQL, независимо от происхождения значения.

Автоматические инструменты ускоряют проверку, но не заменяют понимание

Инструменты вроде sqlmap умеют определять различные типы SQL-инъекций, сравнивать ответы и автоматизировать часть рутинной работы.

Они особенно полезны после ручного подтверждения, когда исследователь уже понимает уязвимый параметр, метод запроса и поведение приложения.

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

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

Ручной анализ помогает понять контекст. Автоматизация ускоряет проверку гипотезы. Эти подходы дополняют друг друга, но не заменяют один другой.

Использовать такие инструменты допустимо только на собственных системах, учебных стендах или в явно согласованном скоупе.

Возможности инъекции зависят от прав базы данных

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

Если пользователь базы может только читать несколько таблиц, последствия будут ограничены. Если ему разрешено изменять данные, создавать объекты, обращаться к файловой системе или выполнять административные операции, влияние становится значительно серьёзнее.

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

Это нарушает принцип минимальных привилегий.

Учётная запись приложения должна иметь только те разрешения, которые действительно нужны. Если сервис только читает каталог, ему не требуется удалять таблицы. Если приложение работает с одной схемой, ему не нужен доступ к остальным базам.

Ограничение прав не устраняет SQL-инъекцию, но уменьшает ущерб в случае ошибки.

Чтение файлов зависит от конфигурации сервера

Некоторые СУБД поддерживают функции для работы с файлами. При определённых правах и настройках SQL-запрос может попытаться прочитать содержимое файла с сервера базы данных.

Это не означает, что любая SQL-инъекция автоматически открывает доступ к конфигурации приложения. Возможность зависит от типа СУБД, системных разрешений, настроек безопасности и расположения базы.

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

Тем не менее чрезмерные привилегии превращают обычную инъекцию в более серьёзную угрозу. Через доступные файлы могут раскрыться конфигурации, ключи и внутренние сведения.

Защита строится сразу на нескольких уровнях: параметризованные запросы, отдельный системный пользователь СУБД, ограниченные файловые права и отключение ненужных возможностей.

Запись файлов делает последствия значительно тяжелее

Некоторые базы данных при наличии специальных привилегий способны записывать результаты запроса в файл. В крайне небезопасной конфигурации это может привести к появлению нового файла в каталоге, доступном веб-серверу.

Такой сценарий часто описывают как путь от SQL-инъекции к выполнению кода на сервере.

Однако для него должно совпасть сразу несколько условий. Учётная запись базы получает право на запись файлов, СУБД видит нужный каталог, системные разрешения допускают создание файла, а веб-сервер способен обработать его как исполняемый код.

Правильно настроенная инфраструктура разрывает эту цепочку на нескольких этапах.

Учётной записи приложения не нужны файловые привилегии. База не должна записывать данные в каталоги веб-сервера. Приложение и СУБД полезно разделять по системным пользователям, контейнерам или отдельным узлам.

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

Экранирование символов не является полноценной защитой

Ранние рекомендации часто сводились к обработке кавычек и обратных слешей. Разработчик пропускает пользовательский ввод через функцию экранирования и вставляет результат в строку SQL.

Такой подход лучше полного отсутствия обработки, но он остаётся хрупким.

Правила экранирования зависят от СУБД, кодировки, режима SQL и контекста. Значение внутри строки обрабатывается иначе, чем имя столбца, число или часть оператора ORDER BY.

Ошибки появляются при несовпадении кодировок, неправильном выборе функции или повторном декодировании данных.

Подготовленные запросы решают проблему на более фундаментальном уровне. Они не пытаются угадать, какие символы опасны, а передают значение отдельно от SQL-команды.

Экранирование может использоваться внутри корректной библиотеки или драйвера, но вручную собирать защиту на его основе не стоит.

Фильтрация не должна искать «опасные символы»

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

Апостроф встречается в именах и текстах. Слова select, union и update могут быть частью обычного комментария. Разные СУБД поддерживают разные конструкции, кодировки и формы записи.

Чёрный список постоянно приходится расширять, но он никогда не охватывает весь синтаксис.

Валидация должна исходить из назначения поля. Идентификатор проверяется как целое положительное число. Направление сортировки выбирается из значений ASC и DESC. Имя столбца сопоставляется с заранее разрешённым списком.

Текстовые значения передаются через параметры без попытки удалить из них SQL-синтаксис.

Так приложение не борется с отдельными символами, а ограничивает данные реальной моделью.

ORM снижает риск, но не делает приложение неуязвимым

Современные проекты часто используют ORM или query builder. Эти инструменты формируют SQL автоматически и обычно параметризуют значения.

Например, безопасный вызов может выглядеть так:

$user = User::where('email', $email)->first();

Разработчик не собирает строку вручную, а библиотека передаёт значение через параметр.

Но ORM позволяет выполнять и сырые запросы. Если внутри raw() или похожей функции появляется конкатенация пользовательского ввода, защита исчезает.

Опасны также динамические имена таблиц, столбцов и сортировок. Обычные параметры предназначены для значений, но не всегда подходят для SQL-идентификаторов. Такие части выбираются из белого списка.

ORM уменьшает количество случайных ошибок, но не отменяет необходимость понимать SQL. Чем сложнее запрос, тем чаще разработчик переходит к ручным конструкциям, где ответственность снова оказывается на нём.

Скрытие ошибок полезно, но проблему не исправляет

В рабочем приложении посетитель не должен видеть трассировку, полный SQL-запрос и сообщение драйвера базы.

Вместо этого сервер возвращает нейтральный ответ:

Не удалось выполнить запрос

Подробная информация записывается во внутренний журнал с ограниченным доступом.

Это мешает атакующему быстро определить СУБД и структуру запроса. Но скрытая ошибка не означает безопасный код. Blind-инъекции работают даже без сообщений, используя различия в ответах или времени выполнения.

Поэтому настройка обработки исключений является дополнительной мерой. Она уменьшает утечку информации, но не заменяет параметризацию.

Пароли нельзя сравнивать внутри SQL как обычный текст

В старых приложениях можно встретить запрос:

SELECT id
FROM users
WHERE username = 'ivan'
  AND password = 'secret';

Это означает, что пароль, вероятно, хранится в открытом виде или в обратимо преобразованной форме.

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

SQL-запрос может выглядеть так:

SELECT id, password_hash
FROM users
WHERE username = :username;

Затем приложение выполняет проверку:

password_verify($password, $user['password_hash']);

Даже если поиск пользователя построен безопасно, слабое хранение паролей остаётся отдельной проблемой. Защита базы должна учитывать не только инъекции, но и последствия возможной утечки.

Пароли хранятся с помощью специализированных алгоритмов вроде Argon2id или bcrypt, а не обычных MD5 и SHA-1.

Логи помогают заметить попытки, но требуют осторожности

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

WAF также способен блокировать часть известных конструкций.

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

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

Мониторинг помогает обнаружить атаку и расследовать инцидент. Исправление приложения всё равно начинается с безопасных запросов.

Почему SQL-инъекции продолжают появляться

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

Тем не менее проблема не исчезает.

В крупных проектах остаются старые модули, написанные до внедрения единых стандартов. Разработчик добавляет один динамический фильтр и ради удобства собирает его строкой. Внутренний сервис считается недоступным извне, поэтому его код проверяют менее тщательно.

Иногда уязвимость появляется не в основном запросе, а в редкой функции: отчёте, импорте, поиске архива, административной панели или старой версии API.

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

Как проверяют приложение без создания лишнего риска

Тестирование начинается с определения параметров, которые могут участвовать в запросах к базе. Исследователь изучает формы, URL, JSON, cookies и заголовки, а затем сравнивает реакцию приложения на безопасные изменения значений.

Вместо попытки сразу получить данные достаточно подтвердить, что ввод способен влиять на SQL-логику. Проверка выполняется на тестовой учётной записи и с минимальным количеством запросов.

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

После подтверждения уязвимость описывается через исходный запрос, контролируемый параметр, наблюдаемое поведение и возможное влияние. Затем проверяется исправление.

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

Защита начинается с параметризации каждого запроса

Подготовленные выражения должны применяться везде, где в SQL участвуют внешние данные.

$stmt = $pdo->prepare(
    "SELECT id, title, price
     FROM products
     WHERE category_id = :category_id
       AND price <= :max_price"
);

$stmt->execute([
    'category_id' => $categoryId,
    'max_price' => $maxPrice,
]);

Значения передаются отдельно и не могут добавить новый оператор или изменить условие.

Динамические части, которые нельзя параметризовать обычным способом, формируются через белый список:

$allowedSort = ['name', 'price', 'created_at'];

$sort = in_array($_GET['sort'], $allowedSort, true)
    ? $_GET['sort']
    : 'created_at';

После этого безопасно выбранное имя используется в запросе.

Дополнительно ограничиваются права учётной записи базы, отключается подробный вывод ошибок, включается журналирование и регулярно проверяются зависимости.

Защита работает надёжнее, когда она встроена в общие правила разработки, а не добавляется после обнаружения очередной инъекции.

Как устроен модуль «SQL-инъекции: основы» в Kraken Academy

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

Главная задача заключается не в запоминании популярных строк. Важно научиться восстанавливать предполагаемую структуру запроса, понимать контекст параметра и замечать различия в поведении приложения.

Во время практики пользователь исследует ошибки SQL, условия авторизации, объединение результатов и слепые методы определения поведения базы. Отдельное внимание уделяется влиянию прав СУБД и тому, почему одна и та же ошибка в разных конфигурациях приводит к разным последствиям.

В модуле предусмотрено 12 практических заданий на контролируемых стендах. Сценарии постепенно усложняются, но каждое упражнение строится вокруг понимания механики, а не бездумного запуска инструментов.

Заключительная часть посвящена защите. Пользователь исправляет небезопасную конкатенацию, переводит код на подготовленные запросы, ограничивает динамические параметры белыми списками и проверяет, что уязвимость действительно закрыта.

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

База данных выполняет именно то, что ей передали

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

Граница безопасности должна проходить внутри приложения. Структуру SQL определяет разработчик, а пользователь управляет только значениями.

Если эта граница размыта, обычное поле поиска может превратиться в способ изменить запрос. Если она задана через параметры, ограниченные права и безопасные методы работы с данными, даже самый необычный ввод остаётся обычным текстом.

Чтобы находить SQL-инъекции, нужно понимать язык базы данных. Чтобы защищаться от них, нужно перестать собирать SQL из строк.