当前位置: 首页 > 图文教程 > 网络编程 > ASP.NET > 保护你的.Net代码:谁动了我的组件?

ASP.NET
赫赫大名的A*寻路算法(vb.net版本)
asp.net(c#)下Jmai去说明 使用与下载
[原创]完美解决Could not load file or assembly ''AjaxPro.2'' or one of its dependencies. 拒绝访问。
asp.net下gridview 批量删除的实现方法
用CSS实现图片倾斜 只支持IE
.net get set用法小结
vs 不显示行号的操作方法
ASP.NET页面进行GZIP压缩优化的几款压缩模块的使用简介及应用测试!(附源码)
ASP.Net不执行问题一解
asp.net 无限分类
让VS2008对JQuery语法的智能感知更完美一点
扩展方法ToJSON() and ParseJSON()
asp.net下PageMethods使用技巧
Linq to SQL Delete时遇到问题的解决方法
实现ASP.NET多文件上传程序代码
ASP.NET AJAX 1.0 RC开发10分钟图解
asp.net get set用法
ASP.NET下使用WScript.Shell执行命令
asp.net2.0实现邮件发送(测试成功)
Asp.net 无限级分类实例代码

ASP.NET 中的 保护你的.Net代码:谁动了我的组件?


出处:互联网   整理: 软晨网(RuanChen.com)   发布: 2009-09-28   浏览: 164 ::
收藏到网摘: n/a

  作为一名.NET开发人员,你没日没夜地写代码,你的组件运行在越来越多的机器上。忽然有一天,你发现你写的组件被引用在别人写的项目里,而且最可气的是,那人竟用你的名义在做破坏它人系统的恶事!你忍不住了,大叫一声Oh shit!,然后打开MSDN,看看有什么办法能帮助你阻止这场阴谋。

  OK,办法找到了,那就是.NET平台提供的Code Access Security有大量继承于CodeAccessPermission的类可以帮你实现不同方面、不同范围的代码安全控制。你所需要做的只是从中挑出最适合的类别加以应用,从而达到保护你的组件的目的。

  在经过一番挑选之后,你最终确定了使用StrongNameIdentityPermissionAttribute类。这个类允许你将组件(或类、方法)与某一强名称(通常就是你发布程序时所用的强名称)绑定,这样,只有在客户端程序具有该强名称签名的情况下才能使用你的组件。也就是说,除了你自己编写的客户端代码因为拥有同样的签名而被允许使用组件以外,任何第三方代码都无法通过StrongNameIdentityPermissionAttribute的防护,因此也就无法恶意调用你的组件了:)。听起来真的不错,马上就动手做吧!

  为了简便起见,先创建一个很简单的Class Library项目,代码如下:

以下为引用的内容:
  // SecureComp.dll
  using System;
  namespace musicland
  {
  public class SecureComp
  {
  public string Confidential()
  {
  return "This is confidential!";
  }
  }
  }

  现在的这个组件非常可怜,因为任何人都可以写代码来调用它。下面,你就要耍点手段了:):

  首先引入System.Security.Permissions命名空间:

以下为引用的内容:
  using System.Security.Permissions;

  然后,在组件级加上StrongNameIdentityPermissionAttribute属性:

以下为引用的内容:
  [assembly: StrongNameIdentityPermissionAttribute(SecurityAction.RequestMinimum,  PublicKey="0024000004800000940000000602000000240000525341310004000001000100c11c8497d“+  “283259f23d645358d65812b69136846b03a7d15124545fc3ed27d89d1330cceda4232c7bc6e8a0e7ecd857f8”+  “126d0859e2300237b3cab6f7737a92f585cbf2afb4b475c537703efb96e17e5921ff00c6e022b22f3d772f14”+  “6a3a5c7f6ccad3131b8d0465e6709e5a28cc3ca1c8b610af4162c1a18c0feb8e6993ab1")]
  namespace musicland
  …

  注意,这里使用了SecurityAction.RequestMinimum,这申明除非获得StrongNameIdentityPermissionAttribute所表明的资源访问权限(即对SecureComp.dll组件的访问权限,可以把SecureComp.dll看作一样资源),否则CLR不会准许调用方(即客户端代码)访问所请求的资源;此外,在PublicKey属性中加入了你所允许的公匙(Public Key)的十六进制表示(转化成字符串类型)。CRL在运行期间将依照这一段公匙来判断调用方是否合法,除非调用方拥有相应的私匙(Private Key),否则将无法访问。看来,平时一定要倍加保护你的密钥文件,因为密钥文件(特别是private key)的泄露将会成为你无尽恶梦的根源,而延迟签名(delay signing)在这里也就显得格外重要了:)

  说到这里,你一定会有个大大的问号:这长长的一串PublicKey是怎么得出来的?难道要我凭空凑出来不成?当然不是。还记得那个Sn.exe工具吗?通过它就可以把PublicKey给提取出来。OK,打开你的命令行,定位到密钥文件所在目录并输入以下内容:

以下为引用的内容:
  sn –p Key.snk PublicKey.snk

  这样,提取出来的公匙信息就被存储在PublicKey.snk文件中。你现在只需把公匙信息读取出来并转化成适当的格式就可以了。这里,你可以使用。NET Framework自带的Secutil.exe工具,但据我所了解,Secutil工具的输出都是数组格式(我在自己的机器上测试了Secutil所提供的全部输出选项,但所得结果都是一样,这让我很感意外,不知大家是否有更好的办法),因此就动手自己写了一个小工具来完成这一读取和转换。大家如果感兴趣可以发邮件给我(因为我没有自己的网络空间可以存放。当然你也可以自己来写,因为它实在是太简单了,就是读取二进制文件)。

  好了,现在你的代码就被全副武装起来了。试着写一个Console客户端来调用SecureComp,结果怎么样?是不是“无法获得相应权限”?试着用Key.snk给客户端程序签名后再访问,这回可以访问了吧!:)

  结论:适当地应用Code Access Security可以使你的代码被保护起来,不致被第三方不正确调用;但是过多的安全保护也将造成代码运行效率下降,从而带来负面影响。