提高權限

發行項
09/12/2008

「提高權限」(Elevation Of Privilege) 肇因於賦予攻擊者的授權權限高於原先賦予的層級。例如，具有「唯讀」權限的攻擊者以不明方式將權限提高為「讀取和寫入」。

受信任的 STS 應該簽署 SAML 權杖宣告

安全性判斷提示標記語言 (SAML) 權杖是一種泛型 XML 權杖，同時也是預設的發行權杖類型。在典型的交換中，結尾 Web 服務所信任的安全性權杖服務 (STS) 可以建構 SAML 權杖。SAML 權杖會在陳述式中包含宣告。攻擊者可從有效權杖中複製宣告、建立新的 SAML 權杖，然後使用不同的發行者進行簽署。其目的就是判斷伺服器是否正在驗證發行者，如果不是的話，會運用弱點來建構 SAML 權杖，針對受信任 STS 原先要賦予的權限賦予更多的權限。

SamlAssertion 類別會驗證 SAML 權杖中包含的數位簽章，而預設的 SamlSecurityTokenAuthenticator 則要求當 IssuedTokenServiceCredential 類別的 CertificateValidationMode 設為 ChainTrust 時，必須使用有效的 X.509 憑證來簽署 SAML 權杖。單是 ChainTrust 模式還不足以判斷 SAML 權杖的發行者是否受信任。需要更細微信任模型的服務可以使用授權與強制執行原則來檢查由已發行權杖驗證所產生的宣告集之發行者，或是使用 IssuedTokenServiceCredential 上的 X.509 驗證設定來限制允許的簽署憑證集。如需詳細資訊，請參閱使用身分識別模型來管理宣告與授權和聯合與發行的權杖。

切換不含安全性內容的身分識別

下列僅適用於 .NET Framework 3.0。

當用戶端與伺服器之間建立連線後，除了以下情況以外，用戶端身分識別不會變更：在開啟了 WCF 用戶端之後，如果下列所有條件都成立：

用來建立安全性內容的程序 (使用傳輸安全性工作階段或訊息安全性工作階段) 已關閉 (例如，在傳輸安全性情況中，使用無法建立安全性工作階段的訊息安全性或傳輸時，將 EstablishSecurityContext 屬性設為 false。HTTPS 即是此類傳輸的範例之一)。
您目前使用 Windows 驗證。
您未明確設定認證。
您在模擬的安全性內容中呼叫服務。

如果這些條件都成立，則用來向服務驗證用戶端的身分識別可能會在開啟 WCF 用戶端之後改變 (可能不是模擬的身分識別，而是處理序識別)。這是因為用來向服務驗證用戶端的 Windows 認證會隨著每個訊息一併傳輸，而用來驗證的認證則是從目前執行緒的 Windows 識別取得。如果目前執行緒的 Windows 識別變更 (例如，藉由模擬不同的呼叫者)，則附加至訊息並用來向服務驗證用戶端的認證可能會一併變更。

如果您希望在合併使用 Windows 驗證與模擬機制時擁有決定性行為，則您需要明確地設定 Windows 認證，或是需要建立服務的安全性內容。若要這麼做，請使用訊息安全性工作階段或傳輸安全性工作階段。例如，net.tcp 傳輸可以提供傳輸安全性工作階段。此外，在呼叫服務時，只能使用同步版本的用戶端作業。如果您建立訊息安全性內容，那麼與服務保持連線的時間不應該比設定的工作階段更新期間還長，因為身分識別也會在工作階段更新處理期間變更。

認證擷取

下列各項適用於 .NET Framework version 3.5和後續版本。

用戶端或服務所使用的認證，係依據目前的內容執行緒而定。認證會在呼叫用戶端或服務的 Open 方法時取得，如果是非同步呼叫 (Asynchronous Call)，則是在呼叫 BeginOpen 方法時取得。對於 ServiceHost 和 ClientBase 類別而言，Open 和 BeginOpen 方法是繼承自 CommunicationObject 類別的 Open 和 BeginOpen 方法。

注意：
使用 BeginOpen 方法時，所擷取的認證無法保證一定是呼叫該方法的處理序認證。

權杖快取允許重新執行使用已過時資料

WCF 會使用本機安全性授權 (LSA) LogonUser 函式，以使用者名稱和密碼來驗證使用者。由於登入函式是很耗時的作業，WCF 可讓您快取用來代表已驗證使用者的權杖來提升效能。快取機制可儲存 LogonUser 的結果以供後續使用。這項機制預設是停用的；若要加以啟用，請將 CacheLogonTokens 屬性設為 true，或是使用 userNameAuthentication element的 cacheLogonTokens 屬性。

您可以將 CachedLogonTokenLifetime 屬性 (Property) 設為 TimeSpan，或是使用 userNameAuthentication 項目的 cachedLogonTokenLifetime 屬性 (Attribute) 為快取權杖設定存留時間 (TTL)；預設時間為 15 分鐘。請注意，一旦快取了權杖，任何使用相同使用者名稱與密碼的用戶端都可以使用該權杖，就算使用者帳戶已從 Windows 中刪除，或當其密碼已經變更也是一樣。除非 TTL 到期，並從快取中移除了權杖，否則 WCF 會持續允許 (可能會是惡意的) 使用者進行驗證。

若要緩解這個情況：請將 cachedLogonTokenLifetime 值設為使用者所需的最短時間範圍來減少可能遭受攻擊的時間範圍。

發行的權杖授權：到期日重設為較大值

在特定情況下，AuthorizationContext 的 ExpirationTime 屬性可以設為超出預期的較大值 (MaxValue 欄位值減掉一天，或是 9999 年 12 月 20 日)。

當您使用 WSFederationHttpBinding 以及任何將已發行權杖當成用戶端認證類型來使用的系統提供繫結時，就會發生這種情況。

當您使用下列其中一種方法來建立自訂繫結時，也會發生這種情況：

若要緩解這個情況，授權原則必須檢查每個授權原則的動作與到期時間。

服務使用的憑證不同於用戶端原先想要的憑證

在特定情況下，用戶端可以使用 X.509 憑證來數位簽署訊息，並讓服務擷取與原先不同的憑證。

在下列狀況下可能會發生這種情形：

用戶端使用 X.509 憑證來數位簽署訊息，而且未將 X.509 憑證附加至訊息，只有使用其主體金鑰識別碼來參照憑證。
服務的電腦包含兩個以上的憑證具有相同的公開金鑰，但是憑證中包含不同的資訊。
服務擷取的憑證符合主體主鑰識別碼，但不是用戶端原先想要使用的那組憑證。當 WCF 收到訊息並驗證簽章之後，WCF 會將非預期的 X.509 憑證中資訊對應至可能是從用戶端預期的權限提升的不同宣告集。

若要緩解這個情況，請以另一種方式來參照 X.509 憑證，例如使用 IssuerSerial。

共用方式為