Недостатки Blacklisting: Почему "чёрные списки" всегда проигрывают

Стратегия «чёрного списка» (Blacklisting) — это попытка защититься, перечислив все заведомо «плохие» слова и символы: SELECT, UNION, кавычки или комментарии. Несмотря на кажущуюся логичность, в мире SQL-инъекций это лишь иллюзия безопасности, которая легко разрушается опытным атакующим.

Разберем три классических способа, которыми хакеры обходят подобные примитивные фильтры.

---

1. Механика: "Игра в кошки-мышки" с регистром

Представьте типичный защитный код на Go:

// ❌ ОПАСНО: Поверхностная проверка по списку слов
func isSafe(input string) bool {
    badWords := []string{"SELECT", "UNION", "DROP"}
    for _, word := range badWords {
        if strings.Contains(input, word) {
            return false // Заблокировано
        }
    }
    return true
}

Злоумышленник просто изменит регистр букв: sElEcT или union строчными. Простая проверка strings.Contains пропустит такое слово, но для большинства СУБД это будет всё та же валидная SQL-команда, которая успешно выполнится.

---

2. Кодирование: Прячемся в символах

Если вы запретили использование одинарной кавычки ', хакер может прибегнуть к кодированию:

• %27 (URL encoding)
• 0x27 (Hex encoding)

Фильтр увидит безобидную строку %27 и пропустит запрос. Однако на следующих этапах — в веб-фреймворке или в самой базе данных — эти данные будут декодированы обратно в кавычку, и инъекция сработает так, будто никакой защиты и не было.

---

3. Таблица работы: Атака vs Поверхностный фильтр

Ввод хакера	Результат фильтрации	Итог в базе данных
UNION SELECT	🔴 Заблокировано	—
UNI/**/ON SELECT	🟢 Пропущено	UNION SELECT (в MySQL)
uNiOn SeLeCt	🟢 Пропущено	UNION SELECT
0x554e494f4e	🟢 Пропущено	UNION

---

4. Почему "White-list" (Белый список) — это единственный путь

Количество вредоносных комбинаций, учитывая разные кодировки и особенности СУБД, практически бесконечно. В то время как список ожидаемых «хороших» данных (например, числовой id или конкретное имя колонки) всегда ограничен. Намного надежнее разрешить 10 известных безопасных полей, чем пытаться предугадать 10 000 вариантов хакерских нагрузок.

В лабораторной этого модуля точка входа — поле поиска каталога, защищённое наивным uppercase-блэклистом. Прямой UPPERCASE-payload SQL-keyword (например, UNION) сразу блокируется WAF:

Идея пейлоада строится на простом наблюдении из таблицы выше: WAF сравнивает строку только по uppercase-словарю и не нормализует регистр. Конкретный обходной payload в подсказках лабы намеренно не приведён — собрать его студент должен сам, опираясь на разобранные техники обхода (mixed-case, комментарии, кодировки).

---

Чёрные списки дают ложное чувство защищенности. Любая попытка «вычистить» или «исправить» пользовательский ввод вручную — это борьба с симптомами, а не с причиной.

Далее мы изучим более сложные трюки с кодировками, которые позволяют хакерам обходить даже продвинутые системы фильтрации.