Как работает внедрение шаблонов на стороне сервера за кулисами
Внедрение шаблона на стороне сервера происходит, когда пользовательский ввод внедряется непосредственно в механизм шаблонизации и обрабатывается без надлежащей очистки или изоляции. Это создаёт уязвимость SSTI, которая позволяет злоумышленнику внедрять специально созданные полезные данные SSTI (например, {{7*7}} (в Jinja2), которые движок будет оценивать, обеспечивая всё: от раскрытия данных до выполнения произвольного кода в контексте сервера. Поскольку разные движки шаблонов предоставляют разные объекты и API, полезные данные SSTI различаются в зависимости от платформы, но представляют одну и ту же опасность: они позволяют ненадежным входным данным выходить за рамки ожидаемого потока рендеринга и выполняться во время выполнения приложения, что часто приводит к полному удаленному выполнению кода или боковому перемещению, если их не контролировать.
Минимальный уязвимый пример в Jinja2
from flask import request, render_template_string @app.route("/hello") def hello(): name = request.args.get("name", "world") # ❌ Vulnerable: directly rendering user input return render_template_string("Hello " + name) Если пользователь отправляет ?имя={{7*7}}, приложение оценит его, вернув Здравствуйте 49. Это классический пример уязвимости SSTI.
Минимальный уязвимый пример в Twig
// ❌ Vulnerable Twig usage $template = $twig->createTemplate("Welcome " . $_GET['user']); echo $template->render([]); Злоумышленник может внедрить полезную нагрузку SSTI, например {{7*7}} для доказательства выполнения кода. Опасность: простая инъекция может перерасти в чтение файлов, выполнение команд ОС или более глубокое проникновение в инфраструктуру.
Реальные эксплойты: полезные нагрузки SSTI, запускающие удаленное выполнение кода
Как только возникает уязвимость SSTI, злоумышленники пытаются перейти от математических доказательств концепции к полной RCE. Разные шаблонизаторы обрабатывают полезные данные по-разному.
Полезные нагрузки Jinja2
- {{7*7}} → арифметическое выполнение
- {{config.items()}} → утечки конфигураций сервера.
- {{ ”.__class__.__mro__[2].__subclasses__() }} → путь к RCE
Скорость полезных нагрузок
- #set($x="7″)${x} → байпас впрыска
- #set($a=$class.inspect(“java.lang.Runtime”)) → прямой доступ во время выполнения
Полезные нагрузки Twig
- {{7*7}} → арифметика
- {{app.request.server.all}} → переменные среды
- {{_self.env.registerUndefinedFilterCallback(‘system’)}} → выполнение кода
Эти полезные нагрузки SSTI демонстрируют, как одна и та же уязвимость в разных двигателях приводит к разным результатам. пути эксплуатации, но они всегда опасны.
Где скрывается внедрение шаблонов на стороне сервера CI/CD-Управляемые приложения
Внедрение шаблона на стороне сервера представляет собой риск не только для веб-приложений; оно проявляется в современный CI/CD pipelines тоже. Типичные места укрытия включают в себя:
- Хелм диаграммы в Kubernetes, где значения шаблонов отображаются динамически
- Шаблоны электронной почты которые объединяют управляемые пользователем входные данные
- Dashboards где строки запроса или данные конфигурации внедряются в шаблоны
- DevOps-скрипты которые генерируют HTML/Markdown с использованием шаблонизаторов.
Пример:
# ❌ Insecure Helm values with user input configMap: appMessage: "{{ .Values.message }}" If.Значения.сообщение исходит из ненадежных входных данных, он вводит серверную часть шаблона в ваше развертывание pipeline себя.
Предотвращение SSTI с помощью более безопасных шаблонов и статического анализа
Для снижения уязвимостей SSTI необходимы лучшие шаблоны кодирования и раннее обнаружение.
Безопасные шаблоны
- ❌ Не использовать render_template_string или эквивалент
- ✅ Используйте предопределенные файлы шаблонов и передавайте очищенные переменные
- ✅ Шаблонизаторы для песочницы (при наличии)
- ✅ Проверка и экранирование введенных пользователем данных перед рендерингом
Небезопасная и безопасная обработка файлов cookie (соответствующий риск ввода)
# ❌ Insecure: session cookie without flags response.set_cookie("session", token) # ✅ Secure: session cookie hardened response.set_cookie("session", token, httponly=True, secure=True, samesite="Strict") Мини-контрольный список для разработчиков
- Никогда не отображайте необработанный пользовательский ввод напрямую
- Используйте изолированные шаблоны, если они поддерживаются
- Очистите и проверьте все переменные шаблона
- Избегайте пользовательских оценщиков шаблонов
- Скан-код для render_template_string или шаблоны конкатенации строк
Статический анализ а линтеры могут отмечать рискованные конструкции до того, как они попадут в производство.
Внедрение проверок SSTI в DevSecOps Pipelines
Раннее обнаружение внедрения шаблона на стороне сервера дешевле и безопаснее, чем его устранение позже. Командам DevSecOps следует встраивать проверки в pipelines:
- Commit hooks: отклонять commitс опасными функциями (render_template_string)
- Статические анализаторы: сканирование на предмет риска внедрения шаблона на стороне сервера в код шаблона
- Проверка зависимости: отметьте устаревшие шаблонизаторы с известными уязвимостями SSTI
- Pipeline Ворота: блокировать слияния до тех пор, пока не пройдут проверки SSTI
Сделав обнаружение полезной нагрузки SSTI частью CI/CD, вы предотвращаете возможность отправки эксплойтного кода.
Не допускайте внедрения шаблонов на стороне сервера в ваш стек
Однократное внедрение шаблона на стороне сервера может привести к эскалации математических трюков ({{7*7}}) к полному удаленному выполнению кода. Уязвимости SSTI проявляются не только в веб-приложениях, но и в CI/CD pipelines, диаграммы Helm и шаблоны электронной почты.
Основные выводы
- Никогда не передавайте необработанные данные, введенные пользователем, в шаблоны
- Проверить и очистить все динамические переменные
- Различные двигатели (Jinja2, Velocity, Twig) имеют различную полезную нагрузку SSTI, но все они могут быть оснащены оружием.
- Используйте статический анализ и отказоустойчивые вентили в pipelines
- Регулярно проверяйте шаблоны в вашем стеке
Такие инструменты, как Ксигени помочь командам обнаружить небезопасное использование шаблонов, блокировать уязвимости SSI и обеспечить соблюдение безопасных практик pipelineи зависимости. В DevSecOps обработка полезных нагрузок SSTI как риска высшего уровня имеет важное значение, поскольку единственная инъекция в ваш pipeline или приложение может поставить под угрозу всю вашу среду.
