安全性警告
支援更安全之程式庫和應用程式的安全性警告。 這些警告有助於防止在程式中出現安全性問題。 如果停用這些警告中的任一個,則您應該清楚地在程式碼中標示理由,同時也要通知指定的安全主管有關您的開發專案。
在本節中
規則 |
說明 |
---|---|
方法會使用透過字串引數所建置的字串,將 System.Data.IDbCommand.CommandText 屬性設定為方法。 這項規則假設字串引數包含使用者輸入。 從使用者輸入所建置的 SQL 命令字串很容易遭到 SQL 插入 (SQL Injection) 攻擊。 |
|
組件中不是以 RuntimeCompatibilityAttribute 標記或是以 RuntimeCompatibility(WrapNonExceptionThrows = false) 標記的成員包含處理 System.Exception 的 catch 區塊,同時不包含緊接其後的一般 catch 區塊。 |
|
方法會使用命令式安全性,而且可能會利用因要求正在使用中而可能變更的狀態資訊或傳回值建構使用權限。 請盡可能使用宣告式安全性。 |
|
外部可見型別包含了可變動參考型別的外部可見唯讀欄位。 可變動型別是可以修改執行個體 (Instance) 資料的型別。 |
|
當您將唯讀 (在 Visual Basic 中為 ReadOnly) 修飾詞套用至包含陣列的欄位時,欄位就不能變更為參考不同的陣列。 但是,儲存在唯讀欄位的陣列元素則可以變更。 |
|
方法會判斷提示使用權限,而且不會在呼叫端上執行安全性檢查。 判斷提示安全性權限但未執行任何安全性檢查,會在您的程式碼中留下可能遭利用的安全性弱點。 |
|
只有相當了解 .NET Framework 安全性的人員才能執行 PermitOnly 方法和 CodeAccessPermission.Deny 安全性動作。 而使用這些安全性動作的程式碼應該接受安全性檢閱。 |
|
公用或受保護的實值型別受到資料存取或連結要求保護。 |
|
偵測到公用或保護的事件處理方法。 除非有絕對的必要性,否則不應該公開 (Expose) 事件處理方法。 |
|
指標不為私用、內部或唯讀。 惡意的程式碼可變更指標值,進而可能會允許存取記憶體中的任意位置,或是造成應用程式或系統失敗。 |
|
公用或受保護的型別包含公用欄位,而且受到連結要求保護。 如果程式碼可存取受連結要求保護的型別執行個體,則程式碼不必滿足連結要求即可存取型別的欄位。 |
|
方法不應該同時具有相同動作的方法層級和型別層級宣告式安全性。 |
|
此規則所偵測的錯誤,可能是因為在 Unmanaged 程式碼仍在使用 Unmanaged 資源時,就完成 Unmanaged 資源所致。 |
|
當完全信任的組件中出現 APTCA (AllowPartiallyTrustedCallers) 屬性,並且組件在不允許部分信任呼叫端的另一個組件中執行程式碼時,可能會發生安全性弱點攻擊。 |
|
當完全信任的組件中出現 APTCA (AllowPartiallyTrustedCallers) 屬性,並且組件中的型別會繼承自不允許部分信任之呼叫端的型別時,就可能會發生安全性弱點攻擊。 |
|
對於執行使用 COM Interop 或平台引動過程之 Unmanaged 程式碼的成員,SuppressUnmanagedCodeSecurityAttribute 會變更安全性系統的預設行為。 這個屬性主要是用於增加效能,不過,效能提升會伴隨顯著的安全性風險。 |
|
可繼承的公用型別會提供內部 (在 Visual Basic 中為 Friend) 介面的可覆寫方法實作。 若要修正此規則的違規情形,請避免在組件外覆寫方法。 |
|
這個型別有接受 System.Runtime.Serialization.SerializationInfo 物件和 System.Runtime.Serialization.StreamingContext 物件 (序列化建構函式的簽章) 的建構函式。 這個建構函式未受到安全性檢查的保護,但型別中有一個或多個規則建構函式是受到保護的。 |
|
系統會在建立型別的第一個執行個體 (Instance) 或參考任何靜態成員之前呼叫靜態建構函式。 如果靜態建構函式不是私用的,則可由系統以外的程式碼呼叫。 視建構函式中執行的作業而定,這會造成非預期的行為。 |
|
公用或受保護的成員具有連結要求,而且是由未執行任何安全性檢查的成員所呼叫。 連結要求只會檢查立即呼叫端的使用權限。 |
|
這項規則會使方法符合它的基底方法,即另一個型別中的介面或虛擬方法,然後比較每個方法上的連結要求。 如果違反這項規則,則惡意呼叫端只需呼叫不安全的方法,就可以略過連結要求。 |
|
公用或受保護的方法包含 try/finally 區塊。 finally 區塊似乎會重設安全性狀態,而且不會封入 finally 區塊中。 |
|
公用 unsealed 型別受到連結要求保護,並且具有可以覆寫的方法。 此型別或方法都不是以繼承要求保護的。 |
|
關鍵程式碼不能出現在 100% 透明的組件中。 這項規則會分析 100% 透明組件中型別、欄位和方法層級的任何 SecurityCritical 附註。 |
|
此規則會分析完全透明或混合透明/關鍵之組件中的所有方法和型別,並將 Assert 的任何宣告式或必要用法加上旗標。 |
|
以 SecurityTransparentAttribute 標記的方法可呼叫標記為 SecurityCritical 的非公用成員。 此規則會分析混合透明/關鍵之組件中的所有方法和型別,而且如果從透明程式碼對非公用關鍵程式碼所做的任何呼叫未標記 SecurityTreatAsSafe,也會將這些呼叫加上旗標。 |
因為編譯器內嵌常數的值,所以沒有針對常數值強制透明度,因此在執行階段不需要查詢。 常數欄位應該具備安全性透明,程式碼檢閱者才不會假設透明程式碼無法存取常數。 |
|
---|---|
型別會參與使用 SecurityCriticalAttribute 屬性來標記的型別等價或型別本身,或是型別的成員或欄位。 此規則會引發任何關鍵的型別或包含參與型別等價之關鍵方法或欄位的型別。 當 CLR 偵測到這種型別時,它便無法載入此型別,而且會在執行階段發生 TypeLoadException。 通常,只有在使用者手動實作型別等價,而不是依賴 tlbimp 和編譯器進行型別等價時,就會引發這項規則。 |
|
Silverlight 應用程式的程式碼不能使用內含 SecurityCriticalAttribute 的型別和成員。 重視安全性的型別以及成員,只能夠由 .NET Framework for Silverlight 類別庫中的受信任程式碼使用。 由於衍生類別中的公用或受保護建構所具有的透明度必須大於或等於其基底類別,因此應用程式中的類別不可衍生自標記為 SecurityCritical 的類別。 |
|
當方法會將使用 SecurityCriticalAttribute 標記的委派繫結到透明方法,或繫結到使用 SecuritySafeCriticalAttribute 標記的方法時,就會針對此方法引發警告。 此警告也會引發將透明或安全關鍵性的委派繫結至關鍵方法的方法。 |
|
當使用 SecurityCriticalAttribute 標記的方法覆寫透明方法,或覆寫使用 SecuritySafeCriticalAttribute 標記的方法時,就會引發此規則。 當透明或使用 SecuritySafeCriticalAttribute 標記的方法覆寫使用 SecurityCriticalAttribute 標記的方法時,也會引發此規則。 覆寫虛擬方法或實作介面時會套用此規則。 |
|
LinkDemand 在層級 2 安全性規則集中已被取代。 不使用 LinkDemand 在 Just-In-Time (JIT) 編譯時期強制執行安全性,改為使用 SecurityCriticalAttribute 屬性來標記方法、型別和欄位。 |
|
透明度屬性會從較大範圍的程式碼項目套用至較小範圍的項目。 範圍較大之程式碼項目的透明度屬性優先於第一個項目中所包含之程式碼項目的透明度屬性。 例如,使用 SecurityCriticalAttribute 屬性來標記的類別不得包含使用 SecuritySafeCriticalAttribute 屬性來標記的方法。 |
|
方法包含無法驗證的程式碼,或以傳址方式傳回型別。 當安全性透明程式碼嘗試執行無法驗證的 MSIL (Microsoft Intermediate Language) 時,就會引發此規則。 不過,此規則不包含完整的 IL 驗證器,並是使用啟發式來擷取多數的 MSIL 驗證違規情形。 |
|
安全性透明方法會呼叫使用 SuppressUnmanagedCodeSecurityAttribute 屬性標記的方法。 |
|
此規則會引發任何透明並且嘗試使用 HandleProcessCorruptedStateExceptionsAttribute 屬性來處理處理序損毀例外狀況的方法。 處理序損毀例外狀況是 AccessViolationException 這類例外狀況的 CLR 4.0 版例外狀況分類。 HandleProcessCorruptedStateExceptionsAttribute 屬性只能供安全性關鍵方法使用,若套用至透明方法則會被忽略。 |
|
使用 SecurityCriticalAttribute 屬性來標記的程式碼項目就是安全性關鍵。 透明方法不能使用安全性關鍵項目。 如果透明型別嘗試使用安全性關鍵型別,就會引發 TypeAccessException、MethodAccessException 或 FieldAccessException。 |
|
安全性透明方法會呼叫未使用 AllowPartiallyTrustedCallersAttribute (APTCA) 屬性標記之組件中的方法,或是安全性透明方法會滿足型別或方法的 LinkDemand。 |
|
需要 LinkDemand 才能存取的透明方法會引發這個規則。 安全性透明程式碼不應負責驗證作業的安全性,因此不應要求權限。 |
|
安全性透明程式碼不應負責驗證作業的安全性,因此不應要求權限。 安全性透明程式碼應使用完整的要求做出安全性決策,而且安全關鍵程式碼不應依賴透明程式碼提出完全要求。 |
|
透明程式碼的安全性檢閱不如關鍵性程式碼的安全性檢閱徹底,因為透明程式碼無法執行安全性敏感動作。 透明程式碼中可能不會注意到從位元組陣列載入的組件,而該位元組陣列可能包含需要稽核之重大或更重要的安全關鍵性程式碼。 |
|
以 SuppressUnmanagedCodeSecurityAttribute 屬性裝飾的方法會在任何方法呼叫它時放置隱含的 LinkDemand。 這個 LinkDemand 會要求呼叫程式碼具備安全性關鍵。 使用 SecurityCriticalAttribute 屬性來標記使用 SuppressUnmanagedCodeSecurity 的方法會使方法呼叫端的這個需求更為明顯。 |
|
當衍生型別有安全性透明屬性,且該屬性的重要性不如基底型別或已實作之介面時,就會引發這個規則。 只有關鍵型別可以衍生自關鍵基底型別或實作關鍵介面,而且只有關鍵或安全關鍵型別可以衍生自安全關鍵基底型別或實作安全關鍵介面。 |
|
標記為 SecurityTransparentAttribute 的程式碼並未具備足夠的使用權限可以進行判斷提示 (Assert)。 |
|
任何直接呼叫機器碼的透明方法都會引發此規則,例如透過 P/Invoke。 違反此規則會導致層級 2 透明度模型出現 MethodAccessException,而在層級 1 透明度模型會出現對 UnmanagedCode 的完整要求。 |