Коротко — данная конкатенация строк уязвима к SQL‑инъекции. Ниже — что именно может пойти не так и как это исправить безопасно.
Уязвимости (кратко)
- SQL‑инъекция: если `username = "admin' OR '1'='1"`, запрос превратится в обход аутентификации и возврат всех/неправильных записей.
- Stacked queries (если драйвер/СУБД поддерживает несколько выражений): атакующий может выполнить дополнительные команды (`; DROP TABLE ...`).
- Blind/time‑based/boolean‑based эксфильтрация данных — атака без видимого вывода, через побочные каналы.
- Кодировка/Unicode/NULL‑байты: хитрые символы могут обойти простое экранирование.
- Логирование чувствительных данных: запись неочищенных входов в логи раскрывает полезную информацию.
- Ошибки: подробные сообщения об ошибках дают подсказки атакующему.
Безопасные паттерны и механизмы СУБД
1. Параметризованные запросы / подготовленные выражения (bind variables) — основной и рекомендуемый подход. Примеры:
- Java (JDBC):
`PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE username = ?");`
`ps.setString(1, username);`
- Python (psycopg2):
`cur.execute("SELECT * FROM users WHERE username = %s", (username,))`
- PHP (PDO):
`$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username");`
`$stmt->execute(['username' => $username]);`
2. ORM с безопасной параметризацией — используйте готовые API ORM (без string interpolation). Пример: `User.find_by(username: username)` (ActiveRecord) — только если ORM действительно параметризует.
3. Хранимые процедуры с параметрами — безопасны, если не выполняют динамическую конкатенацию внутри. Не спасают, если в процедуре строится SQL строкой.
4. Экранирование/quote-функции — только как запасной вариант, если параметризация невозможна. Для идентификаторов используйте специализированные функции (например, `quote_ident` в PostgreSQL), для литералов — `quote_literal`/экранирование на уровне драйвера. Не пользуйтесь простыми `addslashes()`.
5. Ограничьте права доступа БД — принцип наименьших привилегий: учётная запись приложения должна иметь только нужные права (например, только `SELECT` для чтения). Разделяйте права на чтение/запись/админские операции.
6. Отключите выполнение нескольких выражений за один запрос (multi‑statements) в клиенте, если это возможно.
7. Валидация и allow‑list: проверяйте формат входа (например, разрешённые символы, длину). Это дополнение к параметризации, но не её замена.
8. Корректная настройка кодировок: явно задавайте charset (UTF‑8) и используйте драйверы, которые учитывают кодировку, чтобы избежать обходов через Unicode.
9. Журналирование и обработка ошибок: не выводите подробные SQL‑ошибки пользователю; логируйте только безопасную информацию и защищайте логи.
10. Защита в глубину: WAF/IDS, rate limiting, мониторинг аномалий запросов и аудит БД.
Особые случаи
- Динамические идентификаторы (имя таблицы/колонки): нельзя параметризовать как значение. Используйте allow‑list или проверку и безопасное экранирование идентификаторов (функции СУБД), или заранее подготовленные наборы допустимых таблиц/столбцов.
- IN‑списки: используйте массивы/табличные параметры или динамическую генерацию placeholders, но всегда с bind‑переменными (ne: не вставлять значения через конкатенацию).
Резюме (рекомендации)
- Всегда используйте параметризованные запросы / prepared statements.
- Назначьте приложению минимальные права в БД.
- Валидируйте входы по allow‑list, отключите multi‑statements, настройте кодировки.
- Добавьте мониторинг, логирование и защиту на уровне приложения/сети.
Если нужно, могу привести конкретный пример безопасной реализации для вашего языкового стека/СУБД.