Erhöhung von Rechten
Eine Erhöhung von Rechten ergibt sich daraus, dass einem Angreifer umfangreichere Zugangsberechtigungen als die ihm ursprünglich gewährten Berechtigungen eingeräumt werden. Dies ist zum Beispiel der Fall, wenn einem Angreifer mit einem Berechtigungssatz von "Nur-Lesen"-Berechtigungen es irgendwie gelingt, "Lesen-und-Schreiben"-Berechtigungen in seinen Berechtigungssatz aufzunehmen.
Vertrauenswürdige STS sollten SAML-Tokenansprüche signieren
Ein SAML (Security Assertions Markup Language)-Token ist ein generisches XML-Token, das den Standardtyp für ausgestellte Token darstellt. SAML-Token können von einem Sicherheitstokendienst (Security Token Service, STS) erstellt werden, der für den empfangenden Webdienst in einem typischen Datenaustausch als vertrauenswürdig gilt. SAML-Token enthalten Ansprüche in Form von Anweisungen. Ein Angreifer kann die Ansprüche aus einem gültigen Token kopieren, ein neues SAML-Token erstellen und mit einem anderen Aussteller signieren. Das Ziel ist hierbei, festzustellen, ob der Server Aussteller validiert, und wenn nicht, diese Schwäche zum Erstellen von SAML-Token auszunutzen, die Berechtigungen über die von einem vertrauenswürdigen STS beabsichtigten hinaus gewähren.
Die SamlAssertion-Klasse überprüft die digitale Signatur, die in einem SAML-Token enthalten ist, und der Standard-SamlSecurityTokenAuthenticator erfordert, dass SAML-Token mit einem X.509-Zertifikat signiert sind, das gültig ist, wenn CertificateValidationMode der IssuedTokenServiceCredential-Klasse auf ChainTrust festgelegt ist. Mithilfe des ChainTrust-Modus allein kann nicht bestimmt werden, ob der Aussteller des SAML-Tokens vertrauenswürdig ist. Dienste, die ein stärker granuliertes Vertrauenswürdigkeitsmodell erfordern, können entweder mithilfe von Autorisierungs- oder Durchsetzungsrichtlinien den Aussteller der erzeugten Anspruchssätze durch die Authentifizierung der Token überprüfen oder die X.509-Validierungseinstellungen für IssuedTokenServiceCredential verwenden, um den Satz zulässiger Signaturzertifikate einzuschränken. Weitere Informationen finden Sie unter Verwalten von Ansprüchen und Autorisierung mit dem Identitätsmodell und Verbund und ausgestellte Token.
Wechseln der Identität ohne Sicherheitskontext
Das Folgende gilt nur für WinFX.
Wenn eine Verbindung zwischen einem Client und einem Server hergestellt wird, ändert sich die Identität des Clients nur in einem Fall, nämlich wenn nach dem Öffnen des WCF-Clients alle folgenden Bedingungen erfüllt sind:
Die Verfahren zur Einrichtung eines Sicherheitskontexts (mithilfe einer Transport- oder Nachrichtensicherheitssitzung) werden deaktiviert (die Eigenschaft EstablishSecurityContext wird auf
falsefestgelegt, wenn Nachrichtensicherheit verwendet wird oder wenn Transportsicherheit verwendet wird und der betreffende Transport keine Sicherheitssitzungen einrichten kann. HTTPS ist ein Beispiel für einen solchen Transport).Sie verwenden die Windows-Authentifizierung.
Sie legen die Anmeldeinformationen nicht explizit fest.
Sie rufen den Dienst unter dem Identitätswechsel-Sicherheitskontext auf.
Wenn diese Bedingungen erfüllt sind, kann sich die zur Authentifizierung des Clients beim Dienst verwendete Identität ändern (möglicherweise wird nicht die angenommene Identität, sondern die Prozessidentität verwendet), nachdem der WCF-Client geöffnet wurde. Dies geschieht, weil die Windows-Anmeldeinformationen, mit denen der Client für den Dienst authentifiziert wird, mit jeder Nachricht übermittelt werden, und die zur Authentifizierung verwendeten Anmeldeinformationen von der Windows-Identität des aktuellen Threads bezogen werden. Wenn sich die Windows-Identität des aktuellen Threads ändert (beispielsweise durch einen Identitätswechsel, mit dem ein anderer Aufrufer imitiert wird), dann können sich auch die Anmeldeinformationen ändern, die an die Nachricht angefügt sind und die zur Authentifizierung des Clients gegenüber dem Dienst verwendet werden.
Wenn das Verhalten beim Einsatz der Windows-Authentifizierung in Verbindung mit dem Identitätswechsel deterministisch sein soll, müssen Sie die Windows-Anmeldeinformationen explizit festlegen, oder Sie müssen einen Sicherheitskontext für den Dienst einrichten. Hierzu verwenden Sie eine Nachrichtensicherheitssitzung oder eine Transportsicherheitssitzung. Zum Beispiel kann der net.tcp-Transport eine Transportsicherheitssitzung bereitstellen. Darüber hinaus dürfen Sie in Aufrufen des Diensts nur die synchrone Version von Clientvorgängen verwenden. Wenn Sie einen Nachrichtensicherheitskontext einrichten, sollten Sie die Verbindung mit dem Dienst nicht länger als den für die Sitzung konfigurierten Erneuerungszeitraum geöffnet halten, weil sich die Identität auch während des Sitzungserneuerungsprozesses ändern kann.
Aufzeichnung der Anmeldeinformationen
Das Folgende gilt für .NET Framework 3.5 und nachfolgende Versionen.
Die vom Client oder Dienst verwendeten Anmeldeinformationen basieren auf dem aktuellen Kontextthread. Die Anmeldeinformationen werden durch einen Aufruf der Open-Methode (bzw. BeginOpen für asynchrone Aufrufe) des Clients oder Diensts bezogen. Sowohl für die ServiceHost-Klasse als auch für die ClientBase<TChannel>-Klasse gilt, dass die Open-Methode bzw. die BeginOpen-Methode von der Open-Methode bzw. der BeginOpen-Methode der CommunicationObject-Klasse abgeleitet ist.
Hinweis
Bei Verwendung der BeginOpen-Methode kann nicht garantiert werden, dass es sich bei den aufgezeichneten Anmeldeinformationen um die Anmeldeinformationen des Prozesses handelt, von dem die Methode aufgerufen wird.
Tokenzwischenspeicher ermöglichen Wiederholungen mit veralteten Daten
WCF verwendet die Funktion LogonUser der lokalen Sicherheitsautorität (LSA), um Benutzer anhand des Benutzernamens und Kennworts zu authentifizieren. Weil die Anmeldefunktion ein kostspieliger Vorgang ist, können Sie mit WCF Token zwischenspeichern, die authentifizierte Benutzer darstellen, um die Leistung zu erhöhen. Mit dem Zwischenspeichermechanismus werden die Ergebnisse von LogonUser für die spätere Verwendung gespeichert. Dieser Mechanismus ist standardmäßig deaktiviert. Legen Sie zu seiner Aktivierung die Eigenschaft CacheLogonTokens auf true fest, oder Sie verwenden das Attribut cacheLogonTokens der <userNameAuthentication>.
Sie können eine Gültigkeitsdauer (Time to Live, TTL) für die zwischengespeicherten Token festlegen, indem Sie CachedLogonTokenLifetime-Eigenschaft auf eine TimeSpan-Zeitspanne festlegen oder das cachedLogonTokenLifetime-Attribut des userNameAuthentication-Elements verwenden. Der Standardwert beträgt 15 Minuten. Beachten Sie Folgendes: Solange ein Token zwischengespeichert ist, kann jeder Client, der den gleichen Benutzernamen und das gleiche Kennwort angibt, das Token nutzen, auch wenn das betreffende Benutzerkonto in Windows gelöscht oder dessen Kennwort geändert wurde. Bis die Gültigkeitsdauer abgelaufen ist und das Token aus dem Zwischenspeicher entfernt wurde, lässt WCF die Authentifizierung des (möglicherweise böswilligen) Benutzers zu.
So lässt sich dieses Problem abschwächen: Verkleinern Sie die Angriffsfläche, indem Sie den cachedLogonTokenLifetime-Wert auf die kürzeste Zeitspanne festlegen, die von den Benutzern benötigt wird.
Ausgestellte Tokenautorisierung: Ablaufzeit auf großem Wert zurückgesetzt
Unter bestimmten Bedingungen kann die ExpirationTime-Eigenschaft des AuthorizationContext-Objekts auf einen unerwartet großen Wert (z. B. der Wert des MaxValue-Felds minus einem Tag oder der 20. Dezember 9999) festgelegt werden.
Dieser Fall tritt ein, wenn WSFederationHttpBinding und eine der vom System bereitgestellten Bindungen verwendet werden, für die ausgestellte Token als Clientanmeldeinformationen zulässig sind.
Dieser Fall tritt auch ein, wenn Sie mit einer der folgenden Methoden benutzerdefinierte Bindungen erstellen:
Um dem entgegenzuwirken, muss die Autorisierungsrichtlinie die Aktion und Gültigkeitsdauer jeder Autorisierungsrichtlinie überprüfen.
Der Dienst verwendet ein anderes Zertifikat, als das vom Client beabsichtigte
Unter bestimmten Umständen kann ein Client eine Nachricht mit einem X.509-Zertifikat signieren und den Dienst ein anderes als das vorgesehene Zertifikat abrufen lassen.
Dieser Fall kann unter den folgenden Umständen eintreten:
Der Client signiert eine Nachricht mit einem X.509-Zertifikat und fügt das X.509-Zertifikat nicht an die Nachricht an, sondern verweist über dessen Subjektschlüsselbezeichner darauf.
Auf dem Computer, auf dem der Dienst ausgeführt wird, sind zwei oder mehr Zertifikate mit dem gleichen öffentlichen Schlüssel vorhanden, die jedoch unterschiedliche Daten enthalten.
Der Dienst ruft ein Zertifikat ab, das zwar den gleichen Subjektschlüsselbezeichner aufweist, aber nicht das vom Client für die Verwendung vorgesehene Zertifikat ist. Wenn WCF die Nachricht empfängt und die Signatur verifiziert, ordnet es die im unbeabsichtigten X.509-Zertifikat enthaltenen Informationen einem Satz von Ansprüchen zu, der sich von dem vom Client erwarteten Satz unterscheidet und möglicherweise umfangreicher ist.
Um dieses Problem zu entschärfen, verweisen Sie auf eine andere Art auf das X.509-Zertifikat, z. B. mithilfe von IssuerSerial.