Разрешение выполнения реализаций внешнего интерфейса: каковы риски?

Question

При написании программ на ABAP следующая методология известна мне как "выход" из программы, поэтому я выбираю названия соответственно.

Предположим, вы в.Net,

1) определить интерфейс

namespace Exits {
    public interface Exit {
       int exitMethod(string s); // signature serves as example only
    }
}

2) предоставить пользователю вашего приложения способ передать имя написанной пользователем сборки ExitImplementation.dll и название класса, скажем myClass : exit, реализуя интерфейс выхода, к вашему приложению. Например, в качестве параметров командной строки или в некоторой форме.

Вы сохраняете имя пользовательской сборки в string assemblyName и имя класса (включая пространство имен) в string theImplementation а затем загрузить его и выполнить:

3)

    Assembly assembly = Assembly.LoadFrom(assemblyName); 
         // assuming assembly is deployed by user into folder where application resides
    Exit theExitImplementation = assembly.CreateInstance(theImplementation) as Exit;

    int k = theExitImplementation.exitMethod("whatever");  

(Первый вопрос, имеющий второстепенное значение: есть ли у этой техники имя за пределами мира ABAP, и как она называется?:-))

Что я хотел бы знать, так это какой риск вы берете, позволяя вашему приложению выполнять этот код пользователя (извините, если это наивный вопрос, я все еще новичок в.Net). Допустим, вывод - это только некоторый код сообщения, необходимый для определения вывода некоторых сообщений в некоторый журнал.

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

1. ничего, кроме неправильного сообщения в журнале?
2. содержание экземпляров класса приложения?
3. ресурсы ПК, на котором запущено приложение?
4. хуже?

У меня сложилось впечатление, что ответ 4. не так ли? myClass получает возможность для выполнения и, следовательно, может в основном делать то, что может делать любое приложение, которое было запущено пользователем, который запускает исходное приложение. Есть ли способы предотвратить это?

Если так: имеет ли какое-то значение (если да, то что), что сигнатура выхода фиксирована и что входные данные метода не могут быть изменены в методе? Этот метод намеренно не позволяет определять тип динамически.

Этот метод, также намеренно, позволяет только ввод, который не может быть изменен. Предположим, строковый аргумент заменен другим типом, который вызывающий может изменить, например, StringBuilder. Увеличивает ли это риск?

Существуют ли более сложные (стандартные) методы для снижения риска при таком подходе? Есть ли альтернативные подходы?

Answer 1

Подпись вызываемого метода (как правило) не имеет значения, если вы вызываете внешний ненадежный метод без каких-либо мер безопасности.

Вы должны отозвать как можно больше SecurityPermissions насколько это возможно, чтобы свести к минимуму поверхность атаки, открываемую путем вызова ненадежного кода из GAC/ доверенного кода Ознакомьтесь с этим руководством, чтобы получить общее представление о том, как работает.NET Security. Следующее должно заботиться о любом разрушительном поведении, которое может вызвать внешний код:

NamedPermissionSet ps = new NamedPermissionSet("Nothing");
ps.Deny();
CallYourUnsafeMethodHere();
CodeAccessPermission.RevertAll();