Инъекционные атаки

Авторизация прежде всего: это вскрытие, которое делает защитник

Всё ниже предполагает подписанное задание с явным охватом (scope) — намеренно уязвимый стенд, CTF, твоё собственное приложение или программу багбаунти с целью в списке активов. Прощупывание живого приложения, которым ты не владеешь, на инъекции — это несанкционированный доступ в большинстве юрисдикций, точка; один неправильно сформированный запрос к чужой базе может повредить или уничтожить данные, так что «я просто тестировал» — не оправдание. Мы изучаем рассуждения атакующего по одной причине: нельзя надёжно закрыть класс уязвимостей, который понимаешь лишь как пункт чек-листа. Читай это как вскрытие, которое защитник проводит над собственным кодом, учась видеть запрос так, как его видит атакующий, чтобы сломать атаку до того, как она появится. Здесь нет готовых пейлоадов для копирования — только механизм, чтобы ты узнал его на код-ревью и убил в дизайне.

Один механизм за каждой «инъекцией»

SQL-инъекция, OS-command-инъекция, NoSQL-инъекция, LDAP-инъекция, XPath-инъекция, даже server-side template injection — безопасники называют их по-разному, но это один и тот же баг в разных интерпретаторах. Механизм всегда такой: приложение строит инструкцию (SQL-выражение, shell-команду, LDAP-фильтр), конкатенируя доверенный код с недоверенным вводом как текст, и затем отдаёт получившуюся строку интерпретатору, который заново её разбирает. Интерпретатор понятия не имеет, какие байты написал разработчик, а какие подставил пользователь, — он видит одну строку и разбирает её по своей грамматике. Если байты пользователя содержат символы, синтаксически значимые в этой грамматике (кавычку, завершающую строковый литерал; точку с запятой, завершающую выражение; обратный апостроф, открывающий подоболочку), пользователь только что написал код, и интерпретатор его выполняет.

Эта переформулировка и есть весь урок. Уязвимость не в том, что «пользователь ввёл что-то плохое». Она в том, что система смешала два уровня доверия в один канал и затем разобрала этот канал по грамматике. Вся работа атакующего — найти место, где его ввод попадает внутрь интерпретируемой строки, и подать ввод, который вырывается из слота данных в слот кода. Апостроф в поле поиска — ровно это: в SQL ' завершает строковый литерал, поэтому ввод с апострофом может закрыть задуманный разработчиком литерал и продолжить выбранным атакующим SQL.

Как атакующий рассуждает о точке инъекции

Атакующий не начинает с уверенности, что баг есть, — он прощупывает границу между данными и кодом. Это небольшой дисциплинированный цикл, и понимание его — то, что позволяет защитнику воспроизвести и починить проблему.

1. Найти сток (sink). Локализовать, где пользовательский ввод правдоподобно достигает интерпретатора — фильтр поиска, параметр сортировки, id в URL, форма логина, имя файла экспорта, заголовок. Всё, что приложение может подать в запрос или команду.
2. Возмутить синтаксис. Отправить ввод с символом, специальным для предполагаемой грамматики (для SQL — кавычку; для shell — метасимвол), и смотреть, что изменится. Ошибка 500, иное число результатов или сдвиг по времени — всё это сигналы, что ввод дошёл до парсера и изменил его.
3. Подтвердить и охарактеризовать. Отличить реальную инъекцию от случайной ошибки, переключаясь между вводом, который должен оставить синтаксис валидным, и вводом, который должен его сломать. Если «валидный» грузится нормально, а «сломанный» падает — ввод разбирается, и это подтверждённая точка инъекции.
4. Определить контекст и канал. Понять, какой интерпретатор (SQL? shell? LDAP?) и приходят ли результаты в ответе (in-band) или их надо выводить косвенно (слепая, blind).

Контексты: один баг, разный интерпретатор и радиус поражения

Причина, по которой инъекция держится в топе любого списка рисков, — она обобщается на каждый интерпретатор, с которым говорит бэкенд, а радиус поражения масштабируется с тем, что этот интерпретатор умеет.

OS-command-инъекция заслуживает отдельной заметки, потому что её радиус поражения — худший в списке. SQL-инъекция компрометирует базу; command-инъекция компрометирует хост, выполняясь с привилегиями процесса приложения, — что на плохо изолированной машине может означать всю машину и всё, до чего она дотягивается. Корневая причина та же — ошибка конкатенации строк, просто интерпретатором служит shell, а не база. И структурный фикс зеркалит SQL-овский: не отдавай shell строку, которую он заново разбирает на метасимволы, — вызывай целевую программу напрямую, передав её аргументы отдельным списком, чтобы ОС никогда не запускала shell, способный истолковать точку с запятой или пайп как новую команду.

Слепая инъекция: когда ответ не возвращается

Новички полагают, что инъекция требует, чтобы база выводила данные на страницу. Это не так. Слепая инъекция (blind) — случай, когда приложение не возвращает атакующему результаты запроса или ошибки, но атакующий всё равно может извлекать данные по биту за раз, задавая вопросы да/нет и наблюдая побочный эффект. Два классических канала:

• Булева (boolean-based): сформировать ввод так, чтобы запрос был истинным в одном случае и ложным в другом, и смотреть, как различается ответ — другая страница, другая длина, наличие или отсутствие элемента. Каждый запрос утекает один бит («первый символ хеша админа — это „a“?»).
• Временная (time-based): заставить запрос спать, когда условие истинно. Данные нигде не появляются; атакующий читает их чисто по тому, сколько занимает ответ. Это медленно — часто автоматизируется, выгружая хеш символ за символом за тысячи запросов, — но полно: слепой временной канал способен извлечь целую базу при достаточном терпении.

Защитный вывод из слепой инъекции груб и проясняющ: подавление сообщений об ошибках не чинит инъекцию. Команды регулярно «исправляют» баг, спрятав ошибку базы, которая его впервые выдала. Точка инъекции на месте; атакующий просто переключается на слепую технику и продолжает — теперь без удобной ошибки, которая подсказала бы твоему мониторингу. Сокрытие симптома убирает твой собственный сигнал и оставляет уязвимость полностью эксплуатируемой.

Почему параметризация — единственный фикс, закрывающий класс

Свяжем воедино. Инъекция существует, потому что код и данные делят один канал, который интерпретатор заново разбирает. Каждый устойчивый фикс работает через разделение этих каналов на уровне архитектуры, так что недоверенный ввод доставляется как значение, структурно неспособное быть истолкованным как синтаксис. Для SQL это параметризованные запросы (они же подготовленные выражения / связанные параметры): база получает шаблон запроса, планирует его и только потом принимает значения — которые трактует как непрозрачные данные, никогда как часть структуры выражения. Для OS-команд — вызов бинарника с вектором аргументов вместо shell-строки. Для NoSQL — типизированные билдеры запросов, отклоняющие ввод формы оператора. Эшелонированная защита по-прежнему важна — учётки БД с минимальными правами, чтобы успешная инъекция читала меньше; валидация ввода как allowlist, чтобы рано отбросить некорректное; структурированное логирование, чтобы засечь прощупывание, — но это снижает ущерб, а не закрывает дыру. Закрывает её только разделение кода и данных, и поэтому параметризованный запрос, а не WAF-правило, — первый и последний ответ зрелого инженера на инъекцию.