Silverlight開發(fā)工具功能強大，在開發(fā)使用中可以靈活的運用在各個領域中去幫助我們實現(xiàn)基于多媒體的各種用途。那么有沒有人對其的安全性能做過評估呢？在這里我們就為大家詳細介紹一下Silverlight代碼安全性的相關概念。#t#

在Silverlight發(fā)布時，微軟宣稱它將是一個完全跨平臺、跨瀏覽器的下一代富客戶端開發(fā)技術工具。但在使用絢麗功能的同時，很多人會思考Silverlight是否能夠一如既往地實現(xiàn)不同平臺間托管代碼執(zhí)行的安全性?答案是“除了安全，您沒有別的選擇”。

.NET Framework提供了一個新的安全方式——代碼訪問安全(CAS：Code Access Security)，通過Stack Walk檢查、Permission(/set)和Security Policy等一些措施我們可以保證不僅只有某些角色的人可以訪問某些功能(也就是常說的RBS：Role Based Security)，就連哪些代碼可以訪問何種資源也可以有效管理。

Silverlight推出后很多人更多關心的是它絢麗的UI效果和通過一個小小的CoreCLR就可以在多個平臺運行的能力，但當我們嘗試套用以往CAS的辦法定義訪問安全性的時候卻發(fā)現(xiàn)無從下手，原因在于SL采用了所謂的“透明安全模型”(transparency model)，它將代碼分成兩種：transparent Code和critical Code。前者是SL開發(fā)人員編寫的應用代碼，在用戶態(tài)執(zhí)行，執(zhí)行主體是當前這個用戶，而執(zhí)行的訪問控制設置為不受限;后者是CoreCLR在核心態(tài)執(zhí)行的，它需要和具體的操作系統(tǒng)交互，完成例如文件訪問、顯卡調(diào)用等工作。在CoreCLR中兩個代碼可能保存在同一個Assembly中，但一個方法內(nèi)部只能有唯一一類代碼，而且transparent Code不能直接訪問critical Code。

因此，在Silverlight代碼安全性開發(fā)中，我們能編寫的代碼只能是滿足下述transparent Code要求的內(nèi)容：

隱式滿足LinkDemand，即整個調(diào)用棧的所有代碼都必須是transparent Code;

不需執(zhí)行CAS的斷言(Assert);

全部代碼都是可驗證的;

不可以通過Native Call或P/Invoke調(diào)用本地資源，一方面為了安全，另一方面因為不同平臺的本地調(diào)用方式不同;

不可以直接訪問critical code。

這樣您可能覺得Silverlight代碼安全性的開發(fā)限制很大，比如建立一個文件這種操作在應用中非常普遍，為了實現(xiàn)這個目的，CoreCLR提供了一個中間過渡——IsolatedStorage。某種意義上講，它是SL開發(fā)人員所能看到的邏輯運行平臺，無論是文件、設備還是進程之類的信息都只能通過這個中間機制訪問，而嚴格的檢查也會“透明”的在這個中間機制完成。這么做有什么益處呢?很多。因為這一層把很多Best Practice強制實施了，例如：

打開一個文件的時候，文件名稱是否有效，是否存在潛在的緩沖區(qū)溢出等危險，當前用戶是否可以執(zhí)行這個文件打開操作等;

訪問一個URL的時候，這個URL是否會Traverse up，是否可以遍歷到高層目錄。

總體上通過IsolatedStorage，把很多已知的代碼安全訪問檢查全部在CoreCLR平臺一級內(nèi)置了，開發(fā)人員可以通過這種“與生俱來”的安全性相對放心地開發(fā)自己的上層應用。

(CAS：Code Access Security)，通過Stack Walk檢查、Permission(/set)和Security Policy等一些措施我們可以保證不僅只有某些角色的人可以訪問某些功能(也就是常說的RBS：Role Based Security)，就連哪些代碼可以訪問何種資源也可以有效管理。由此可以看出Silverlight代碼安全性的重要性。