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

在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。

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

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

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

全部代碼都是可驗證的;

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

不可以直接訪問critical code。

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

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

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

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

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