Итак, чтобы еще раз сформулировать вашу основную проблему:
... и, следовательно, может получить доступ к моему приложению и его текущим запущенным формам/методам/элементам управления/и т.д.
Прежде чем приступать к сложным и сложным способам загрузки, изоляции и ограничения этих расширений, вы должны кое-что узнать о Windows и CLR. Во-первых, любая программа, работающая на компьютере, может использовать ряд API-интерфейсов Windows для внедрения кода в ваш процесс. Как только код загружен в ваш процесс вами или операционной системой, доступ к среде выполнения CLR и загрузка сборок и/или выполнение кода в существующем AppDomain становятся довольно простыми.
Зная это, вы должны взвесить и сбалансировать усилия, которые вы прикладываете для ограничения «расширений». Если бы я создавал что-то подобное, меня бы больше беспокоили другие вещи, а не вредоносная часть кода расширения, манипулирующая состоянием моего приложения. Например, вот что вы можете рассмотреть:
- Загружайте только те расширения, которые одобрены вашим пользователем, позвольте им контролировать то, что разрешено, и позвольте им отозвать расширение позже, если это необходимо. Посмотрите, например, на Office или VStudio.
- Убедитесь, что эти утвержденные расширения не изменены, используя требование подписи кода (строгие имена или сертификаты подписи кода).
- Подумайте о том, чтобы иметь возможность отозвать возможность удаленного запуска расширения, если оно окажется вредоносным.
- Подтвердите хорошо оборудованный интерфейс API, чтобы позволить разработчикам легко реализовывать желаемое поведение. Если им легко использовать ваши интерфейсы для выполнения своей задачи, им не нужно будет «взламывать».
Помимо этого, на самом деле, вы больше ничего не можете сделать. Как я уже сказал, любой может атаковать ваше приложение даже с помощью вышеуказанных мер безопасности. Ваша главная задача должна состоять в том, чтобы не удивить своих пользователей. Таким образом, рекомендуется тщательно следить за тем, какой код запускает ВАШЕ приложение, но то, что делают эти расширения, когда ваши пользователи предоставляют им доступ, на самом деле не является чем-то, что вы можете полностью контролировать.
Это не означает, что изоляция AppDomain не принесет вам пользы, она может; однако, ИМХО, достаточно ограничить безопасность, не ограничивая их возможности, будет сложно.
ОБНОВЛЕНИЕ
... но если вы загружаете плагин в AppDomain, который настроен с ограниченными разрешениями, как он может использовать этот вектор?
Правильно, как я сказал в заключительных заявлениях, вы можете ограничить их доступ к неуправляемому коду в AppDomain. Это также ограничивает их возможности по разработке удобного интерфейса Windows. Я ожидаю, что большинство приложений WinForms используют по крайней мере один вызов PInvoke или неуправляемый COM-элемент управления. Это наложенное ограничение может быть приемлемым, я действительно не могу сказать без дополнительной информации о том, какую функциональность они пытаются предоставить.
Все, что я пытался сказать, это то, что, устанавливая и одобряя расширение, ваши пользователи берут на себя ответственность за разрешение запуска этого расширения. Что делает это расширение и насколько вредоносным оно может быть, не является вашей ответственностью, если, конечно, вы загрузили правильный код. Вот почему я рекомендую сосредоточить свою энергию на выполнении утвержденного кода, а не беспокоиться о том, что этот код может делать, когда он находится в вашем процессе.
person
csharptest.net
schedule
26.01.2011
