Höjning av privilegier
Utökade privilegier resulterar från att ge en angripare behörighet utöver de som ursprungligen beviljades. Till exempel höjer en angripare med en behörighetsuppsättning med "skrivskyddade" behörigheter på något sätt uppsättningen så att den inkluderar "läsa och skriva".
Betrodd STS bör signera SAML-tokenanspråk
En SAML-token (Security Assertions Markup Language) är en generisk XML-token som är standardtypen för utfärdade token. En SAML-token kan konstrueras av en säkerhetstokentjänst (STS) som slutwebbtjänsten litar på i ett typiskt utbyte. SAML-token innehåller anspråk i -instruktioner. En angripare kan kopiera anspråken från en giltig token, skapa en ny SAML-token och signera den med en annan utfärdare. Avsikten är att avgöra om servern validerar utfärdare och, om inte, använda svagheten för att konstruera SAML-token som tillåter privilegier utöver de som är avsedda för en betrodd STS.
Klassen SamlAssertion verifierar den digitala signaturen som finns i en SAML-token och standard SamlSecurityTokenAuthenticator kräver att SAML-token signeras av ett X.509-certifikat som är giltigt när CertificateValidationModeIssuedTokenServiceCredential klassens värde är inställt på ChainTrust. ChainTrust läget är inte tillräckligt för att avgöra om utfärdaren av SAML-token är betrodd. Tjänster som kräver en mer detaljerad förtroendemodell kan antingen använda auktoriserings- och tvingande principer för att kontrollera utfärdaren av anspråksuppsättningarna som skapats av utfärdad tokenautentisering eller använda X.509-verifieringsinställningarna på IssuedTokenServiceCredential för att begränsa uppsättningen tillåtna signeringscertifikat. Mer information finns i Hantera anspråk och auktorisering med identitetsmodellen och federation och utfärdade token.
Växla identitet utan säkerhetskontext
Följande gäller endast För WinFX.
När en anslutning upprättas mellan en klient och server ändras inte klientens identitet, förutom i en situation: när WCF-klienten har öppnats, om alla följande villkor är uppfyllda:
Procedurerna för att upprätta en säkerhetskontext (med hjälp av en transportsäkerhetssession eller en meddelandesäkerhetssession) är avstängda (EstablishSecurityContext egenskapen är inställd
falsepå i händelse av meddelandesäkerhet eller transport som inte kan upprätta säkerhetssessioner används i transportsäkerhetsfall. HTTPS är ett exempel på sådana transporter).Du använder Windows-autentisering.
Du anger inte uttryckligen autentiseringsuppgifterna.
Du anropar tjänsten under den personifierade säkerhetskontexten.
Om dessa villkor är sanna kan identiteten som används för att autentisera klienten till tjänsten ändras (det kanske inte är den personifierade identiteten utan processidentiteten i stället) när WCF-klienten har öppnats. Detta beror på att Windows-autentiseringsuppgifterna som används för att autentisera klienten till tjänsten överförs med varje meddelande, och de autentiseringsuppgifter som används för autentisering hämtas från den aktuella trådens Windows-identitet. Om Windows-identiteten för den aktuella tråden ändras (till exempel genom att personifiera en annan anropare) kan även autentiseringsuppgifterna som är kopplade till meddelandet och används för att autentisera klienten till tjänsten ändras.
Om du vill ha deterministiskt beteende när du använder Windows-autentisering tillsammans med personifiering måste du uttryckligen ange Windows-autentiseringsuppgifterna eller så måste du upprätta en säkerhetskontext med tjänsten. Det gör du genom att använda en meddelandesäkerhetssession eller en transportsäkerhetssession. Till exempel kan net.tcp-transporten tillhandahålla en transportsäkerhetssession. Dessutom får du bara använda en synkron version av klientåtgärder när du anropar tjänsten. Om du upprättar en meddelandesäkerhetskontext bör du inte hålla anslutningen till tjänsten öppen längre än den konfigurerade sessionsförnyelseperioden, eftersom identiteten också kan ändras under förnyelseprocessen för sessionen.
Avbildning av autentiseringsuppgifter
Följande gäller för .NET Framework 3.5 och efterföljande versioner.
Autentiseringsuppgifter som används av klienten eller tjänsten baseras på den aktuella kontexttråden. Autentiseringsuppgifterna hämtas när Open metoden (eller BeginOpen, för asynkrona anrop) för klienten eller tjänsten anropas. För både klasserna och ärver metoderna och BeginOpen från Open - och BeginOpen -metoderna i CommunicationObject klassen.ClientBase<TChannel>ServiceHostOpen
Kommentar
När du använder BeginOpen metoden kan de insamlade autentiseringsuppgifterna inte garanteras vara autentiseringsuppgifterna för den process som anropar metoden.
Tokencacheminnen tillåter uppspelning med föråldrade data
WCF använder funktionen lokal säkerhetsmyndighet (LSA) LogonUser för att autentisera användare med användarnamn och lösenord. Eftersom inloggningsfunktionen är en kostsam åtgärd kan du med WCF cachelagra token som representerar autentiserade användare för att öka prestandan. Cachelagringsmekanismen sparar resultatet från LogonUser för efterföljande användningar. Den här mekanismen är inaktiverad som standard. om du vill aktivera den anger du egenskapen till eller använder cacheLogonTokens attributet <userNameAuthentication>.trueCacheLogonTokens
Du kan ange TTL (Time to Live) för cachelagrade token genom att ange CachedLogonTokenLifetime egenskapen till ett TimeSpan, eller använda cachedLogonTokenLifetime -attributet för elementet userNameAuthentication . Standardvärdet är 15 minuter. Observera att även om en token cachelagras kan alla klienter som visar samma användarnamn och lösenord använda token, även om användarkontot tas bort från Windows eller om lösenordet har ändrats. Tills TTL upphör att gälla och token tas bort från cacheminnet tillåter WCF (eventuellt skadlig) användare att autentisera.
Så här åtgärdar du detta: Minska attackfönstret genom att ange cachedLogonTokenLifetime värdet till den kortaste tid som användarna behöver.
Utfärdad tokenauktorisering: Förfalloåterställning till stort värde
Under vissa förhållanden ExpirationTime kan egenskapen för egenskapen AuthorizationContext anges till ett oväntat större värde ( MaxValue fältvärdet minus en dag eller 20 december 9999).
Detta inträffar när du använder WSFederationHttpBinding och någon av de systembaserade bindningar som har en utfärdad token som klientautentiseringstyp.
Detta inträffar också när du skapar anpassade bindningar med någon av följande metoder:
För att minimera detta måste auktoriseringsprincipen kontrollera åtgärden och förfallotiden för varje auktoriseringsprincip.
Tjänsten använder ett annat certifikat än den klient som är avsedd
Under vissa förhållanden kan en klient signera ett meddelande digitalt med ett X.509-certifikat och låta tjänsten hämta ett annat certifikat än det avsedda.
Detta kan inträffa under följande omständigheter:
Klienten signerar ett meddelande digitalt med ett X.509-certifikat och bifogar inte X.509-certifikatet till meddelandet, utan refererar bara till certifikatet med dess ämnesnyckelidentifierare.
Tjänstens dator innehåller två eller flera certifikat med samma offentliga nyckel, men de innehåller annan information.
Tjänsten hämtar ett certifikat som matchar ämnesnyckelidentifieraren, men det är inte den klient som ska användas. När WCF tar emot meddelandet och verifierar signaturen mappar WCF informationen i det oavsiktliga X.509-certifikatet till en uppsättning anspråk som är olika och potentiellt upphöjda från vad klienten förväntade sig.
Du kan åtgärda detta genom att referera till X.509-certifikatet på ett annat sätt, till exempel att använda IssuerSerial.