从编写 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 的新手)。假设输出只是确定某些消息输出到某个日志所需的一些消息代码。
假设作为部署场景,某家公司使用该应用程序开展业务,该公司的某位员工编写退出实现。如果该员工想要造成损害,将会面临哪些风险:
- 日志中只有一条错误消息?
- 应用程序的类实例的内容?
- 运行应用程序的 PC 的资源?
- 更差?
我的印象是答案是 4。不是吗?myClass 获得了执行的机会,因此基本上可以执行任何应用程序可以执行的操作,这些应用程序由运行原始应用程序的用户启动。有没有办法防止这种情况?
如果是这样:出口的签名是固定的并且方法的输入不能在方法中更改是否有任何区别(如果是,是哪个)?这种有意的方法不允许动态定义类型。
这种方法,也是有意的,只允许不能改变的输入。假设字符串参数被调用者可以修改的其他类型替换,比如 StringBuilder。这会增加风险吗?
是否有更复杂(标准)的技术来降低这种方法的风险?有替代方法吗?