Odepření služby

Článek
03/05/2024

K odepření služby dochází v případě, že je systém zahlcený takovým způsobem, že zprávy nelze zpracovat nebo jsou zpracovávány extrémně pomalu.

Nadbytečná spotřeba paměti

K problému může dojít při čtení dokumentu XML s velkým počtem jedinečných místních názvů, oborů názvů nebo předpon. Pokud používáte třídu, která je odvozena od XmlReader, a voláte LocalNamebuď , Prefix nebo NamespaceURI vlastnost pro každou položku, vrácený řetězec je přidán do NameTable. Kolekce uchovávané nikdy nezmenšuje NameTable velikost a vytváří virtuální "nevracení paměti" popisovačů řetězců.

Mezi zmírnění rizik patří:

Odvozujte z NameTable třídy a vynucujte maximální kvótu velikosti. (Nelze zabránit použití NameTable nebo přepnutí NameTable , pokud je plný.)
Vyhněte se použití uvedených vlastností a místo toho použijte MoveToAttribute metodu s metodou IsStartElement tam, kde je to možné; tyto metody nevrací řetězce, a proto se vyhněte problému přeplnění NameTable kolekce.

Škodlivý klient odesílá do služby nadměrné žádosti o licence.

Pokud škodlivý klient bombarduje službu s nadměrnými požadavky na licence, může způsobit, že server používá nadměrnou paměť.

Omezení rizik: Použijte následující vlastnosti LocalServiceSecuritySettings třídy:

MaxCachedCookies: Řídí maximální počet časových hranic SecurityContextToken, které server ukládá do mezipaměti po SPNego nebo SSL vyjednávání.
IssuedCookieLifetime: řídí dobu životnosti SecurityContextTokens , kterou server vydává po provedení SPNego nebo SSL vyjednávání. Server ukládá soubory do SecurityContextTokenmezipaměti pro toto časové období.
MaxPendingSessions: řídí maximální počet zabezpečených konverzací, které jsou vytvořeny na serveru, ale pro které nebyly zpracovány žádné zprávy aplikace. Tato kvóta brání klientům v vytváření zabezpečených konverzací ve službě, což způsobí, že služba udržuje stav na klienta, ale nikdy je nepoužívá.
InactivityTimeout: Řídí maximální dobu, po kterou služba udržuje zabezpečenou konverzaci naživu, aniž by od klienta obdržela zprávu aplikace pro konverzaci. Tato kvóta brání klientům v vytváření zabezpečených konverzací ve službě, což způsobí, že služba udržuje stav na klienta, ale nikdy je nepoužívá.

WSDualHttpBinding nebo duální vlastní vazby vyžadují ověření klienta.

Ve výchozím nastavení WSDualHttpBinding je povolené zabezpečení. Je však možné, že pokud je ověřování klienta zakázáno nastavením ClientCredentialType vlastnosti Nonena , může škodlivý uživatel způsobit útok dosílání služby na třetí službu. K tomu může dojít, protože škodlivý klient může nasměrovat službu tak, aby odeslala datový proud zpráv do třetí služby.

Chcete-li tento problém zmírnit, nenastavujte vlastnost na Nonehodnotu . Mějte také na paměti tuto možnost při vytváření vlastní vazby, která má duální vzor zpráv.

Protokol událostí auditování je možné vyplnit.

Pokud uživatel se zlými úmysly rozumí tomu, že auditování je povolené, může útočník odeslat neplatné zprávy, které způsobí zápis položek auditu. Pokud se tímto způsobem vyplní protokol auditu, systém auditování selže.

Pokud chcete tento problém zmírnit, nastavte SuppressAuditFailure vlastnost na true vlastnosti Prohlížeč událostí a použijte ji k řízení chování auditování. Další informace o použití Prohlížeč událostí k zobrazení a správě protokolů událostí najdete v tématu Prohlížeč událostí. Další informace najdete v tématu Auditování.

Neplatné implementace IAuthorizationPolicy můžou způsobit, že služba přestane reagovat.

Evaluate Volání metody na chybné implementaci IAuthorizationPolicy rozhraní může způsobit, že služba přestane reagovat.

Zmírnění: Používejte pouze důvěryhodný kód. To znamená, že použijte pouze kód, který jste napsali a otestovali, nebo který pochází od důvěryhodného poskytovatele. Nepovolujte připojení nedůvěryhodných rozšíření IAuthorizationPolicy do kódu bez řádného zvážení. To platí pro všechna rozšíření použitá v implementaci služby. WCF nerozlišuje mezi kódem aplikace a cizím kódem, který je připojený pomocí bodů rozšiřitelnosti.

Maximální velikost tokenu Kerberos může vyžadovat změnu velikosti

Pokud klient patří do velkého počtu skupin (přibližně 900, i když se skutečné číslo liší v závislosti na skupinách), může dojít k problému, když blok záhlaví zprávy překročí 64 kilobajtů. V takovém případě můžete zvětšit maximální velikost tokenu Kerberos. Možná budete také muset zvětšit maximální velikost zprávy WCF tak, aby vyhovovala většímu tokenu Kerberos.

Výsledkem automatického zápisu je více certifikátů se stejným názvem subjektu pro počítač.

Automatický zápis je schopnost systému Windows Server 2003 automaticky registrovat uživatele a počítače pro certifikáty. Pokud je počítač v doméně s povolenou funkcí, automaticky se vytvoří certifikát X.509 s zamýšleným účelem ověření klienta a vloží se do úložiště osobních certifikátů místního počítače při každém připojení nového počítače k síti. Automatický zápis však používá stejný název subjektu pro všechny certifikáty, které vytvoří v mezipaměti.

Dopadem je, že služby WCF se nemusí podařit otevřít v doménách s automatickým zápisem. K tomu dochází, protože výchozí kritéria vyhledávání přihlašovacích údajů X.509 služby X.509 mohou být nejednoznačná, protože existuje více certifikátů s plně kvalifikovaným názvem DNS (Domain Name System). Jeden certifikát pochází z automatického zápisu; druhým může být certifikát vystavený vlastním držitelem.

Pokud chcete tento problém zmírnit, odkazujte na přesný certifikát, který chcete použít, pomocí přesnějšího vyhledávacího <kritéria pro serviceCredentials>. Použijte FindByThumbprint například možnost a zadejte certifikát podle jeho jedinečného kryptografického otisku (hash).

Další informace o funkci automatického zápisu naleznete v tématu Automatické zápisy certifikátů v systému Windows Server 2003.

Poslední z více alternativních názvů subjektů používaných k autorizaci

Ve výjimečných případech, kdy certifikát X.509 obsahuje více alternativních názvů subjektů a autorizujete použití alternativního názvu subjektu, může autorizace selhat.

Ochrana konfiguračních souborů pomocí seznamů ACL

Požadované a volitelné deklarace identity můžete zadat v kódu a konfiguračních souborech pro tokeny vydané cardspace. Výsledkem je, že se odpovídající prvky vygenerují ve RequestSecurityToken zprávách odesílaných službě tokenů zabezpečení. Útočník může upravit kód nebo konfiguraci tak, aby odebral požadované nebo volitelné deklarace identity a potenciálně získal službu tokenů zabezpečení k vydání tokenu, který nepovoluje přístup k cílové službě.

Zmírnění: Vyžaduje přístup k počítači pro úpravu konfiguračního souboru. K zabezpečení konfiguračních souborů použijte seznamy řízení přístupu k souborům (ACL). WCF vyžaduje, aby byl kód v adresáři aplikace nebo globální mezipaměti sestavení předtím, než umožní načtení takového kódu z konfigurace. K zabezpečení adresářů použijte seznamy ACL adresáře.

Je dosaženo maximálního počtu zabezpečených relací pro službu

Když se klient úspěšně ověří službou a vytvoří se zabezpečená relace se službou, služba sleduje relaci, dokud ji klient nezruší nebo nevyprší platnost relace. Každá zavedená relace se počítá do limitu maximálního počtu aktivních souběžných relací se službou. Po dosažení tohoto limitu se klienti, kteří se pokusí vytvořit novou relaci s touto službou, budou odmítnuti, dokud nevyprší platnost jedné nebo více aktivních relací nebo se klient zruší. Klient může mít více relací se službou a každá z těchto relací se počítá do limitu.

Poznámka:

Pokud používáte stavové relace, předchozí odstavec se nepoužije. Další informace o stavovýchrelacích

Pokud chcete tento problém zmírnit, nastavte limit maximálního počtu aktivních relací a maximální životnost relace nastavením SecurityBindingElement vlastnosti SecurityBindingElement třídy.

Sdílet prostřednictvím