Кратко о проблеме в примере
- Запрос строится конкатенацией: SELECT * FROM users WHERE name = ' " + userInput + " '; — это делает приложение уязвимым к SQL-инъекции: пользовательский ввод попадает в SQL без синтаксической границы и фильтрации.
Возможные уязвимости и способы эксплуатации (основные типы)
- Тавтология (bypass аутентификации). Payload: ${}^{\prime }O{R}^{\prime }{1}^{\prime }{=}^{\prime }1$
Пример: если userInput = ${}^{\prime \prime }O{R}^{\prime }{1}^{\prime }{=}^{\prime }{1}^{\prime }$, то получится: SELECT * FROM users WHERE name = '' OR '1'='1'; — вернёт все строки.
- UNION-инъекция (добыча данных). Payload: ${}^{\prime }UNIONSELECTusername,passwordFROMadmin--$
Используется для объединения результатов произвольного SELECT.
- Error-based (через ошибки). Payload: ${}^{\prime }OR(SELECT1/0)=1--$
Приводит к ошибкам, из которых можно извлечь данные через текст ошибки.
- Blind/Boolean-based (побитовое/логическое): проверяет условия и по ответу приложения восстанавливает данные. Пример: ${}^{\prime }OR(SUBSTRING(password,1,1){=}^{\prime }{a}^{\prime })--$.
- Time-based blind: вызывает задержку при истинности условия (exfiltration). Пример (MySQL): ${}^{\prime }ORIF(SUBSTRING((SELECTpasswordFROMusersWHEREname{=}^{\prime }admi{n}^{\prime }),1,1){=}^{\prime }{a}^{\prime },SLEEP(5),0)--$.
- Stacked queries / piggybacking (если драйвер разрешает несколько выражений): payload: ${}^{\prime };DROPTABLEusers;--$.
- Second-order injection: вредоносный ввод сохраняется и позже используется в SQL в другом месте.
Инструменты и приёмы для обнаружения/эксплуатации
- sqlmap — автоматическое сканирование и эксплуатация SQL-инъекций.
- Burp Suite (Intruder, Repeater), OWASP ZAP — интерактивное тестирование и проксирование.
- Наборы payload'ов: payloadsAllTheThings, SQLi cheat-sheets.
- Ручное тестирование: подставлять типичные полезные нагрузки (таутологии, UNION, время/ошибки), анализировать ответы и временные характеристики.
Как предотвращать (практические рекомендации, приоритеты)
- Параметризованные запросы / Prepared statements (главное средство). Пример (PHP PDO):
$stmt = $pdo->prepare("SELECT * FROM users WHERE name = ?"); $stmt->execute([$userInput]);
- Использовать параметризацию в ORM/DB API (Hibernate, JPA, psycopg2, PDO и т.д.), не строить SQL строкой.
- Whitelist-валидация и нормализация ввода: если ожидается имя/ид — проверять по шаблону, длине, допустимым символам.
- Экранирование только как запасной метод и через специализированные функции драйвера (не полагаться на addslashes).
- Ограничение привилегий БД: учетная запись приложения — минимум прав (нет DROP/CREATE если не нужно).
- Отключение поддержки нескольких запросов в одном вызове, если драйвер/БД позволяет (PREVENT stacked queries).
- Минимизировать раскрытие ошибок: не возвращать внутренние сообщения БД пользователю; логировать безопасно.
- WAF как дополнение (ModSecurity, облачные WAF) — снижает риск, но не заменяет безопасный код.
- Регулярное тестирование: автоматизированные сканеры (DAST), статический анализ кода (SAST), ревью кода и pentest.
- Мониторинг и alert'ing: аномальные запросы, длительные запросы (time-based), частые 500 ошибки.
Короткие примеры безопасной практики (языки)
- Python (psycopg2): cur.execute("SELECT * FROM users WHERE name = %s", (userInput,))
- Java (JDBC): PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE name = ?"); ps.setString(1, userInput);
- PHP (PDO): $stmt = $pdo->prepare("SELECT * FROM users WHERE name = :name"); $stmt->execute(['name' => $userInput]);
Дополнительно (важно)
- Комбинируйте меры: параметризация + валидация + минимальные права + логирование/сканирование.
- Не полагайтесь только на WAF или на простое экранирование.
Если нужно — могу привести конкретные payload'ы для тестирования или примеры кода для вашего стека.