SQL Injection: WAF Bypass

# SQL-инъекция: обход самодельного WAF ## Сценарий Магазин снаряжения **«Гряда-Софт»** готовится впервые вынести свой Express-магазин с базой SQLite в публичный интернет, и вас позвали на «стресс-тест» защиты входа. Разработчик уже начитался про атаки на формы логина и гордится самодельным фильтром: значения полей проверяются на вхождение «опасных» SQL-слов и запрос с ними отвергается. Ваша задача — проверить, держит ли эта защита реальную нагрузку. ## Цель 1. Убедитесь, что фильтр существует и блокирует привычный вариант атаки на форму входа, а сам запрос к базе по-прежнему собирается строкой. 2. Изучите логику фильтра и найдите эквивалентную SQL-конструкцию, которую он не распознаёт. 3. Через найденный обход войдите как **admin**, купите товар **CTF Flag** и заберите флаг со страницы профиля. ## Теория Чёрный список «опасных слов» защищает только от копирования чужих примеров, но не от самой инъекции: за фильтром остаётся обработчик, склеивающий SQL из пользовательского ввода. Достаточно одной щели в списке — и атака проходит в исходном виде. **Уязвимый паттерн:** ```js const blocked = ['select', 'union', 'or', 'and', '--', '#']; // каждое слово ищется в полях формы как подстрока, с учётом регистра const query = `SELECT id FROM users WHERE username = '${username}' AND password = '${password}'`; ``` Фильтр сравнивает строки так, как это делает JavaScript — с учётом регистра, а SQL ключевые слова регистром пренебрегает. Смешанный регистр оператора или блочный комментарий вместо однострочного не совпадают ни с одним словом списка, но полностью работоспособны в запросе: условие проверки пароля отсекается, и вход выполняется без знания пароля. ## Точка входа атаки `POST /login` — форма входа с полями `username` и `password`; фильтр отвергает «подозрительный» ввод сообщением об ошибке на странице логина. * **Обычный пользователь:** `demo` / `demo` * **Целевая учётная запись:** `admin` / `???`