Як працює впровадження шаблонів на стороні сервера за лаштунками
Впровадження шаблону на стороні сервера відбувається, коли введені користувачем дані вбудовуються безпосередньо в механізм шаблонів та оцінюються без належної санітарної обробки чи ізоляції. Це створює вразливість 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”)) → прямий доступ до середовища виконання
Корисне навантаження гілочки
- {{7*7}} → арифметика
- {{app.request.server.all}} → змінні середовища
- {{_self.env.registerUndefinedFilterCallback(‘system’)}} → виконання коду
Ці корисні навантаження SSTI демонструють, як одна й та сама вразливість у різних двигунах призводить до різних експлуатувати шляхи, але вони завжди небезпечні.
Де ховається ін'єкція шаблонів на стороні сервера CI/CD-Керовані програми
Впровадження шаблонів на стороні сервера – це не лише ризик веб-застосунку; воно проявляється в сучасний CI/CD pipelines теж. Типові місця для сховання включають:
- Діаграми Helm у Kubernetes, де значення шаблонів відображаються динамічно
- Шаблони електронної пошти що об'єднують вхідні дані, керовані користувачем
- Dashboards де рядки запитів або дані конфігурації вводяться в шаблони
- DevOps-скрипти що генерують HTML/Markdown за допомогою шаблонізаторів.
приклад:
# ❌ Insecure Helm values with user input configMap: appMessage: "{{ .Values.message }}" If.Values.message походить з ненадійних вхідних даних, це впроваджує впровадження шаблону на стороні сервера у ваше розгортання pipeline себе.
Запобігання SSTI за допомогою безпечніших шаблонів та статичного аналізу
Зменшення вразливостей SSTI вимагає кращих шаблонів кодування та раннього виявлення.
Безпечні шаблони
- ❌ Не використовуйте рядок_шаблону_відображення або еквівалент
- ✅ Використовуйте попередньо визначені файли шаблонів та передайте очищені змінні
- ✅ Шаблонні механізми пісочниці, якщо вони доступні
- ✅ Перевіряти та екранувати введені користувачем дані перед рендерингом
Небезпечна та безпечна обробка файлів 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") Міні-контрольний список для розробників
- Ніколи не відображати необроблений введений користувачем текст безпосередньо
- Використовуйте шаблони ізольованого програмного середовища, якщо це підтримується
- Очистити та перевірити всі змінні шаблону
- Уникайте оцінювачів власних шаблонів
- Відскануйте код для рядок_шаблону_відображення або шаблони конкатенації рядків
Статичний аналіз а лінтери можуть позначати ризиковані конструкції, перш ніж вони потраплять у виробництво.
Вбудовування перевірок SSTI в DevSecOps Pipelines
Виявлення впровадження шаблонів на стороні сервера на ранній стадії дешевше та безпечніше, ніж їх виправлення пізніше. Команди DevSecOps повинні вбудовувати перевірки в pipelines:
- Commit hooksвідхилити commitз небезпечними функціями (рядок_шаблону_відображення)
- Статичні аналізатори: сканування на наявність ризику впровадження шаблонів на стороні сервера в код шаблонів
- Перевірка залежностей: позначити застарілі механізми шаблонів з відомими вразливостями SSTI
- Pipeline Ворота: блок об'єднується, доки не пройдуть перевірки SSTI
Зробивши виявлення корисного навантаження SSTI частиною CI/CD, ви запобігаєте поширенню коду, що піддається експлуатації.
Не дозволяйте впровадженню шаблонів на стороні сервера прослизнути у ваш стек
Одне впровадження шаблону на стороні сервера може призвести до ескалації через математичні трюки ({{7*7}}) до повного віддаленого виконання коду. Вразливості SSTI з'являються не лише у веб-додатках, але й у CI/CD pipelines, діаграми Helm та шаблони електронних листів.
Ключові вивезення
- Ніколи не відображати необроблений введений користувачем в шаблонах
- Перевірити та очистити всі динамічні змінні
- Різні двигуни (Jinja2, Velocity, Twig) мають різне корисне навантаження SSTI, але всі вони можуть бути озброєні.
- Використовуйте статичний аналіз та відмовостійкі вентилі в pipelines
- Регулярно перевіряйте шаблони у своєму стеку
Такі інструменти, як Ксігені допомагати командам виявляти небезпечне використання шаблонів, блокувати вразливості SSI та забезпечувати безпечні практики pipelineта залежності. У DevSecOps важливо розглядати корисні навантаження SSTI як ризик найвищого рівня, оскільки одне введення у ваш pipeline або додаток може поставити під загрозу все ваше середовище.
