Effective C# 原則47：選擇安全的代碼(譯)

Effective C# 原則47：選擇安全的代碼
Item 47: Prefer Safe Code

.Net運行時已經設計好了，一些懷有惡意的代碼不能滲透到遠端電腦上並執行。目前一些分部式系統依懶於從遠程機器上下載和執行代碼。如果你可以通過Internet或者乙太網路來發布你的軟體，或者直接從web上運行，但你須要明白CRL在你的程式集中的一些限制。如果CLR不是完全相信一個程式集，它會限制一些的行為。這些調用代碼要有訪問安全認證(CAS)。從另一方面來說，CLR強制要求基於角色的安全認證，這樣這些代碼才能或者不能在基於一個特殊的角色帳號下運行。

安全違例是運行時條件，編譯器不能強制它們。幸運的是，它們絕不會在你的開發機器上出現，而且你所編譯的代碼從你自己的硬體上載入，這就是說，它有更高的信任層級。討論所有潛在的.Net安全模型可以足足寫上幾本書，但你可以瞭解合理行為的一小部份，這樣可以讓你的程式集與.Net的安全模式更容易的互動。這些推薦只有在你建立一個組件程式庫時，或者是開發一些通過網路發布的組件和程式集是才可以參考應用。

通過這個討論，你應該記住.Net是一個託管的環境。這個環境保證有一個明確的安全環境。在安裝時可以用.Net的配置策略來管理安全性原則。大多數.Net架構庫是在安裝時對配置策略是安全信任的。它會查明安全問題，這就是說CLR可以檢測IL而且確保它不會有什麼潛在的危險行為，例如直接存取原始記憶體。它不會在訪問本地資源時要求特殊的安全許可權進行斷言。你應該試著遵守同樣的檢測，如果你的代碼不須要任何的安全許可權，就應該避免使用CAS的API來對斷定存取權限，否則你所做的只是降低程式效能。

你要使用CAS的API來訪問一些受保護的資源，而這些資源是要求增加的特權的。很多通用的受保護資源是非託管的記憶體和檔案系統。其它一些受保護的資源還包括資料庫，網路連接埠，windows註冊表，以及列印子系統。在每種情況下，如果調用代碼沒有足夠的許可，試著訪問這些資源都會引發一個異常。而且，訪問這些資源可能引發運行時建立一個安全棧上的詢訪，以確保當前棧上的所有的程式集有恰當的許可。讓我們看一下記憶體以及檔案系統，討論安全系統和機密問題中最實際的一些問題。

不管什麼時候，你都可以通過建立恰當的安全程式集來避免非託管記憶體訪問。一個安全的程式集，也就是一個不用使用任何指標來訪問其它非託管，或者託管的堆記憶體。不管你是否知道，你所建立的所有C#代碼幾乎都是安全的。除非你在C#編譯器上開啟了不安全的編譯開關/unsafe，否則你所建立的都是安全的程式碼(譯註：就算開啟了開關也不是說就編譯成不安全的程式碼了，還要看你的代碼是怎樣寫的。)。/unsafe充許使用者使用CLR不進行的驗證的指標。

要使用不安全的程式碼的原因很少，特別是一常規的任務中。指向原始記憶體的指標比要檢測的安全的引用快一些。在一些經典的數組中，它們可能要快上10倍以上。但當你使用不安全結構時，要明白任何的不安全的程式碼都會影響整個程式集。當你建立不安全塊時，應該考慮把這些演算法獨立到一個程式信中(參見原則32)。這樣可以在整個程式上限制不安全的程式碼的影響。如果它是獨立的，只有實際調用它的訪問者才會受到影響。其它剩下的，你還是可以在更嚴格的環境中使用安全機制。你可能還須要不安全的程式碼來處理一些須要直接指標的P/Invoke或者COM介面。同樣的推薦：獨立它。不安全的程式碼只會影響它自己的小程式集，不再有其它的。

對於訪問的建議很簡單：只要可能，都應該避免訪問非託管記憶體。

接下來的安全核心就是檔案系統。程式要儲存資料。從Internet上下載回來的代碼，檔案系統中的大多數地方都不能訪問，否則會有很大的安全性漏洞。是的，完全不許訪問檔案系統就很難建立能使用的程式。通過使用隔離儲存區 (Isolated Storage)可以解決這一問題。隔離儲存區 (Isolated Storage)可以穿越基於程式集而獨立的虛擬目錄，以及應用程式定義域，以及當前的使用者。選擇性的，你可以使用更一般的隔離儲存區 (Isolated Storage)虛擬目錄，該目錄是基於程式集或者目前使用者的。

實際上，受信任的程式集可以訪問他們自己特殊的隔離儲存區 (Isolated Storage)地區，但不能是檔案系統的其它地方。獨立的儲存目錄是隱藏在其它程式集以及其它使用者中的。你可以使用System.IO.IsolatedStorage名字空間中的類來訪問獨立的儲存。IsolatedStorageFile類包含的方法可以很簡單的訪問System.IO.File類。實際上，它是從 System.IO. FileStream 類派生下來的。寫內容到隔離儲存區 (Isolated Storage)的代碼幾乎與寫內容到任何檔案裡是一樣的：

IsolatedStorageFile iso =
  IsolatedStorageFile.GetUserStoreForDomain( );

IsolatedStorageFileStream myStream = new
  IsolatedStorageFileStream( "SavedStuff.txt",
  FileMode.Create, iso );
StreamWriter wr = new StreamWriter( myStream );
// several wr.Write statements elided
wr.Close();

讀操作也是完全和其它使用檔案I/O相似的：

IsolatedStorageFile isoStore =
  IsolatedStorageFile.GetUserStoreForDomain( );

string[] files = isoStore.GetFileNames( "SavedStuff.txt" );
if ( files.Length > 0 )
{
  StreamReader reader = new StreamReader( new
    IsolatedStorageFileStream( "SavedStuff.txt",
    FileMode.Open,isoStore ) );

  // Several reader.ReadLines( ) calls elided.

  reader.Close();
}

你可以隔離儲存區 (Isolated Storage)來持久大小合適的資料元素，這些元素可以被代碼部分信任，用於從一個安全分離的本地磁碟上的某個地方儲存和載入資訊。.Net環境為每個程式定義和限制了隔離儲存區 (Isolated Storage)的大小。這可以預防一些惡意的代碼佔用磁碟空間，讓系統就得不可用。隔離儲存區 (Isolated Storage)對於其它程式和其它使用者來說是不可見的。也就是說，它不應用於要管理員手動操作才能布署或者配置設定的情況。即使這它是隱藏的，然而，隔離儲存區 (Isolated Storage)對於從受信任的使用者那來裡來的Unmanaged 程式碼來說也是不受保護的。不要用隔離儲存區 (Isolated Storage)來儲存一些高度機密的內容，除非你的程式給它加過密。

在檔案系統中建立一個可能要許可安全性原則的程式集時，要隔離儲存區 (Isolated Storage)流的內容。當你的程式集可能在web上運行，或者可能被運行在web上的代碼訪問時，應該考慮使用隔離儲存區 (Isolated Storage)。

你可能須要正確的使用一個受保護的資源。一般情況下，訪問這些資源要指出你的程式要被完全信任。唯一可選的就是完全避免使用這些受保護的資源。例如，考慮windows的註冊表，如果你和程式須要訪問註冊表，你必須安裝你的程式到終端使用者的機器上，這樣才能有必須的許可權來訪問註冊表。你想簡單點，從web上啟動並執行程式是不能建立註冊表的修改的。安全性原則就應該是這樣的。

.Net的安全模型意味著你的程式的行為是要權得進行核對的。注意你的程式所要求的權利，而且試著最小化它們。不必要求你不使用的權利。你的程式集越是少的要求受保護資源，那麼它們就越是可以保證安全性原則異常不拋出。避免使用機密資源，如果可能，要考慮其它可選方案。當你在某個演算法上確實須要更高安全的許可時，應該獨立這些代碼到它們自己的程式集中。
==================

    

Item 50: Learn About the ECMA Standard
The ECMA standard is the official word on how every feature in the C# language behaves. ECMA-334 defines the 1.0 standard for the C# language. You can learn about the C# 2.0 proposals from the book The C# Programming Language, by Anders Hejlsberg, Scott Wiltamuth, and Peter Golde (Addison-Wesley, 2003). This book is a language reference, not a tutorial. It explains in very pedantic detail exactly how each feature of the language works. Each language feature is annotated so that you can better understand the justification of each language feature. While I was working on this book, I constantly had this reference open on my desk.

If you are a serious C# programmer, you should understand the language, including the rationale behind different features. It will make your job easier if you know when to apply each feature in your own work. You will have a better understanding of any subtle differences in different language expressions.

In addition to the C# language, you should understand the Common Language Runtime (CLR) thoroughly. The CLR and Common Language Infrastructure (CLI) standards are defined in ECMA-335, the CLR standard. As with C#, this is version 1.0 of the standard. The Common Language Infrastructure Annotated Standard, by James Miller and Susann Ragsdale (Addison-Wesley, 2003), explains the CLI version 2.0. This reference includes the Common Language Subsystem (CLS), which will help you understand the rules behind CLS compliance. This also helps you understand the ECMA standard for the .NET runtime and infrastructure.

Both the C# and CLR committees continue to publish working documents on the discussion and progress of the 2.0 version of the C# language and the CLR. The discussions are a valuable way to understand how C# will grow and change over time.

In addition, a deeper understanding of the current standard and the proposed enhancements will help you create code that stands the test of time. By understanding the features that will be added to the language and the environment, you are in a better position to create software that lasts longer into the future. You can anticipate the future modifications that might be necessary.

Software changes over time. C# will grow and change, probably for some time and for several revisions after 2.0. This is a tool that you use every day, for most of your day. Learn the official definitions, and stay on top of them.