Блог

У меня есть сценарий powershell (но я думаю, что эти соображения можно распространить на любой сценарий, для интерпретации и выполнения которого требуется среда выполнения), который выполняет то, что мне также нужно предоставить интерфейсу веб-приложения в качестве вызываемого API REST, и меня попросили напрямую вызвать сам сценарий из веб-метода, но, хотя технически это возможно, метод веб-api, запускающий оболочку/процесс для выполнения сценария и перенаправление stdin/stdout/stderr, выглядит для меня очень плохой практикой. Существует ли какой-либо конкретный риск для безопасности при выполнении чего-то подобного?

Чтение этого вопроса наводит на мысль о том, скольким из десяти основных уязвимостей безопасности OWASP он может подвергнуть ваш сайт.

1. Недостатки инъекций — это, безусловно, высокий риск. Конечно, есть способы исправить это. Параметризация всех входных данных с помощью строго типизированных дат и чисел вместо строк-это один из методов, который можно использовать, но он может не соответствовать вашему бизнес-кейсу. Вы никогда не должны разрешать выполнение кода, предоставленного пользователем, но если вы принимаете строки в качестве входных данных и запускаете сценарий на основе этих входных данных, становится очень трудно предотвратить выполнение произвольного кода.
2. Нарушена аутентификация — возможно, уязвима. Если вы заставите пользователя пройти аутентификацию до достижения вашего сценария (вероятно, вам следует это сделать), есть вероятность, что пользователь повторно использует свои учетные данные в другом месте и подвергнет эти учетные данные атаке грубой силы. Вы блокируете учетные записи после слишком многих попыток? У вас есть двухфакторная аутентификация? Разрешаете ли вы использовать слабые пароли? Все это необходимо учитывать при внедрении нового механизма аутентификации.
3. Доступ к конфиденциальным данным — вероятно, уязвим, в зависимости от вашего сценария. Позволяет ли скрипт читать файлы и возвращать их содержимое? Если не сейчас, то сделает ли это в будущем? Даже если он никогда не предназначался для этого, в сочетании с другими эксплойтами скрипт может считывать файл с пути, находящегося за пределами веб-каталога. Очень сложно предотвратить эксплойты обхода каталогов, которые позволили бы злоумышленнику получить доступ к вашему серверу или даже ко всей сети. Скомпилированный код и веб-сервер во многих случаях предотвращают это.
4. Внешние сущности XML — возможно, уязвимы, в зависимости от ваших требований. Если вы разрешите предоставленный пользователем XML, плохой парень может внедрить другие файлы и создать хаос. Это легче уловить, когда вы используете стандартные веб-инструменты.
5. Нарушенный контроль доступа — определенно уязвим. Приложение веб-API может применять пользовательские элементы управления и устанавливать уровни разрешений в контроллере C#. Исключения обрабатываются с помощью кодов состояния HTTP, которые указывают, что запрос не был разрешен. В отличие от этого, Powershell выполняется в контексте безопасности пользователя, вошедшего в систему, и позволяет вносить изменения на уровне системы, даже если не выполняется эскалация. Если используется ошибка внедрения, код будет выполняться в контексте безопасности веб — сервера, а не пользователя. Вы можете быть удивлены, как много может сделать IIS_USER (или другая учетная запись службы пула приложений). Во — первых, если плохой парень работает в контексте учетной записи службы, он может отключить весь ваш сайт одним запросом, заблокировав эту учетную запись или изменив пароль-задача, которая намного проще с помощью сценария Powershell, чем с помощью скомпилированного кода C#.
6. Неправильная конфигурация системы безопасности — вероятно, уязвима. Для запущенного сценария потребуется собственная конфигурация безопасности вне рамок, которые вы используете для веб-API. Готовы ли вы повторно реализовать что-то вроде утверждений OAuth или списков управления доступом?
7. Межсайтовые сценарии — вероятно, уязвимы. Вы повторяете вывод сценария? Если вы не очищаете ввод и вывод, сценарий может повторять некоторый Javascript, который отправляет содержимое файлов cookie пользователя на вредоносный сервер, предоставляя им доступ ко всем ресурсам пользователя. Подделка межсайтовых запросов также является риском, если входные данные не будут проверены.
8. Небезопасная десериализация — Вероятно, не уязвима.
9. Использование компонентов с известными уязвимостями — значительно повышенная уязвимость по сравнению с скомпилированными. Powershell предоставляет доступ ко всему набору библиотек, на которые в противном случае потребовались бы явные ссылки в скомпилированном приложении.
10. Недостаточное ведение журнала и мониторинг — вероятно, уязвимы. IIS регистрирует запросы по умолчанию, но Powershell ничего не регистрирует, если вы явно не записываете в файл или не запускаете расшифровку. Ни один из методов не предназначен для параллелизма и может привести к проблемам с производительностью или функциональностью для общих файлов.

Короче говоря, 9 из 10 основных уязвимостей могут повлиять на эту реализацию. Я бы надеялся, что этого будет достаточно, чтобы, по крайней мере, помешать вам опубликовать свой сценарий. В основном проблема в том, что вы используете инструмент (Powershell) для целей, для которых он не предназначался.