Silverlight 开发中的代码安全性

在 Silverlight 发布时，微软宣称它将是一个完全跨平台、跨浏览器的下一代富客户端开发技术工具。但在使用绚丽功能的同时，很多人会思考 Silverlight 是否能够一如既往地实现不同平台间托管代码执行的安全性？答案是“除了安全，您没有别的选择”。

.NET Framework 提供了一个新的安全方式——代码访问安全（CAS：Code Access Security），通过 Stack Walk 检查、Permission(/set) 和 Security Policy 等一些措施我们可以保证不仅只有某些角色的人可以访问某些功能（也就是常说的 RBS：Role Based Security），就连哪些代码可以访问何种资源也可以有效管理。

Silverlight 推出后很多人更多关心的是它绚丽的 UI 效果和通过一个小小的 CoreCLR 就可以在多个平台运行的能力，但当我们尝试套用以往 CAS 的办法定义访问安全性的时候却发现无从下手，原因在于 SL 采用了所谓的“透明安全模型”（transparency model），它将代码分成两种：transparent Code 和 critical Code。前者是 SL 开发人员编写的应用代码，在用户态执行，执行主体是当前这个用户，而执行的访问控制设置为不受限；后者是 CoreCLR 在核心态执行的，它需要和具体的操作系统交互，完成例如文件访问、显卡调用等工作。在 CoreCLR 中两个代码可能保存在同一个 Assembly 中，但一个方法内部只能有唯一一类代码，而且 transparent Code 不能直接访问 critical Code。

因此，在 SL 开发中，我们能编写的代码只能是满足下述 transparent Code 要求的内容：

• 隐式满足 LinkDemand，即整个调用栈的所有代码都必须是 transparent Code；
• 不需执行 CAS 的断言（Assert）；
• 全部代码都是可验证的；
• 不可以通过 Native Call 或 P/Invoke 调用本地资源，一方面为了安全，另一方面因为不同平台的本地调用方式不同；
• 不可以直接访问 critical code。

这样您可能觉得 SL 开发限制很大，比如建立一个文件这种操作在应用中非常普遍，为了实现这个目的，CoreCLR 提供了一个中间过渡——IsolatedStorage。某种意义上讲，它是 SL 开发人员所能看到的逻辑运行平台，无论是文件、设备还是进程之类的信息都只能通过这个中间机制访问，而严格的检查也会“透明”的在这个中间机制完成。这么做有什么益处呢？很多。因为这一层把很多 Best Practice 强制实施了，例如：

• 打开一个文件的时候，文件名称是否有效，是否存在潜在的缓冲区溢出等危险，当前用户是否可以执行这个文件打开操作等；
• 访问一个 URL 的时候，这个 URL 是否会 Traverse up，是否可以遍历到高层目录。

总体上通过 IsolatedStorage，把很多已知的代码安全访问检查全部在 CoreCLR 平台一级内置了，开发人员可以通过这种“与生俱来”的安全性相对放心地开发自己的上层应用。