Avslöjande av information
Informationsutlämnande gör det möjligt för en angripare att få värdefull information om ett system. Tänk därför alltid på vilken information du avslöjar och om den kan användas av en obehörig användare. Följande visar möjliga informationsattacker och innehåller åtgärder för var och en.
Meddelandesäkerhet och HTTP
Om du använder säkerhet på meddelandenivå över ett HTTP-transportlager bör du vara medveten om att säkerhet på meddelandenivå inte skyddar HTTP-huvuden. Det enda sättet att skydda HTTP-huvuden är att använda HTTPS-transport i stället för HTTP. HTTPS-transport gör att hela meddelandet, inklusive HTTP-huvudena, krypteras med hjälp av SSL-protokollet (Secure Sockets Layer).
Principinformation
Det är viktigt att hålla principen säker, särskilt i federationsscenarier där känsliga krav för utfärdad token eller information om token-utfärdare exponeras i principen. I dessa fall är rekommendationen att skydda den federerade tjänstens principslutpunkt för att förhindra att angripare hämtar information om tjänsten, till exempel vilken typ av anspråk som ska placeras i den utfärdade token eller omdirigera klienter till utfärdare av skadliga token. En angripare kan till exempel identifiera användarnamn/lösenordspar genom att konfigurera om den federerade förtroendekedjan så att den avslutas i en utfärdare som utförde en man-in-the-middle-attack. Vi rekommenderar också att federerade klienter som hämtar sina bindningar via principhämtning kontrollerar att de litar på utfärdarna i den erhållna federerade förtroendekedjan. Mer information om federationsscenarier finns i Federation.
Minnesdumpar kan avslöja anspråksinformation
När ett program misslyckas kan loggfiler, till exempel de som skapats av Dr. Watson, innehålla anspråksinformationen. Den här informationen bör inte exporteras till andra entiteter, till exempel supportteam. Annars exporteras även anspråksinformationen som innehåller privata data. Du kan åtgärda detta genom att inte skicka loggfilerna till okända entiteter.
Slutpunktsadresser
En slutpunktsadress innehåller den information som behövs för att kommunicera med en slutpunkt. SOAP-säkerhet måste innehålla adressen i sin helhet i de meddelanden om säkerhetsförhandling som utbyts för att kunna förhandla om en symmetrisk nyckel mellan en klient och en server. Eftersom säkerhetsförhandling är en bootstrap-process kan adresshuvudena inte krypteras under den här processen. Adressen bör därför inte innehålla några konfidentiella uppgifter. annars leder det till informationsröjandeattacker.
Certifikat som överförts okrypterade
När du använder ett X.509-certifikat för att autentisera en klient överförs certifikatet i klartext i SOAP-huvudet. Var medveten om detta som en potentiellt personligt identifierbar information (PII) avslöjande. Det här är inte ett problem för TransportWithMessageCredential läget, där hela meddelandet krypteras med säkerhet på transportnivå.
Tjänstreferenser
En tjänstreferens är en referens till en annan tjänst. En tjänst kan till exempel skicka en tjänstreferens till en klient under en åtgärd. Tjänstreferensen används också med en betrodd identitetsverifierare, en intern komponent som säkerställer målobjektets identitet innan information som programdata eller autentiseringsuppgifter avslöjas för målet. Om fjärrförtroendeidentiteten inte kan verifieras eller är felaktig bör avsändaren se till att inga data har avslöjats som kan kompromettera sig själv, programmet eller användaren.
Här är några av följande åtgärder:
Tjänstreferenser antas vara tillförlitliga. Var försiktig när du överför tjänstreferensinstanser för att säkerställa att de inte har manipulerats.
Vissa program kan presentera en användarupplevelse som möjliggör interaktiv etablering av förtroende baserat på data i tjänstreferensen och förtroendedata som bevisas av fjärrvärden. WCF tillhandahåller utökningspunkter för en sådan anläggning, men användaren måste implementera dem.
NTLM
I Windows-domänmiljön använder Windows-autentisering som standard Kerberos-protokollet för att autentisera och auktorisera användare. Om Kerberos-protokollet inte kan användas av någon anledning används NT LAN Manager (NTLM) som reserv. Du kan inaktivera det här beteendet genom att ange AllowNtlm egenskapen till false. Problem som du bör känna till när du tillåter NTLM är:
NTLM exponerar klientens användarnamn. Om användarnamnet måste hållas konfidentiellt anger du
AllowNTLMegenskapen för bindningen tillfalse.NTLM tillhandahåller inte serverautentisering. Därför kan klienten inte se till att den kommunicerar med rätt tjänst när du använder NTLM som autentiseringsprotokoll.
Ange klientautentiseringsuppgifter eller ogiltig identitet tvingar NTLM-användning
När du skapar en klient, anger klientautentiseringsuppgifter utan domännamn eller anger en ogiltig serveridentitet, används NTLM i stället för Kerberos-protokollet (om AllowNtlm egenskapen är inställd på true). Eftersom NTLM inte utför serverautentisering kan information eventuellt avslöjas.
Det går till exempel att ange autentiseringsuppgifter för Windows-klienten utan ett domännamn, som du ser i följande Visual C#-kod.
MyChannelFactory.Credentials.Windows.ClientCredential = new System.Net.NetworkCredential("username", "password");
Koden anger inget domännamn och därför används NTLM.
Om domänen anges, men ett ogiltigt namn på tjänstens huvudnamn anges med hjälp av funktionen för slutpunktsidentitet, används NTLM. Mer information om hur slutpunktsidentitet anges finns i Tjänstidentitet och autentisering.