Silverlight開發中的程式碼安全性

在Silverlight釋出時，微軟宣稱它將是一個完全跨平臺、跨瀏覽器的下一代富客戶端開發技術工具。但在使用絢麗功能的同時，很多人會思考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平臺一級內建了，開發人員可以通過這種“與生俱來”的安全性相對放心地開發自己的上層應用。

(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平臺一級內建了，開發人員可以通過這種“與生俱來”的安全性相對放心地開發自己的上層應用。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12639172/viewspace-594738/，如需轉載，請註明出處，否則將追究法律責任。