Код
query = "SELECT * FROM users WHERE name = '" + name + "'
уязвим из‑за конкатенации пользовательских данных в SQL — это классическая SQL‑инъекция. Ниже — разбор.
Уязвимости
- SQL‑инъекция: отсутствие параметризации приводит к выполнению произвольного SQL.
- Недостаточная валидация/фильтрация и некорректная обработка кодировок (UTF‑7/UTF‑8) — обход фильтров.
- Возможность «вторичной» (second‑order) инъекции: данные записаны в БД и позже используются в другом запросе.
- Привилегии БД не ограничены — при успешной инъекции можно повредить/удалить данные.
- Если введённые данные затем выводятся в HTML без экранирования — риск XSS.
Типичные атаки и примеры полезной нагрузки
- Тавтология (выбрать всех): name = "' OR 1=1--" → добавляет условие $1=1$ и возвращает все строки.
- Комментирование остатка запроса: использование `--` или `/* ... */` для игнорирования части запроса.
- UNION‑эксплойт для вытягивания данных из других таблиц: например `name = "' UNION SELECT username, password FROM admin --"`.
- Stacked queries (если СУБД поддерживает несколько выражений): `name = "'; DROP TABLE users; --"` — удаление таблицы.
- Time‑based blind SQLi: `name = "' OR IF(SUBSTR(password,1,1)='a', SLEEP(5), 0) --"` — задержка $5$ секунд для определения символа.
- Error‑based и boolean‑based блочные инъекции — извлечение данных через сообщения об ошибках или логические ответы.
- Чтение файлов/выполнение ОС (зависит от привилегий/СУБД): `LOAD_FILE('/etc/passwd')` и пр.
- Обход фильтров через кодировки, экранирование, юникод‑подмены.
Безопасные способы передачи данных на сервер
1. Параметризованные запросы / подготовленные выражения (prepared statements). Это основной и надёжный метод. Примеры:
- PHP (PDO):
$stmt = $pdo->prepare("SELECT * FROM users WHERE name = ?");
$stmt->execute([$name]);
- Java:
PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE name = ?");
ps.setString(1, name);
ResultSet rs = ps.executeQuery();
- Python (psycopg2):
cur.execute("SELECT * FROM users WHERE name = %s", (name,))
2. ORM / query builders: используют байндинг параметров и защищают от ручной конкатенации (например SQLAlchemy, Eloquent).
3. Хранимые процедуры с параметрами — при правильной реализации тоже безопаснее конкатенации (но не заменяют валидацию).
4. Белый список / валидация входа: проверять формат (регулярные выражения), длину, набор допустимых символов; для идентификаторов — выбирать из списка допустимых значений.
5. Экранирование как крайний вариант: использовать встроенные функции драйвера (например mysqli_real_escape_string), но это ненадёжно при отсутствии корректной кодировки и сложных контекстах — предпочитайте параметризацию.
6. Для запросов с LIKE — правильно экранировать метасимволы (`%`, `_`) в параметре и использовать параметризованные выражения.
7. Минимальные привилегии БД: аккаунт приложения должен иметь только нужные права (SELECT/INSERT/UPDATE по необходимости), не CREATE/DROP/ADMIN.
8. Логирование, WAF и мониторинг: обнаруживать подозрительные паттерны инъекций и аномалии.
9. Экранирование при выводе в HTML/JS: если введённое имя будет отображаться в веб‑странице — использовать соответствующее HTML-экранирование, чтобы избежать XSS.
Короткий вывод: никогда не формируйте SQL простым сложением строк с пользовательским вводом — используйте параметризованные запросы (prepared statements) и валидацию/ограничение прав.