保护你的代码——谁动了我的组件？
来源：中国IT实验室
作为一名.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可以使你的代码被保护起来，不致被第三方不正确调用；但是过多的安全保护也将造成代码运行效率下降，从而带来负面影响。
作为一名.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可以使你的代码被保护起来，不致被第三方不正确调用；但是过多的安全保护也将造成代码运行效率下降，从而带来负面影响。
