Шаблонная инъекция

Автор: Питер Яворски.
Переводчик: Летающий дракон.
Лицензия: CC BY-NC-SA 4.0.

Шаблонные движки позволяют разработчикам и дизайнерам отделять логику программирования от отображения данных при создании динамических веб-страниц. Другими словами, шаблонные движки отделяют данные от кода, который обрабатывает эти данные и отображает их в одном файле для пользователя. Кроме того, популярные фреймворки и системы управления контентом также отделяют HTTP-запросы от запросов к базе данных.

Серверное шаблонное внедрение (SSTI) происходит, когда шаблонные движки обрабатывают пользовательский ввод без надлежащей проверки. Это похоже на XSS. Например, jinja2 — это язык шаблонов Python, взятый из nVisium. Вот пример с 404 страницы:

@app.errorhandler(404) 
def page_not_found(e): 
    template = '''{%% extends "layout.html" %%} 
    {%% block body %%} 
    <div class="center-content error"> 
        <h1>Opps! That page doesn't exist.</h1> 
        <h3>%s</h3> 
    </div> 
    {%% endblock %%} 
    ''' % (request.url) 
    return render_template_string(template), 404

Источник: https://nvisium.com/blog/2016/03/09/exploring-ssti-in-flask-jinja2.

Здесь функция page_not_found отображает HTML, и разработчик форматирует URL как строку и показывает его пользователю. Если злоумышленник введёт http://foo.com/nope{{7*7}}, код разработчика отобразит http://foo.com/nope49, фактически выполнив переданное выражение. Когда вы передаёте фактический код Python и jinja2 оценивает его, серьёзность проблемы возрастает.

Теперь серьёзность каждого SSTI зависит от используемого шаблонного движка и типа проверки, если таковая имеется. Например, в jinja2 есть возможность удалённого выполнения кода и доступа к произвольным файлам, а в ERB, шаблонном движке Rails, есть возможность удалённого выполнения кода. В Shopify Liquid позволяет получить доступ к ограниченному количеству методов шаблона, среди прочих. То, насколько серьёзной является уязвимость, зависит от того, что вы тестируете. Хотя вы можете оценить некоторый код, он может не быть важной уязвимостью. Например, я обнаружил SSTI, используя нагрузку {{4+4}}, которая вернула 8. Однако при использовании {{4*4}} возвращается текст {{44}}, поскольку звёздочка была отфильтрована. Этот символ также переполняет специальные символы, такие как () и [], позволяя использовать только максимум 30 символов. Все эти факторы делают SSTI бесполезным.

Противоположностью SSTI является клиентское шаблонное внедрение (CSTI). Здесь CSTI не является общим сокращением уязвимости, как в других сокращениях этой книги, и я рекомендую использовать его в отчётах. Эта уязвимость возникает при использовании клиентских шаблонных фреймворков, таких как AngularJS, которые внедряют пользовательский контент в веб-страницы без обработки. Он очень похож на SSTI, за исключением того, что это клиентский фреймворк, создающий уязвимость. Тестирование CSTI в Angular аналогично тестированию jinja2 и использует {{}} и некоторые выражения внутри них.

Примеры

1. Uber Angular Template Injection

Сложность: высокая.
URL: developer.uber.com.
Ссылка на отчёт: https://hackerone.com/reports/125027.
Дата отчёта: 22 марта 2016 года.
Награда: $3000.

Описание: В 2016 году Джеймс Кеттл (разработчик Burp, одного из инструментов, рекомендованных в этой главе) использовал URL https://developer.uber.com/docs/deeplinking?q=wrtz{{7*7}} для обнаружения уязвимости CSTI. Согласно его отчёту, строка wrtz49 присутствует в исходном коде страницы, что указывает на то, что выражение было оценено.

Интересно, что Angular использует так называемую песочницу для «поддержания разумного разделения обязанностей приложения». Иногда такое разделение, обеспечиваемое песочницей, предназначено для обеспечения безопасности, ограничивая доступ потенциальных злоумышленников к определённым ресурсам. Однако в случае с Angular документация гласит: «Эта песочница не предназначена для предотвращения атак со стороны злоумышленников, желающих изменить шаблоны, и в двух фигурных скобках можно запустить произвольный код». Затем Джеймс смог обойти песочницу Angular и выполнить произвольный JavaScript-код:

https://developer.uber.com/docs/deep-linking?q=wrtz{{(_="".sub).call.call({}[$="constructor"].getOwnPropertyDescriptor(_.__proto__,$).value,0,"alert(1)")()}}zzzz

Документация Uber Angular Injection.

Он отмечает, что эта уязвимость может быть использована для захвата учётных записей разработчиков и связанных приложений.

Важный вывод

Обязательно обратите внимание на использование AngularJS и используйте синтаксис Angular {{}} для тестирования полей. Для упрощения процесса используйте плагин Firefox Wappalyzer, который покажет вам, какое программное обеспечение используется на сайте, включая AngularJS.

2. Uber Template Injection

Сложность: средняя.
URL: riders.uber.com.
Отчётная ссылка: https://hackerone.com/reports/125980.
Дата отчёта: 25 марта 2016 года.
Вознаграждение: $10 000.

Описание: Uber запустил свою программу публичных вознаграждений за обнаружение уязвимостей, которая включает в себя «карту сокровищ», которую можно найти на их сайте https://eng.uber.com/bug-bounty.

Эта карта документирует некоторые чувствительные субдомены Uber, включая взаимозависимые технологии. Поэтому для рассматриваемого сайта riders.uber.com технологическая цепочка включает Python Flask и NodeJS. Таким образом, для этой уязвимости Orange (злоумышленник) заметил использование Flask и Jinja2 и протестировал синтаксис в поле имени.

В процессе тестирования Orange заметил, что любое изменение личных данных на riders.uber.com приводит к отправке электронного письма и текстового сообщения владельцу учётной записи. Согласно своему сообщению в блоге, он протестировал {{1+1}}, что привело к тому, что сайт проанализировал выражение и отправил 2 в электронном письме.

Затем он попытался загрузить {% For c in [1,2,3]%} {{c,c,c}} {% endfor %}, который выполнил цикл for и создал следующую страницу личных данных:

Загрузка Uber blog.organge.tw.

Это привело к следующему электронному письму:

Письмо Uber после загрузки.

Вы можете видеть, что на странице личных данных отображается фактический текст, но электронное письмо фактически выполняет код и внедряет его в сообщение. Следовательно, уязвимость существует, позволяя злоумышленникам выполнять код Python.

Jinja2 пытается смягчить ущерб, помещая выполнение в песочницу, что означает ограниченные возможности, но иногда может быть обойдено. Этот отчёт первоначально поддерживался сообщением в блоге (опубликованным ранее), содержащим несколько полезных ссылок на блог nVisium.com (да, тот же самый, где демонстрируется выполнение RCE Rails), демонстрирующих, как обойти функции песочницы:

• https://nvisium.com/blog/2016/03/09/exploring-ssti-в-flask-jinja2
• https://nvisium.com/blog/2016/03/11/exploring-ssti-в-flask-jinja2-part-ii

Важный вывод

Важно понимать, какие функции используются на сайте, поскольку они часто являются ключом к использованию информации о сайте. Здесь Flask и Jinja2 стали отличным вектором атаки. И в этом примере, где есть некоторые уязвимости XSS, уязвимость может быть не такой прямой или очевидной, поэтому убедитесь, что проверили все места, где отображается текст. Здесь личные данные Uber отображаются в виде простого текста, но на самом деле в электронном письме есть уязвимость. Будет искаться что-то вроде app/views/user/#{params[:template]}

nVisium использует переданные в бэкенд примеры, которые могут рендерить .html, .haml, .html.erb — бэкенд-представления. После получения вызова Rails будет искать в каталоге файлы, соответствующие типам файлов, принятым в соглашениях Rails (концепция Rails заключается в том, что соглашение лучше конфигурации). Однако, когда вы заставляете Rails что-то рендерить и он не может найти подходящий файл для использования, он будет искать в RAILS_ROOT/app/views, RAILS_ROOT и системном корневом каталоге.

Это часть проблемы. Указание на корневой каталог вашего приложения (RAILS_ROOT) имеет смысл. Системный корневой каталог не имеет смысла, и это очень опасно.

Таким образом, используя его, вы можете передать %2f%2fpasswd, и Rails распечатает ваш файл /etc/passwd. Это страшно.

Теперь давайте продолжим: если вы передадите <%25%3dls%25>, это будет интерпретировано как <%= ls %>. В языке шаблонов ERB <%= %> означает код, который должен быть выполнен и напечатан. Таким образом, здесь это команда, которая должна быть выполнена, или разрешение на удалённое выполнение кода.

Важный вывод

Эта уязвимость присутствует не на каждом сайте Rails — она зависит от того, как сайт закодирован. Поэтому это не то, с чем могут справиться автоматизированные инструменты. Когда вы знаете, что сайт построен на Rails, будьте осторожны, потому что он следует общепринятому соглашению об URL — в основном, /controller/id используется для простого запроса GET, либо /controller/id/edit для редактирования, и так далее.

Когда вы видите этот шаблон URL, начинайте играть. Введите неожиданное значение и посмотрите, что вернётся.

Резюме

При поиске уязвимости попытка определить лежащие в основе технологии (фреймворк, механизм рендеринга фронтенда и т. д.) является хорошей идеей, чтобы обнаружить возможные векторы атаки. Различные разновидности механизмов шаблонов затрудняют точное определение того, что применимо ко всем средам, но знание используемых технологий может помочь. Обратите внимание на возможности, где текст, которым вы управляете, отображается на странице или в другом месте (например, в электронном письме).