Denial of Service
Denial of Service inträffar när ett system överbelastas på ett sådant sätt att meddelanden inte kan bearbetas, eller så bearbetas de extremt långsamt.
Överförbrukning av minne
Ett problem kan uppstå när du läser ett XML-dokument med ett stort antal unika lokala namn, namnområden eller prefix. Om du använder en klass som härleds från XmlReader, och du anropar antingen LocalNameegenskapen , Prefix eller NamespaceURI för varje objekt, läggs den returnerade strängen till i en NameTable. Samlingen som innehas av NameTable minskar aldrig i storlek, vilket skapar en virtuell "minnesläcka" av stränghandtagen.
Här är några av följande åtgärder:
Härled från NameTable klassen och framtvinga en maximal storlekskvot. (Du kan inte förhindra användning av en NameTable eller växla när den NameTable är full.)
Undvik att använda de egenskaper som nämns och använd MoveToAttribute i stället metoden med IsStartElement metoden där det är möjligt. Dessa metoder returnerar inte strängar och undviker därför problemet med att överfylla NameTable samlingen.
Skadlig klient skickar överdrivna licensbegäranden till tjänsten
Om en skadlig klient bombarderar en tjänst med överdrivna licensbegäranden kan det leda till att servern använder för mycket minne.
Åtgärd: Använd följande egenskaper för LocalServiceSecuritySettings klassen:
MaxCachedCookies: styr det maximala antalet tidsbegränsade
SecurityContextTokens som servern cachelagrar efterSPNegoellerSSLförhandling.IssuedCookieLifetime: styr livslängden för
SecurityContextTokensserverns problem efterSPNegoellerSSLförhandling. Servern cachelagrarSecurityContextTokens för den här tidsperioden.MaxPendingSessions: styr det maximala antalet säkra konversationer som upprättas på servern men som inga programmeddelanden har bearbetats för. Den här kvoten hindrar klienter från att upprätta säkra konversationer i tjänsten, vilket gör att tjänsten underhåller tillstånd per klient, men aldrig använder dem.
InactivityTimeout: styr den maximala tid som tjänsten håller en säker konversation vid liv utan att ta emot ett programmeddelande från klienten för konversationen. Den här kvoten hindrar klienter från att upprätta säkra konversationer i tjänsten, vilket gör att tjänsten underhåller tillstånd per klient, men aldrig använder dem.
WSDualHttpBinding eller dubbla anpassade bindningar kräver klientautentisering
Som standard WSDualHttpBinding har säkerheten aktiverats. Det är dock möjligt att om klientautentiseringen är inaktiverad genom att ställa in ClientCredentialType egenskapen på Nonekan en obehörig användare orsaka en överbelastningsattack på en tredje tjänst. Detta kan inträffa eftersom en skadlig klient kan dirigera tjänsten att skicka en ström av meddelanden till en tredje tjänst.
Du kan undvika detta genom att inte ange egenskapen till None. Tänk också på den här möjligheten när du skapar en anpassad bindning som har ett mönster med dubbla meddelanden.
Granskningshändelseloggen kan fyllas i
Om en obehörig användare förstår att granskning är aktiverat kan angriparen skicka ogiltiga meddelanden som gör att granskningsposter skrivs. Om granskningsloggen fylls i på det här sättet misslyckas granskningssystemet.
För att minimera detta anger du SuppressAuditFailure egenskapen till true och använder egenskaperna för Loggboken för att kontrollera granskningsbeteendet. Mer information om hur du använder Loggboken för att visa och hantera händelseloggar finns i Loggboken. Mer information finns i Granskning.
Ogiltiga implementeringar av IAuthorizationPolicy kan leda till att tjänsten slutar svara
Evaluate Om du anropar metoden för en felaktig implementering av IAuthorizationPolicy gränssnittet kan tjänsten inte svara.
Åtgärd: Använd endast betrodd kod. Använd alltså endast kod som du har skrivit och testat, eller som kommer från en betrodd provider. Tillåt inte att ej betrodda tillägg ansluts IAuthorizationPolicy till koden utan vederbörlig hänsyn. Detta gäller för alla tillägg som används i en tjänstimplementering. WCF gör ingen skillnad mellan programkod och sekundärkod som är ansluten med hjälp av utökningspunkter.
Maximal tokenstorlek för Kerberos kan behöva storleksändring
Om en klient tillhör ett stort antal grupper (cirka 900, även om det faktiska antalet varierar beroende på grupperna), kan ett problem uppstå när ett meddelandehuvuds block överskrider 64 kilobyte. I så fall kan du öka den maximala Kerberos-tokenstorleken. Du kan också behöva öka den maximala WCF-meddelandestorleken för att hantera den större Kerberos-token.
Automatisk registrering resulterar i flera certifikat med samma ämnesnamn för datorn
Automatisk registrering är funktionen för Windows Server 2003 för att automatiskt registrera användare och datorer för certifikat. När en dator finns på en domän med funktionen aktiverad skapas automatiskt ett X.509-certifikat med det avsedda syftet med klientautentisering och infogas i den lokala datorns personliga certifikatarkiv när en ny dator är ansluten till nätverket. Automatisk registrering använder dock samma ämnesnamn för alla certifikat som skapas i cacheminnet.
Effekten är att WCF-tjänster inte kan öppnas på domäner med automatisk registrering. Detta beror på att standardsökvillkoren för X.509-autentiseringsuppgifter kan vara tvetydiga eftersom det finns flera certifikat med datorns fullständigt kvalificerade DNS-namn (Domain Name System). Ett certifikat kommer från automatisk registrering. det andra kan vara ett självutfärdat certifikat.
För att minimera detta refererar du till det exakta certifikat som ska användas med hjälp av ett mer exakt sökvillkor för serviceCredentials>.< Använd till exempel alternativet FindByThumbprint och ange certifikatet med dess unika tumavtryck (hash).
Mer information om funktionen för automatisk registrering finns i Automatisk registrering av certifikat i Windows Server 2003.
Sista av flera alternativa ämnesnamn som används för auktorisering
I sällsynta fall när ett X.509-certifikat innehåller flera alternativa ämnesnamn och du auktoriserar med det alternativa ämnesnamnet kan auktoriseringen misslyckas.
Skydda konfigurationsfiler med ACL:er
Du kan ange obligatoriska och valfria anspråk i kod- och konfigurationsfiler för CardSpace-utfärdade token. Detta resulterar i att motsvarande element genereras i RequestSecurityToken meddelanden som skickas till säkerhetstokentjänsten. En angripare kan ändra kod eller konfiguration för att ta bort nödvändiga eller valfria anspråk, vilket kan få tjänsten för säkerhetstoken att utfärda en token som inte tillåter åtkomst till måltjänsten.
Så här åtgärdar du: Kräv åtkomst till datorn för att ändra konfigurationsfilen. Använd filåtkomstkontrollistor (ACL: er) för att skydda konfigurationsfiler. WCF kräver att koden finns i programkatalogen eller den globala sammansättningscacheminnet innan den tillåter att sådan kod läses in från konfigurationen. Använd katalog-ACL:er för att skydda kataloger.
Maximalt antal säkra sessioner för en tjänst har uppnåtts
När en klient har autentiserats av en tjänst och en säker session upprättas med tjänsten håller tjänsten reda på sessionen tills klienten avbryter den eller sessionen upphör att gälla. Varje etablerad session räknas mot gränsen för det maximala antalet aktiva samtidiga sessioner med en tjänst. När den här gränsen har nåtts avvisas klienter som försöker skapa en ny session med tjänsten tills en eller flera aktiva sessioner upphör att gälla eller avbryts av en klient. En klient kan ha flera sessioner med en tjänst, och var och en av dessa sessioner räknas mot gränsen.
Kommentar
När du använder tillståndskänsliga sessioner gäller inte föregående stycke. Mer information om tillståndskänsliga sessioner finns i Så här skapar du en säkerhetskontexttoken för en säker session.
För att minimera detta anger du gränsen för det maximala antalet aktiva sessioner och den maximala livslängden för en session genom att ange SecurityBindingElement klassens SecurityBindingElement egenskap.