因為在本機代碼中提供代碼路徑的任何托管代碼都是惡意代碼的潛在目標，因此確定可以安全地使用什么非托管代碼以及必須如何使用它就需要非常小心。通常，所有非托管代碼都不應當直接公開給部分信任的調用方（請參閱下一部分）。在對可由部分信任代碼調用的庫中的非托管代碼使用情況的安全性進行評估時，有兩個主要注意事項：
•功能。非托管 API 是否提供了安全的功能，即，不允許通過調用它來執行潛在危險的操作？代碼訪問安全性使用權限來實施對資源的訪問，所以請考慮 API 是否使用文件、用戶界面、線程，或者是否公開受保護的信息。如果是這樣，則包裝它的托管代碼必須請求所需的權限，然后才允許輸入它。此外，雖然不受權限保護，但安全性要求將內存訪問限制在嚴格的類型安全范圍內。
•參數檢查。常見攻擊在試圖使被公開的非托管代碼 API 方法進行脫離規范的操作時，會將意外的參數傳遞給它們。緩沖溢出是此類攻擊的一個常見示例（使用范圍外的索引或偏移量值），另一個示例是可能利用基礎代碼中的錯誤的任何參數。因此，即使非托管代碼 API 在功能上對于部分受信任的調用方是安全的（在必要的請求之后），但托管代碼仍必須徹底地檢查參數的有效性，以使用托管代碼包裝程序層來確保惡意代碼不會發出非預期的調用。
使用 SuppressUnmanagedCodeSecurity斷言然后調用非托管代碼有性能方面因素。對每個這樣的調用來說，安全系統會自動請求非托管代碼權限，這會導致每次都進行堆棧審核。如果您斷言并直接調用非托管代碼，則堆棧審核沒有任何意義：它由斷言和非托管代碼調用組成。
可以將一個名為 SuppressUnmanagedCodeSecurity 的自定義屬性應用于非托管代碼入口點，以禁用請求 SecurityPermission.UnmanagedCode 的正常安全檢查。這樣做時必須始終保持謹慎，這是因為該操作會為在沒有運行時安全檢查的情況下進入非托管代碼創建一扇打開的門。應當注意到，即使應用了 SuppressUnmanagedCodeSecurity，在 JIT 時也會發生一次性安全檢查，以確保直接調用方擁有調用非托管代碼的權限。
如果您使用 SuppressUnmanagedCodeSecurity 屬性，請檢查以下幾點：
•使非托管代碼入口點在代碼外部不可訪問（例如，“internal”）。
•調用非托管代碼的任何位置都是潛在的安全漏洞。確保您的代碼不是惡意代碼間接調用非托管代碼并避開安全檢查的門戶。在適當的情況下請求權限。
•在創建到非托管代碼的危險路徑時，使用命名約定使它成為顯式的，下一部分將對此進行描述。
非托管代碼方法的命名約定人們已經為命名非托管代碼方法建立了有用和高度推薦的約定。所有非托管代碼方法都可以劃分到三個類別中：safe、native 和 unsafe。這些關鍵字可用作在其中定義各種非托管代碼入口點的類名稱。在源代碼中，這些關鍵字應添加到類名稱中；例如，Safe.GetTimeOfDay、Native.Xyz 或 Unsafe.DangerousAPI。這些類別中的每一個都應向使用它們的開發人員發送強消息，如下表所述。
關鍵字安全注意事項
文章來源于領測軟件測試網 http://www.kjueaiud.com/
