Zvýšení oprávnění

Článek
03/05/2024

Zvýšení oprávnění má za následek udělení oprávnění útočníkovi nad rámec těch, které byly původně uděleny. Například útočník s sadou oprávnění "jen pro čtení" nějak zvýší úroveň nastavenou tak, aby zahrnovala "čtení a zápis".

Důvěryhodné tokeny zabezpečení by měly podepisovat deklarace identity tokenů SAML.

Token SAML (Security Assertions Markup Language) je obecný token XML, který je výchozím typem vydaných tokenů. Token SAML může vytvořit služba tokenů zabezpečení (STS), kterou koncová webová služba důvěřuje v typické výměně. Tokeny SAML obsahují deklarace identity v příkazech. Útočník může zkopírovat deklarace identity z platného tokenu, vytvořit nový token SAML a podepsat ho jiným vystavitelem. Záměrem je určit, jestli server ověřuje vystavitele, a pokud ne, využijte slabinu k vytvoření tokenů SAML, které umožňují oprávnění nad rámec těch, které jsou určeny důvěryhodným tokenem zabezpečení.

SamlAssertion Třída ověřuje digitální podpis obsažený v tokenu SAML a výchozí SamlSecurityTokenAuthenticator vyžaduje, aby tokeny SAML byly podepsány certifikátem X.509, který je platný při CertificateValidationMode IssuedTokenServiceCredential nastavení ChainTrusttřídy . ChainTrust samotný režim není dostatečný k určení, jestli je vystavitel tokenu SAML důvěryhodný. Služby, které vyžadují podrobnější model důvěryhodnosti, můžou buď použít zásady autorizace a vynucení ke kontrole vystavitele sad deklarací vytvořených ověřováním vystaveného tokenu, nebo pomocí nastavení IssuedTokenServiceCredential ověřování X.509 omezit sadu povolených podpisových certifikátů. Další informace najdete v tématu Správa deklarací identit a autorizace pomocí modelu identit a federace a vydaných tokenů.

Přepnutí identity bez kontextu zabezpečení

Následující informace platí jenom pro WinFX.

Při navázání připojení mezi klientem a serverem se identita klienta nezmění, s výjimkou jedné situace: po otevření klienta WCF platí všechny následující podmínky:

Postupy vytvoření kontextu zabezpečení (při použití relace zabezpečení přenosu nebo relace zabezpečení zpráv) jsou vypnuty (EstablishSecurityContext vlastnost je nastavena na false případ zabezpečení zpráv nebo přenosu, které nejsou schopné navázat relace zabezpečení, se používají v případě zabezpečení přenosu. Jedním z příkladů takového přenosu je HTTPS).
Používáte ověřování systému Windows.
Přihlašovací údaje explicitně nenastavíte.
Voláte službu pod zosobněným kontextem zabezpečení.

Pokud jsou tyto podmínky pravdivé, může se po otevření klienta WCF změnit identita použitá k ověření klienta ve službě (nemusí se jednat o zosobněnou identitu, ale identitu procesu). K tomu dochází, protože přihlašovací údaje systému Windows používané k ověření klienta ve službě se přenášejí se každou zprávou a přihlašovací údaje použité k ověření se získávají z identity systému Windows aktuálního vlákna. Pokud se změní identita windows aktuálního vlákna (například zosobněním jiného volajícího), můžou se také změnit přihlašovací údaje připojené ke zprávě a použité k ověření klienta ve službě.

Pokud chcete mít deterministické chování při použití ověřování systému Windows spolu s zosobněním, musíte explicitně nastavit přihlašovací údaje systému Windows nebo musíte vytvořit kontext zabezpečení se službou. K tomu použijte relaci zabezpečení zpráv nebo přenosovou relaci zabezpečení. Přenos net.tcp může například poskytovat relaci zabezpečení přenosu. Kromě toho musíte při volání služby použít pouze synchronní verzi klientských operací. Pokud vytvoříte kontext zabezpečení zprávy, neměli byste ponechat připojení ke službě otevřené déle než nakonfigurované období obnovení relace, protože identita se může během procesu obnovení relace také změnit.

Zachytávání přihlašovacích údajů

Následující platí pro rozhraní .NET Framework 3.5 a další verze.

Přihlašovací údaje používané klientem nebo službou jsou založeny na aktuálním kontextovém vlákně. Přihlašovací údaje jsou získány při Open volání metody (nebo BeginOpen, pro asynchronní volání) klienta nebo služby. Pro třídy ServiceHost a ClientBase<TChannel>Open třídy dědí a BeginOpen metody z Open třídy a BeginOpen metody CommunicationObject třídy.

Poznámka:

Při použití BeginOpen metody nelze zaručit, že přihlašovací údaje zachycené jako přihlašovací údaje procesu, který volá metodu.

Mezipaměti tokenů umožňují přehrání pomocí zastaralých dat.

WCF používá funkci místní autority zabezpečení (LSA) LogonUser k ověřování uživatelů podle uživatelského jména a hesla. Vzhledem k tomu, že přihlašovací funkce je nákladná operace, wcf umožňuje ukládat tokeny do mezipaměti, které představují ověřené uživatele za účelem zvýšení výkonu. Mechanismus ukládání do mezipaměti ukládá výsledky pro LogonUser následné použití. Tento mechanismus je ve výchozím nastavení zakázaný; a to enable it, set the property to , or use cacheLogonTokens the attribute of the< userNameAuthentication>.trueCacheLogonTokens

Hodnotu TTL (Time to Live) pro tokeny v mezipaměti můžete nastavit nastavením CachedLogonTokenLifetime vlastnosti na TimeSpanhodnotu nebo použít cachedLogonTokenLifetime atribut userNameAuthentication prvku. Výchozí hodnota je 15 minut. Všimněte si, že když je token uložený v mezipaměti, může každý klient, který zobrazuje stejné uživatelské jméno a heslo, použít token, i když se uživatelský účet odstraní z Windows nebo pokud došlo ke změně hesla. Dokud nevyprší hodnota TTL a token se odebere z mezipaměti, WCF povolí ověření (potenciálně škodlivého) uživatele.

Pokud chcete tento problém zmírnit: Snižte okno útoku nastavením cachedLogonTokenLifetime hodnoty na nejkratší časové období, které uživatelé potřebují.

Autorizace vydaného tokenu: Resetování platnosti na velkou hodnotu

Za určitých podmínek ExpirationTime může být vlastnost AuthorizationContext nastavena na neočekávaně větší hodnotu ( MaxValue hodnota pole minus jeden den nebo 20. prosince 9999).

K tomu dochází při použití WSFederationHttpBinding jakékoli systémové vazby, které mají vystavený token jako typ přihlašovacích údajů klienta.

K tomu dochází také při vytváření vlastních vazeb pomocí jedné z následujících metod:

Aby se to zmírnit, musí zásady autorizace zkontrolovat akci a čas vypršení platnosti jednotlivých zásad autorizace.

Služba používá jiný certifikát než zamýšlený klient.

Za určitých podmínek může klient digitálně podepsat zprávu certifikátem X.509 a nechat službu načíst jiný certifikát, než je zamýšlený.

K tomu může dojít za následujících okolností:

Klient digitálně podepíše zprávu pomocí certifikátu X.509 a nepřipočítá certifikát X.509 ke zprávě, ale odkazuje pouze na certifikát pomocí jeho identifikátoru klíče subjektu.
Počítač služby obsahuje dva nebo více certifikátů se stejným veřejným klíčem, ale obsahují jiné informace.
Služba načte certifikát, který odpovídá identifikátoru klíče subjektu, ale nejedná se o certifikát, který má klient použít. Když WCF obdrží zprávu a ověří podpis, WCF mapuje informace v nezamýšleném certifikátu X.509 na sadu deklarací identity, které se liší a potenciálně zvýší z toho, co klient očekával.

Pokud chcete tento problém zmírnit, odkazujte na certifikát X.509 jiným způsobem, například pomocí IssuerSerial.

Sdílet prostřednictvím