Что хотят услышать интервьюеры:

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

Определение:

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

Пример использования:

Пусть есть форма входа, где приложение собирает запрос так:

username = request.form["username"]
password = request.form["password"]

query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'"
cursor.execute(query)

Если злоумышленник введёт в поле имени пользователя:

admin' --

то итоговый запрос может стать таким:

SELECT * FROM users WHERE username = 'admin' --' AND password = 'anything'

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

Пояснение кода:

В этом примере код не требуется, но важно понять логику по шагам:

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

Безопасный подход — использовать параметризованные запросы, где данные передаются отдельно от текста SQL. Например, вместо конкатенации нужно передавать параметры через драйвер БД.

Ключевые моменты:

SQL-инъекция возникает из-за смешивания SQL-кода и пользовательских данных.
Основная причина уязвимости — строковая сборка запросов.
Атака может привести к обходу аутентификации, утечке или изменению данных.
Защита: параметризованные запросы, а не f-строки или конкатенация.
Дополнительно полезны ограничение прав пользователя БД и серверная валидация ввода.
Фильтрация символов сама по себе не является надёжной заменой параметризации.

Могли бы вы привести пример атаки через внедрение вредоносного SQL-кода в приложение?