Краткий анализ уязвимости
- Проблема: конкатенация пользовательского ввода в SQL:
\(q = "SELECT * FROM users WHERE name = '".$_GET['name']."'";\) — значит любая строка из \($_GET['name']\) попадает прямо в запрос без экранирования/параметризации → SQL-инъекция.
Возможные виды атак (перечисление)
- Аутентификация/авторизация: обход проверки (например возврат всех строк).
- Чтение конфиденен. данных: извлечение других полей/таблиц (UNION, error-based).
- Модификация данных: UPDATE/DELETE (если разрешены множественные запросы).
- Удаление/портативность БД: DROP/ALTER (через «stacked queries», если поддерживается).
- Эксплуатация через функции СУБД: чтение файлов, выполнение команд (если СУБД и права позволяют).
- Blind SQLi (boolean/time-based) для пощаговой эксфильтрации.
- Повышение привилегий косвенно (через утечку паролей/токенов).
Конкретные примеры полезной нагрузки (для тестирования/ремедиации)
- Простейший «таутологический» обход: передать в name строку
`' OR ${}^{\prime }{1}^{\prime }{=}^{\prime }{1}^{\prime }$ -- `
(в контексте запроса это даст WHERE name = '' OR ${}^{\prime }{1}^{\prime }{=}^{\prime }{1}^{\prime }$ — вернутся все строки).
- UNION-инъекция (извлечь дополнительные колонки):
` ' UNION SELECT username, password FROM users -- `
(подгонять число столбцов/типов под оригинальный SELECT).
- Stacked queries (если поддерживается клиентом/СУБД):
`'; DROP TABLE users; -- `
(может уничтожить таблицу — часто запрещено драйверами).
- Time-based (проверка наличия символа в пароле):
` ' OR (CASE WHEN (SUBSTRING(password,1,1)='a') THEN $SLEEP(5)$ ELSE 0 END) -- `
— замедление служит сигналом «истинности» условия.
- Error-based (вызвать ошибку, чтобы в сообщении утекли данные):
` ' AND (SELECT 1/0) -- `
Примечание: эти примеры даются исключительно для тестирования и исправления уязвимости.
Безопасные подходы (рекомендации)
1. Подготовленные выражения (parameterized queries / prepared statements) — самый важный шаг. Пример в PHP (PDO):
$stmt = $pdo->prepare("SELECT * FROM users WHERE name = :name");
$stmt->execute([':name' => $_GET['name']]);
(параметризация гарантирует, что ввод трактуется как значение, а не как часть SQL).
2. ORM: использовать проверенные ORM (Eloquent, Doctrine и т.п.) — они по умолчанию используют параметризацию и снижают риск ручных ошибок. Но ORM не заменяет валидацию и права.
3. Валидация и нормализация ввода:
- whitelist по типу/регулярным выражениям (например имена — только буквы/цифры/определённые символы), длина, кодировка UTF-8.
- отбрасывать/нормализовать неожиданную бинарную/специальную последовательность.
4. Экранирование только как дополнение (если по какой-то причине нельзя использовать параметризацию) — используйте функции библиотеки (PDO::quote) — но это менее предпочтительно.
5. Отключить поддержку множественных выражений в одном вызове (если возможно) и минимизировать функции СУБД, которые могут исполнять команды ОС или читать файлы.
6. Логи/мониторинг: логировать аномальные запросы, настроить WAF/IDS для блокировки типичных payload'ов.
Другие аспекты безопасности ввода
- Ошибки и информативность: не выдавать детальные SQL-ошибки пользователю — они помогают атакующему; логируйте на сервере, показывайте дружественное сообщение.
- Права доступа (принцип наименьших привилегий): аккаунт БД для приложения должен иметь только необходимые права (обычно SELECT/INSERT/UPDATE/DELETE по нужным таблицам), не права администратора, не доступ к файловой системе/функциям ОС.
- XSS: данные из БД, возвращаемые в HTML, должны выводиться с корректной HTML-энкодингом (например, PHP: htmlspecialchars($s, ENT_QUOTES, 'UTF-8')).
- CSRF: использовать CSRF-токены для предотвращения нежелательных действий от имени пользователя, защиту same-site для cookie, проверку заголовков и методов.
- Authentication/Session: безопасное хранение паролей (bcrypt/argon2), защита сессий (Secure, HttpOnly, SameSite cookies), ограничение времени жизни сессий.
- Полезные практики: ограничение длины ввода, rate-limiting, CAPTCHA для подозрительных операций, регулярные безопасные аудиты/пентесты.
Краткий чеклист для исправления конкретного фрагмента
- Перейти на подготовленные выражения (PDO/MySQLi с bind).
- Установить аккаунту БД минимальные права.
- Добавить валидацию/ограничения на \($_GET['name']\) (тип, длина, whitelist).
- Спрятать подробные ошибки SQL от пользователей.
- Внедрить логирование и мониторинг аномалий, подумать о WAF.
Если нужно — могу привести конкретный безопасный пример кода для PDO/MySQLi и объяснить вариант с проверкой whitelist для имени.