Metodtips för säkerhet i WCF
I följande avsnitt listas metodtipsen när du skapar säkra program med hjälp av Windows Communication Foundation (WCF). Mer information om säkerhet finns i Säkerhetsöverväganden, säkerhetsöverväganden för data och säkerhetsöverväganden med metadata.
Identifiera tjänster som utför Windows-autentisering med SPN
Tjänster kan identifieras med antingen användarens huvudnamn (UPN) eller tjänstens huvudnamn (SPN). Tjänster som körs under datorkonton, till exempel nätverkstjänsten, har en SPN-identitet som motsvarar den dator som de kör. Tjänster som körs under användarkonton har en UPN-identitet som motsvarar den användare som de kör som, även om setspn verktyget kan användas för att tilldela ett SPN till användarkontot. Konfigurera en tjänst så att den kan identifieras via SPN och konfigurera klienterna som ansluter till tjänsten för att använda det SPN kan göra vissa attacker svårare. Den här vägledningen gäller bindningar med Kerberos- eller SSPI-förhandling. Klienter bör fortfarande ange ett SPN om SSPI återgår till NTLM.
Verifiera tjänstidentiteter i WSDL
Med WS-SecurityPolicy kan tjänster publicera information om sina egna identiteter i metadata. När den hämtas via svcutil eller andra metoder, till exempel WsdlImporter, översätts den här identitetsinformationen till identitetsegenskaperna för WCF-tjänstens slutpunktsadresser. Klienter som inte verifierar att dessa tjänstidentiteter är korrekta och giltiga kringgår effektivt tjänstautentisering. En skadlig tjänst kan utnyttja sådana klienter för att köra vidarebefordran av autentiseringsuppgifter och andra "man i mitten"-attacker genom att ändra den identitet som påstås i dess WSDL.
Använda X509-certifikat i stället för NTLM
WCF erbjuder två mekanismer för peer-to-peer-autentisering: X509-certifikat (används av peer-kanal) och Windows-autentisering där en SSPI-förhandling nedgraderas från Kerberos till NTLM. Certifikatbaserad autentisering med nyckelstorlekar på 1 024 bitar eller mer föredras framför NTLM av flera orsaker:
tillgängligheten för ömsesidig autentisering,
användning av starkare kryptografiska algoritmer och
den större svårigheten att använda vidarebefordrade X509-autentiseringsuppgifter.
Återställ alltid efter personifiering
När du använder API:er som aktiverar personifiering av en klient måste du återgå till den ursprungliga identiteten. När du till exempel använder WindowsIdentity och WindowsImpersonationContextanvänder du C# using -instruktionen eller Visual Basic-instruktionen Using , som du ser i följande kod. Klassen WindowsImpersonationContext implementerar IDisposable gränssnittet och därför återgår CLR (Common Language Runtime) automatiskt till den ursprungliga identiteten när koden lämnar using blocket.
WindowsIdentity identity = ServiceSecurityContext.Current.WindowsIdentity;
using (identity.Impersonate())
{
// Run code under the caller's identity.
}
Dim identity = ServiceSecurityContext.Current.WindowsIdentity
Using identity.Impersonate()
' Run code under the caller's identity.
End Using
Personifiera endast efter behov
Impersonate Med hjälp av -metoden för WindowsIdentity klassen är det möjligt att använda personifiering i ett mycket kontrollerat omfång. Detta står i kontrast till att använda Impersonation egenskapen OperationBehaviorAttributeför , som tillåter personifiering för hela åtgärdens omfång. När det är möjligt kontrollerar du omfånget för personifiering med hjälp av den mer exakta Impersonate metoden.
Hämta metadata från betrodda källor
Se till att du litar på källan för dina metadata och se till att ingen har manipulerat metadata. Metadata som hämtas med HTTP-protokollet skickas i klartext och kan manipuleras. Om tjänsten använder HttpsGetEnabled egenskaperna och HttpsGetUrl använder du url:en som tillhandahålls av tjänstens skapare för att ladda ned data med hjälp av HTTPS-protokollet.
Publicera metadata med säkerhet
Skydda metadatautbytesslutpunkten med transport- eller meddelandenivåsäkerhet för att förhindra manipulering av en tjänsts publicerade metadata. Mer information finns i Publicera metadataslutpunkter och Så här publicerar du metadata för en tjänst med hjälp av kod.
Se till att lokal utfärdare används
Om en utfärdaradress och bindning anges för en viss bindning används inte den lokala utfärdaren för slutpunkter som använder bindningen. Klienter som förväntar sig att alltid använda den lokala utfärdaren bör se till att de inte använder en sådan bindning eller att de ändrar bindningen så att utfärdarens adress är null.
Storlekskvoter för SAML-token
När SAML-token (Security Assertions Markup Language) serialiseras i meddelanden, antingen när de utfärdas av en Säkerhetstokentjänst (STS) eller när klienter presenterar dem för tjänster som en del av autentiseringen, måste den maximala meddelandestorlekskvoten vara tillräckligt stor för att rymma SAML-token och de andra meddelandedelarna. I normala fall räcker standardkvoterna för meddelandestorlek. Men i fall där en SAML-token är stor eftersom den innehåller hundratals anspråk bör kvoterna ökas för att hantera den serialiserade token. Mer information om kvoter finns i Säkerhetsöverväganden för data.
Ange SecurityBindingElement.IncludeTimestamp till True för anpassade bindningar
När du skapar en anpassad bindning måste du ange IncludeTimestamp till true. Annars, om IncludeTimestamp är inställt på false, och klienten använder en asymmetrisk nyckelbaserad token, till exempel ett X509-certifikat, kommer meddelandet inte att signeras.