#c# #.net #asp.net #razor #mailmerge
#c# #.net #asp.net #razor #mailmerge
Вопрос:
У меня есть функция, подобная слиянию почты, которая берет шаблон, некоторый бизнес-объект и создает html, который затем преобразуется в PDF.
Я использую RazorEngine для преобразования шаблона модели в html-бит.
Если я позволю пользователям указывать шаблоны, какие риски я беру на себя? Возможно ли снизить какие-либо риски?
Например, могут ли пользователи выполнять произвольный код? (удаление файлов, изменение базы данных и т. Д.?) Есть ли какой-нибудь способ, которым я могу обнаружить подобные вещи? (Я знаю, что в целом это было бы невозможно, но фрагменты кода в шаблоне razor должны быть свойством модели gets или, возможно, операторами if, основанными на значениях свойств модели).
Я в основном доверяю здешним пользователям (это небольшой частный проект), но по мере продвижения движков шаблонов этот кажется чрезмерно мощным для этого приложения.
Ответ №1:
В версии 3 я представил an IsolatedTemplateService , который поддерживает синтаксический анализ / компиляцию шаблонов в другом AppDomain . Вы сможете контролировать создание домена приложения, в котором будут компилироваться шаблоны, что означает, что вы можете вводить любые требования безопасности, какие захотите, применяя политики безопасности к самому дочернему домену приложения.
В будущих версиях я надеюсь представить общий способ добавления расширений в конвейер, чтобы вы могли выполнять такие вещи, как проверка генерации кода. Я бы предположил, что это позволит использовать сценарии для проверки типов сгенерированного кода перед его компиляцией.
Несколько дней назад я выложил раннюю версию RazorEngine (v3) на GitHub. Не стесняйтесь проверить это. https://github.com/Antaris/RazorEngine
Комментарии:
1. Спасибо, я буду следить за RazorEngine — он кажется действительно полезным (но не для этого приложения, в настоящее время).
Ответ №2:
Файл cshtml Razor способен выполнять любые. ЧИСТЫЙ код в контексте сайта, так что да, разрешение их предоставления пользователями представляет угрозу безопасности.
Вам было бы лучше принять более общий шаблон HTML с пользовательскими токенами для ввода данных модели.
Комментарии:
1. Спасибо. Сейчас я ищу движок шаблонов в другом месте. Мне показалось, что Razor небезопасен в этом приложении, но я не нашел никого, кто делал это предупреждение (и есть много статей о том, как использовать его для слияния почты).
Ответ №3:
Я считаю, что удаление using операторов и замена любого @System.[...] подобного System.IO.File.Delete(filepath) с помощью регулярных выражений может уменьшить количество возможных дыр в безопасности.
Имейте в виду, что шаблон выполняется внутри контекста и может получить доступ только к тому, что доступно в нем, но это включает также сборки .NET Framework.
Комментарии:
1. @{ использование System. IO;} Без попыток я бы заподозрил, что код будет работать просто отлично, и я уверен, что найдутся другие умные способы обойти практически любое регулярное выражение. Я бы сказал, что это небезопасно, и лучше создать что-то простое и безопасное с нуля
2. Это правда. Но единственный способ, который кто-то может использовать. СЕТЕВЫЕ библиотеки должны быть написаны с использованием System .[…] или с использованием NS = System .[…] или введите полное пространство имен. (Пока я не могу придумать другого способа). Тем не менее, я согласен, что это опасно, но все идет на компромисс, и если кто-то должен использовать RazorTemplates, я считаю, что позаботиться о .NET Lib — хорошее начало.
3. Я уверен, что вы могли бы сделать несколько забавных вещей с отражением, если бы вы действительно старались превзойти регулярные выражения … … хотя, я полагаю, в какой-то момент вам нужно было бы вызвать что- то напрямую.
4. @RuneFS — этот конкретный пример не будет работать, поскольку блоки кода становятся частью тела метода Execute .