Риск и атаки (кратко)
- SQL-инъекция: злоумышленник подставляет в `user_input` SQL‑фрагменты (напр. `' OR '1'='1` или `'; DROP TABLE users; --`), что приводит к изменению смысла запроса. Возможные последствия: чтение/изменение/удаление данных, обход аутентификации, получение доступа к ОС (через расширения), удалённое исполнение команд, эскалация привилегий, утечка конфиденциальных данных.
- Типы атак: классические (логические: `OR 1=1`), error‑based, UNION‑based, blind (time‑based, boolean‑based), stacked queries (если поддерживаются), out‑of‑band (через DNS/HTTP), second‑order SQLi (вредоносные данные сохранены и позже использованы в небезопасном запросе).
- Дополнительные риски: порча логов, poisoning, XSS в сочетании с утекшими данными, поведение библиотеки (некорректное экранирование) и человеческий фактор.
Почему конструкция опасна
- Конкатенация строк вставляет ввод прямо в SQL, без разделения кода и данных — позволяет управлять синтаксисом запроса.
Безопасные альтернативы (общие принципы)
1. Использовать параметризованные запросы / подготовленные выражения (prepared statements, bind parameters).
2. Ограничивать права подключения (least privilege).
3. Валидировать/фильтровать ввод по allow‑list (формат, длина) — но не как основную меру против SQLi.
4. Не полагаться на экранирование как единственное средство; использовать только проверенные библиотечные функции при отсутствии параметров.
5. Ограничить возможность выполнения нескольких выражений (multi‑statements) на уровне драйвера, если не нужен.
6. Логирование, IDS/WAF, мониторинг аномалий, периодические тесты на SQLi (сканеры, pentest).
7. Хранить секреты и права отдельно, использовать минимальные привилегии БД.
Примеры безопасной реализации по СУБД / API
- MySQL (PHP PDO)
- Неправильно: `"... WHERE name = '" + $user_input + "'"`.
- Правильно (PDO, подготовленное выражение):
```php
$stmt = $pdo->prepare("SELECT * FROM users WHERE name = ?");
$stmt->execute([$user_input]);
$rows = $stmt->fetchAll();
```
- Если нужен LIKE: `WHERE name LIKE ?` и передавать `"$user_input%"`, при этом экранировать `%` и `_` в пользовательском вводе.
- MySQL (mysqli, если нельзя PDO)
- Использовать prepared statements или, если только экранирование: `mysqli_real_escape_string` — менее надежно, легко ошибиться.
- PostgreSQL (psycopg2, Python)
```python
cur.execute("SELECT * FROM users WHERE name = %s", (user_input,))
```
- В чистом libpq/JDBC тоже использовать bind parameters (`$1` / `?` / PreparedStatement). Для time‑based атаки 공격자는 может использовать `pg_sleep()`, поэтому проверять и лимитировать возможности запросов.
- SQLite (python sqlite3)
```python
cur.execute("SELECT * FROM users WHERE name = ?", (user_input,))
```
- Microsoft SQL Server (C#, ADO.NET)
```csharp
using var cmd = new SqlCommand("SELECT * FROM users WHERE name = @name", conn);
cmd.Parameters.AddWithValue("@name", userInput);
var reader = cmd.ExecuteReader();
```
- Отключить MULTI_STATEMENTS/allow user‑defined_batch если не нужен; учесть, что SQL Server позволяет несколько выражений через `;` в некоторых драйверах.
- Oracle (JDBC / cx_Oracle)
```java
PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE name = ?");
ps.setString(1, userInput);
```
или
```python
cur.execute("SELECT * FROM users WHERE name = :name", name=user_input)
```
- Java (JDBC)
```java
PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE name = ?");
ps.setString(1, userInput);
ResultSet rs = ps.executeQuery();
```
- ORM (примерные рекомендации)
- Использовать ORM‑методы или query builders, которые параметризуют запросы (e.g., SQLAlchemy, Entity Framework). При использовании "raw SQL" в ORM — передавать параметры через bind variables, не конкатенировать строку.
Особые случаи и советы
- LIKE: экранировать `%` и `_` в пользовательском вводе или использовать explicit escape: `WHERE name LIKE ? ESCAPE '\'` и заменять `\`, `%`, `_`.
- Сложные динамические запросы: строить структуру SQL строго из белого списка допустимых имен столбцов/операторов; параметры — отдельно.
- Stored procedures: безопасны, если внутри используются bind parameters; не безопасны, если процедура сама конкатенирует вход.
- Second‑order SQLi: проверять и параметризовать данные при каждом использовании, не только при вводе.
- Экранирование vs параметризация: экранирование опасно и легко ошибочно; предпочитать bind‑параметры.
Короткие примеры атак (для понимания риска)
- Базовая обходная попытка: `user_input = "' OR '1'='1"` → возвращает все строки.
- Уничтожение данных (если разрешены stacked queries): `user_input = "a'; DROP TABLE users; --"`.
Резюме (одно предложение)
- Не храните SQL как конкатенацию строк с пользовательскими данными — используйте параметризованные запросы/подготовленные выражения, ограничивайте привилегии и валидируйте ввод; конкретная реализация зависит от СУБД и драйвера (см. примеры выше).