SQL Injection: Обход WAF через mixed case

# SQL-инъекция: обход самодельного WAF через регистр ## Сценарий Вы проводите аудит безопасности **PhantomSupply** — магазина снаряжения для команд тестирования на проникновение. После прошлого инцидента команда вшила в поиск каталога «WAF»: список SQL-ключевых слов верхнего регистра, и любая фраза с ними блокируется предупреждением. Архитектор уверен, что SQL-инъекции теперь невозможны. Вы знаете антипаттерн: чёрный список перечисляет «опасные» строки, а между фильтром и парсером базы всегда найдётся расхождение. ## Цель 1. Подтвердите работу фильтра: поисковые фразы с обычными SQL-ключевыми словами блокируются предупреждением. 2. Изучите логику фильтра и найдите его слепую зону — свойство записи ключевых слов, которое фильтр не учитывает. 3. Составьте поисковую фразу, которая не задевает фильтр, но исполняется базой как SQL-команда, и подберите структуру присоединяемой выборки под запрос каталога. 4. Извлеките секретный ключ администратора из скрытой таблицы — он и есть флаг лабы. ## Теория **Чёрный список ключевых слов** — попытка перечислить «опасные» строки и заблокировать их. Общая слабость всех таких фильтров: между точкой проверки (приложение) и точкой исполнения (СУБД) лежит слой нормализации. SQL не различает регистр ключевых слов, а побайтовое сравнение подстрок — различает. Любое расхождение в нормализации между фильтром и парсером порождает обход. **Уязвимый паттерн:** ```go // Фильтр ищет ключевые слова верхнего регистра побайтовым сравнением: if strings.Contains(search, keyword) { /* блокировка с предупреждением */ } // ...а затем та же фраза собирается в SQL форматированием строки: query := fmt.Sprintf("SELECT id, name, description, price, image FROM products WHERE name LIKE '%%%s%%'", search) ``` Пока ключевое слово записано точно в том виде, в каком оно хранится в списке, запрос блокируется. Но база исполняет ключевые слова в любом регистре — и вариант, записанный иначе, фильтр не замечает, а парсер послушно выполняет. Фильтр задерживает только «вежливых» атакующих, а сама инъекция живёт в конкатенации фразы в текст запроса. ## Точка входа атаки `GET /catalog` — поиск по каталогу, поле `q`. * **Обычный пользователь:** `demo` / `demo` > Лаба — наглядная демонстрация, почему чёрный список не должен быть единственной защитой от SQL-инъекций: финальное исправление — разделение SQL-кода и данных, а не более длинный список слов.