Jef*_*ser 13
让一切内部的DLL,然后在属性\ AssemblyInfo.cs中,将设置InternalsVisibleTo属性只指向强名称您的应用程序.
Eri*_*ert 13
这根本不可能.
整个代码访问安全系统基于以下概念:安全性决策来自运行代码的用户,而不是来自代码的作者.作为代码的作者,您无法告诉用户他们的安全决策是什么; 你是用户的仆人,而不是用户的主人.
现在,您可以使第三方代码难以使用您的代码.您可以使用各种安全属性来记录您的第三方代码的意图是不使用您的代码.这些都是很好的步骤,但在用户对您不利的任何世界中,它们实际上并不能解决您的问题.在CAS模型中,用户总是赢.
例如:您可以让代码中的方法执行安全性要求,以触发堆栈遍历以检查调用堆栈中的每个人是否都有与之关联的某些证据.例如,证据"这个DLL是用Guillaume的强名私钥签名的,它被锁在Guillaume办公室的抽屉里",这将是检查的好证据.这几乎可以保证每个调用代码的人都是你的代码.
但这不是强名签名的目的; 强名称签名的目的是帮助用户知道他们认为他们运行的代码实际上来自你.正如我们所看到的,将安全工具用于其他目的以外的目的是危险的.它给你一种完全错误的安全感.
假设您的用户想要创建一个不属于您的应用程序而使用您的DLL.用户可以编写完全可信的代码,完全可信的代码有权伪造证据.这就是"完全信任"的含义.因此,用户创建一个未经您签名的应用程序,但由于用户可以完全信任该应用程序,因此完全信任的应用程序可以伪造证据来表明代码来自您.
就此而言,没有什么能阻止用户简单地使用您的代码,删除您的签名,并将其替换为签名.你可以说你的EULA禁止这样做,如果你发现了,你可以起诉他们,但是你无法阻止他们.
而且,用户可以根据需要禁用整个安全系统,在这种情况下,任何东西都可以运行.
您应该考虑是否要将DLL发送给客户.如果它包含您不想离开的秘密,那么不要与成千上万的客户分享这些秘密,其中一些客户可能对您不利.如果您将DLL保存在自己的服务器上并通过Web提供服务,那么您不会将DLL发送给客户,因此他们无法在自己的计算机上将其用于除您的意图之外的目的.
| 归档时间： |
|
| 查看次数： |
8219 次 |
| 最近记录： |