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

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

1 голос
/ 25 ноября 2011

При написании программ на 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.Увеличивает ли это риск?

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

1 Ответ

1 голос
/ 25 ноября 2011

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

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

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