Veröffentlichung von Informationen
Die Veröffentlichung von Informationen ermöglicht Angreifern, an wertvolle Informationen über ein System zu gelangen. Daher sollten Sie immer genau überlegen, welche Informationen offengelegt werden und ob sie von anderen Personen böswillig missbraucht werden könnten. Im Folgenden finden Sie eine Übersicht über mögliche Angriffe auf veröffentlichte Informationen mit den entsprechenden Entschärfungen.
Nachrichtensicherheit und HTTP
Falls Sie die Sicherheit auf Nachrichtenebene mit einer HTTP-Transportschicht verwenden, dürfen Sie nicht vergessen, dass bei dieser Sicherheitsstufe HTTP-Header nicht geschützt sind. HTTP-Header lassen sich nur durch einen HTTPS-Transport, nicht jedoch durch HTTP schützen. Beim HTTPS-Transport wird die gesamte Nachricht einschließlich der HTTP-Header mit dem SSL-Protokoll (Secure Sockets Layer) verschlüsselt.
Richtlinieninformationen
Der Schutz von Richtlinien ist sehr wichtig, vor allem in Verbundszenarien, bei denen die Richtlinien auch vertrauliche Informationen zu den Anforderungen für ausgegebene Token und zu den Tokenausstellern enthalten. In diesen Fällen sollte möglichst der Richtlinienendpunkt des Verbunddiensts gesichert werden, damit Angreifer keine Informationen zum Dienst, wie zum Beispiel Informationen zur Art der Ansprüche, die in das ausgegebene Token aufgenommen werden müssen, einholen oder keine Clients an bösartige Tokenaussteller umleiten können. So können Angreifer beispielsweise Benutzernamen-/Kennwortkombinationen ermitteln, indem sie die Vertrauenskette des Verbunds so umkonfigurieren, dass sie bei einem Aussteller endet, der einen Man-In-The-Middle-Angriff (MITM-Angriff, Janusangriff) durchgeführt hat. Auch sollte von Verbundclients, die ihre Bindungen über den Abruf einer Richtlinie erhalten, überprüft werden, ob die Aussteller in der bezogenen Vertrauenskette des Verbunds tatsächlich vertrauenswürdig sind. Weitere Informationen über Verbundszenarien finden Sie unter Verbund.
Anspruchsinformationen in Speicherabbildern
Falls in einer Anwendung ein Fehler auftritt, können Protokolldateien (wie zum Beispiel die von Dr. Watson erzeugten Protokolldateien) Anspruchsinformationen enthalten. Diese Informationen sollten nicht für andere Einheiten in der Organisation wie Supportteams exportiert werden, da sonst auch die Anspruchsinformationen mit persönlichen Daten exportiert werden. Sie können diese Gefahr umgehen, indem Sie keine Protokolldateien an Unbekannte senden.
Endpunktadressen
Eine Endpunktadresse enthält die für die Kommunikation mit einem Endpunkt erforderlichen Informationen. Bei der SOAP-Sicherheit muss die vollständige Adresse in den gesendeten Sicherheitsaushandlungsnachrichten enthalten sein, damit zwischen Client und Server ein symmetrischer Schlüssel ausgehandelt werden kann. Da es sich bei der Sicherheitsaushandlung um einen Bootstrapprozess handelt, können die Adressheader während des Prozesses nicht verschlüsselt werden. Daher sollte die Adresse keine vertraulichen Daten enthalten, da dies zu Angriffen auf veröffentlichte Informationen führen kann.
Unverschlüsselt übertragene Zertifikate
Wenn Sie für die Authentifizierung eines Clients ein X.509-Zertifikat verwenden, wird das Zertifikat unverschlüsselt im SOAP-Header übertragen. Beachten Sie, dass es sich hierbei um eine mögliche Veröffentlichung personenbezogener Informationen (PII, Personally Identifiable Information) handelt. Dies ist kein Problem beim TransportWithMessageCredential-Modus, bei dem die gesamte Nachricht mithilfe von Sicherheit auf Transportebene verschlüsselt wird.
Dienstverweise
Bei einem Dienstverweis handelt es sich um einen Verweis auf einen anderen Dienst. So kann zum Beispiel ein Dienst im Laufe eines Vorgangs einen Dienstverweis an einen Client übergeben. Der Dienstverweis wird auch zusammen mit einer Vertrauensidentitätsprüfung verwendet. Hierbei handelt es sich um eine interne Komponente, durch die die Identität des Zielprinzipals sichergestellt wird, bevor auf dem Ziel Informationen wie Anwendungs- oder Anmeldedaten bekanntgegeben werden. Falls die Remotevertrauensidentität nicht überprüft werden kann oder falsch ist, sollte sich der Sender vergewissern, dass keine Daten veröffentlicht wurden, die den Sender, die Anwendung oder den Benutzer gefährden könnten.
Folgende Maßnahmen mindern das Risiko:
Dienstverweise werden als vertrauenswürdig angesehen. Falls Sie Dienstverweisinstanzen übertragen, sollten Sie daher sicherstellen, dass diese nicht manipuliert wurden.
Bei einigen Anwendungen haben Benutzer die Möglichkeit, die Vertrauenswürdigkeit interaktiv basierend auf Daten im Dienstverweis und anhand von vertrauenswürdigen Daten, die durch den Remotehost belegt wurden, herzustellen. WCF stellt Erweiterungspunkte für diese Funktion bereit, diese müssen jedoch vom Benutzer implementiert werden.
NTLM
In der Windows-Domänenumgebung wird zur Authentifizierung und Autorisierung von Benutzern über die Windows-Authentifizierung standardmäßig das Kerberos-Protokoll verwendet. Falls das Kerberos-Protokoll nicht verwendet werden kann, wird für diesen Zweck NT LAN Manager (NTLM) herangezogen. Sie können dieses Verhalten deaktivieren, indem Sie die AllowNtlm-Eigenschaft auf false festlegen. Beachten Sie unter anderem folgende Punkte, wenn Sie NTLM zulassen:
NTLM gibt den Clientbenutzernamen bekannt. Falls der Benutzername vertraulich behandelt werden muss, legen Sie die
AllowNTLM-Eigenschaft für die Bindung auffalsefest.NTLM stellt keine Serverauthentifizierung bereit. Daher hat der Client bei Verwendung von NTLM als Authentifizierungsprotokoll keine Möglichkeit sicherzustellen, dass die Kommunikation mit dem richtigen Dienst erfolgt.
Die Angabe von Clientanmeldeinformationen oder eine ungültige Identität erzwingt die Verwendung von NTLM
Werden beim Erstellen eines Clients Clientanmeldeinformationen ohne Domänennamen oder eine ungültige Serveridentität angegeben, wird NTLM anstelle des Kerberos-Protokolls verwendet (sofern die AllowNtlm-Eigenschaft auf true festgelegt wurde). Da NTLM keine Serverauthentifizierung durchführt, können Informationen potenziell offengelegt werden.
So ist es beispielsweise möglich, wie im folgenden Visual C#-Code Windows-Clientanmeldeinformationen ohne Domänennamen anzugeben.
MyChannelFactory.Credentials.Windows.ClientCredential = new System.Net.NetworkCredential("username", "password");
Da im Code kein Domänenname angegeben wird, wird NTLM verwendet.
Falls bei Verwendung der Funktion für die Endpunktidentität zwar eine Domäne, jedoch ein ungültiger Dienstprinzipalname angegeben wird, wird NTLM verwendet. Weitere Informationen darüber, wie die Endpunktidentität festgelegt wird, finden Sie unter Dienstidentität und Authentifizierung.