Freigeben über

Veröffentlichung von Informationen

Die Offenlegung von Informationen ermöglicht es einem Angreifer, wertvolle Informationen über ein System zu erhalten. Überlegen Sie daher immer, welche Informationen Sie offenlegen und ob sie von einem böswilligen Benutzer verwendet werden können. Im Folgenden werden mögliche Informationsveröffentlichungsangriffe aufgelistet und Gegenmaßnahmen für jeden bereitgestellt.

Nachrichtensicherheit und HTTP

Wenn Sie die Sicherheit auf Nachrichtenebene über eine HTTP-Transportebene verwenden, beachten Sie, dass die Sicherheit auf Nachrichtenebene keine HTTP-Header schützt. Die einzige Möglichkeit zum Schutz von HTTP-Headern ist die Verwendung des HTTPS-Transports anstelle von HTTP. DER HTTPS-Transport bewirkt, dass die gesamte Nachricht, einschließlich der HTTP-Header, mithilfe des SSL-Protokolls (Secure Sockets Layer) verschlüsselt wird.

Richtlinieninformationen

Die Sicherheit der Richtlinie ist wichtig, insbesondere in Verbundszenarien, in denen vertrauliche Anforderungen an ausgestellte Token oder Tokenherausgeberinformationen in der Richtlinie verfügbar gemacht werden. In diesen Fällen empfiehlt es sich, den Richtlinienendpunkt des Verbunddiensts zu sichern, um Angreifer daran zu hindern, Informationen über den Dienst abzurufen, z. B. den Typ der Ansprüche, die im ausgestellten Token platziert werden sollen, oder Clients an böswillige Tokenherausgeber umzuleiten. Ein Angreifer könnte beispielsweise Benutzernamen-/Kennwortpaare ermitteln, indem die Verbundvertrauenskette so konfiguriert wird, dass sie in einem Aussteller beendet wird, der einen Man-in-the-Middle-Angriff ausgefü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 zu Verbundszenarien finden Sie unter "Verbund".

Speicherabbilder können Anspruchsinformationen anzeigen

Wenn eine Anwendung fehlschlägt, können Protokolldateien, z. B. von Dr. Watson, die Anspruchsinformationen enthalten. Diese Informationen sollten nicht in andere Entitäten exportiert werden, z. B. Supportteams; andernfalls werden auch die Anspruchsinformationen exportiert, die private Daten enthalten. Sie können dies vermeiden, indem Sie die Protokolldateien nicht an unbekannte Entitäten senden.

Endpunktadressen

Eine Endpunktadresse enthält die informationen, die für die Kommunikation mit einem Endpunkt erforderlich sind. SOAP-Sicherheit muss die Adresse vollständig in den ausgetauschten Sicherheitsverhandlungsnachrichten enthalten, um einen symmetrischen Schlüssel zwischen einem Client und einem Server auszuhandeln. Da es sich bei der Sicherheitsverhandlung um einen Bootstrapprozess handelt, können die Adressheader während dieses Prozesses nicht verschlüsselt werden. Daher sollte die Adresse keine vertraulichen Daten enthalten; andernfalls führt sie zu Angriffen auf die Offenlegung von Informationen.

Zertifikate unverschlüsselt übertragen

Wenn Sie ein X.509-Zertifikat zur Authentifizierung eines Clients verwenden, wird das Zertifikat im Klartext im SOAP-Header übertragen. Seien Sie sich dessen als potenzielle Offenlegung personenbezogener Daten (PII) bewusst. Dies ist kein Problem für den TransportWithMessageCredential-Modus, bei dem die gesamte Nachricht mit Transportsicherheit verschlüsselt wird.

Dienstverweise

Ein Dienstverweis ist ein Verweis auf einen anderen Dienst. Beispielsweise kann ein Dienst im Verlauf eines Vorgangs einen Dienstverweis an einen Client übergeben. Der Dienstverweis wird auch mit einem Vertrauensidentitätsüberprüfer verwendet, einer internen Komponente, die die Identität des Zielprinzipals überprüft, bevor Informationen wie Anwendungsdaten oder Anmeldeinformationen für das Ziel offenlegt werden. Wenn die Remotevertrauensidentität nicht überprüft oder falsch ist, sollte der Absender sicherstellen, dass keine Daten offengelegt wurden, die sich selbst, die Anwendung oder der Benutzer kompromittieren könnten.

Maßnahmen zur Risikominderung umfassen Folgendes:

  • Dienstverweise werden als vertrauenswürdig angenommen. Falls Sie Dienstverweisinstanzen übertragen, sollten Sie daher sicherstellen, dass diese nicht manipuliert wurden.

  • Einige Anwendungen können eine Benutzererfahrung darstellen, die den interaktiven Aufbau von Vertrauen basierend auf Daten in der Dienstreferenz und vertrauenswürdigen Daten ermöglicht, die vom Remotehost bestätigt wurden. WCF stellt Erweiterungspunkte für eine solche Einrichtung bereit, aber der Benutzer muss sie implementiert haben.

NTLM

Standardmäßig verwendet die Windows-Authentifizierung in der Windows-Domänenumgebung das Kerberos-Protokoll, um Benutzer zu authentifizieren und zu autorisieren. Wenn das Kerberos-Protokoll aus irgendeinem Grund nicht verwendet werden kann, wird NT LAN Manager (NTLM) als Fallback verwendet. Sie können dieses Verhalten deaktivieren, indem Sie die Eigenschaft AllowNtlm auf false setzen. Probleme, die beim Zulassen von NTLM zu beachten sind:

  • NTLM macht den Clientbenutzernamen verfügbar. Wenn der Benutzername vertraulich gehalten werden muss, legen Sie die AllowNTLM Eigenschaft für die Bindung auf false.

  • NTLM stellt keine Serverauthentifizierung bereit. Daher kann der Client nicht sicherstellen, dass er mit dem richtigen Dienst kommuniziert, wenn Sie NTLM als Authentifizierungsprotokoll verwenden.

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 möglicherweise Informationen offengelegt werden.

Beispielsweise ist es möglich, Windows-Clientanmeldeinformationen ohne Domänennamen anzugeben, wie im folgenden Visual C#-Code dargestellt.

MyChannelFactory.Credentials.Windows.ClientCredential = new System.Net.NetworkCredential("username", "password");

Der Code gibt keinen Domänennamen an, daher wird NTLM verwendet.

Wenn die Domäne angegeben ist, aber ein ungültiger Dienstprinzipalname mithilfe des Endpunktidentitätsfeatures angegeben wird, wird NTLM verwendet. Weitere Informationen zur Angabe der Endpunktidentität finden Sie unter Dienstidentität und Authentifizierung.

Siehe auch