Откройте
доказательство.

Исполнение кода без авторизации в обработчике шаблонов

Иллюстративный отчёт по вымышленному приложению app.example. Запросы и серверные наблюдения показывают формат доказательств.

Описание и условия

POST /api/render/preview доступен без сессии и передаёт недоверенный шаблон в небезопасный обработчик. В сценарии обработчик интерпретирует вход как исполняемые инструкции и выполняет управляемое действие с правами app-service. Класс проблемы — CWE-94, ненадлежащий контроль генерации кода. Критичность примера — CRITICAL: для достижения контекста приложения не нужна авторизация.

Символический запрос

POST /api/render/preview HTTP/1.1
Host: app.example
Content-Type: application/json
X-Demo-Request: RCE/014-A

{
  "template": "[controlled demonstration action]",
  "proofPath": "/tmp/tibex-proof-7f2a",
  "proofToken": "TX-7F2A"
}

# No Authorization header or session cookie.
# Symbolic fixture request; the placeholder is not an exploit payload.

Вместо нагрузки указано условное действие [controlled demonstration action]. proofPath и proofToken связывают запрос с проверочным файлом.

Ответ приложения

HTTP/1.1 200 OK
Content-Type: application/json

{
  "status": "preview_ready",
  "request_id": "RCE/014-A"
}

# This response alone does not establish code execution.

HTTP 200 и status: preview_ready подтверждают лишь ответ обработчика. Исполнение устанавливается отдельным серверным наблюдением файла и токена, а не самим ответом.

Независимое наблюдение

INDEPENDENT SERVER OBSERVATION
SIMULATED, ISOLATED FIXTURE

Request reference: RCE/014-A
Observer: server-side fixture observer
Execution identity: app-service
Before request: proof file absent
After request: /tmp/tibex-proof-7f2a
Observed file contents: TX-7F2A

The observer reads the file independently of the HTTP response.
This is illustrative evidence, not a live system measurement.

Повтор из новой сессии

FRESH REPLAY / RCE/014-B
SIMULATED, ISOLATED FIXTURE

Session: new; no cookies or Authorization
Endpoint: POST /api/render/preview

{
  "template": "[controlled demonstration action]",
  "proofPath": "/tmp/tibex-proof-9c31",
  "proofToken": "TX-9C31"
}

INDEPENDENT SERVER OBSERVATION
Execution identity: app-service
Before replay: new proof file absent
After replay: /tmp/tibex-proof-9c31
Observed file contents: TX-9C31

A distinct file and token separate this replay from the first run.
The placeholder is not an exploit payload; no live request was made.

Шаги воспроизведения

1. В изолированной демонстрационной среде начать сессию без cookies и Authorization. Независимо убедиться, что /tmp/tibex-proof-7f2a отсутствует.
2. Смоделировать POST /api/render/preview с управляемым действием создания proof-файла. Символическая заглушка в опубликованном запросе не исполняется сама по себе.
3. Отдельным серверным наблюдателем зафиксировать /tmp/tibex-proof-7f2a, содержимое TX-7F2A и контекст app-service. Не использовать HTTP-ответ как доказательство исполнения.
4. Открыть новую независимую сессию без авторизации. Повторить сценарий с ранее отсутствовавшим /tmp/tibex-proof-9c31 и новым токеном TX-9C31; независимо подтвердить их появление.
5. Сохранить связанные запросы и наблюдения, затем удалить созданные демонстрационные proof-файлы из демонстрационной среды.

Подтверждённое влияние и границы

В границах примера внешний посетитель управляет действием, выполняемым процессом app-service: создаёт выбранный proof-файл с заданным токеном. Это демонстрирует исполнение кода в контексте приложения. Привилегии root, выход из контейнера, контроль всего хоста, доступ к другим сервисам и эксфильтрация данных не подтверждены и не включены в установленное влияние.

Рекомендация

1. Исключить eval, динамическую компиляцию и другие пути исполнения недоверенного ввода. Не передавать пользовательские строки в исполняемый контекст.
2. Использовать безопасный renderer с ограниченным декларативным форматом шаблонов, явной схемой входа и разрешёнными операциями. Не допускать доступа шаблона к файловой системе, процессам или сети.
3. Ограничить доступ к preview по назначению продукта. Проверка авторизации дополняет устранение исполнения кода и не заменяет его.
4. Изолировать renderer, запускать его с минимальными правами и ограниченными файловыми, сетевыми и ресурсными разрешениями. Не выдавать ему секреты и права основного сервиса без необходимости.

Критерии повторной проверки

1. Исходный сценарий и повтор с новыми путём и токеном не приводят к исполнению: независимый наблюдатель не обнаруживает proof-файлы или другие действия.
2. Недоверенные исполняемые конструкции отклоняются или безопасно обрабатываются как данные. Проверка выполняется и для авторизованного пользователя, если ему разрешён preview.
3. Обычные разрешённые шаблоны продолжают корректно отображаться. Требуемые проверки доступа и изоляция renderer остаются действующими.

Статус: демонстрационный сценарий. Исправление и повторная проверка реального продукта не заявлены.