Freigeben über


Überlegungen zur WinHTTP-Sicherheit

Die folgenden Sicherheitsaspekte gelten für Anwendungen, die WinHTTP verwenden:

  • Serverzertifikate werden nur einmal pro Sitzung überprüft. Nachdem ein Zertifikat überprüft wurde, bleibt es für die Dauer der aktuellen Sitzung gültig. Solange der Fingerabdruck des Zertifikats übereinstimmt (wodurch angegeben wird, dass das Zertifikat nicht geändert wurde), wird das Zertifikat weiterhin erneut überprüft. Daher werden Änderungen der Überprüfungskriterien durch das Protokoll, die Sperrüberprüfung oder das Flag „certificate-error-ignore“ nicht wirksam, sobald das Zertifikat überprüft wurde. Damit eine solche Änderung sofort wirksam wird, muss die aktuelle Sitzung beendet und eine neue gestartet werden. Entsprechend kann der Ablauf eines Zertifikats während einer Sitzung nur erkannt werden, wenn die Anwendung selbst den Zertifikatserver regelmäßig überprüft, um Ablaufdaten abzurufen.
  • Der automatische Proxy umfasst das Herunterladen und Ausführen von Skripts. Die Unterstützung für die automatische Proxyermittlung umfasst die Erkennung über DHCP oder DNS, das Herunterladen und das Ausführen von Proxyskripts wie Java-Skripts. Um ein höheres Maß an Sicherheit zu erreichen, darf eine Anwendung das Flag WINHTTP_AUTOPROXY_RUN_INPROCESS nicht übergeben, sodass die automatische Proxyermittlung außerhalb des Prozesses initiiert wird. Selbst dann versucht WinHTTP standardmäßig, ein automatisches Proxyskript im Prozess auszuführen, wenn das Skript nicht ordnungsgemäß außerhalb des Prozesses ausgeführt wird. Wenn Sie der Meinung sind, dass dieses Fallbackverhalten ein inakzeptables Risiko darstellt, deaktivieren Sie das Fallbackverhalten mit dem Flag WINHTTP_AUTOPROXY_RUN_OUTPROCESS_ONLY.
  • Funktionen vom Typ „WINHTTP_STATUS_CALLBACK“ müssen umgehend zurückgegeben werden. Achten Sie beim Schreiben einer dieser Rückruffunktionen darauf, dass sie nicht blockiert. Beispielsweise sollte weder der Rückruf noch jede damit aufgerufene Funktion ein Benutzerdialogfeld anzeigen oder auf ein Ereignis warten. Wenn eine WINHTTP_STATUS_CALLBACK-Funktion blockiert, wirkt sich dies auf die interne Planung von WinHTTP aus und bewirkt, dass andere Anforderungen innerhalb desselben Prozesses verweigert werden.
  • Funktionen vom Typ „WINHTTP_STATUS_CALLBACK“ müssen eintrittsinvariant sein. Vermeiden Sie beim Schreiben eines Rückrufs statische Variablen oder andere Konstrukte, die bei Eintrittsinvarianz nicht sicher sind, und vermeiden Sie das Aufrufen anderer Funktionen, die nicht eintrittsinvariant sind.
  • Wenn ein asynchroner Vorgang möglich ist, übergeben Sie NULL-Werte für OUT-Parameter. Wenn Sie einen asynchronen Vorgang durch Registrieren einer Rückruffunktion aktiviert haben, übergeben Sie immer NULL-Werte für OUT-Parameter wie lpdwDataAvailable für WinHttpQueryDataAvailable, lpdwBytesRead für WinHttpReadData oder lpdwBytesWritten für WinHttpWriteData. Unter bestimmten Umständen wird der aufrufende Thread beendet, bevor der Vorgang abgeschlossen ist, und wenn die OUT-Parameter nicht NULL sind, kann die Funktion in Speicher schreiben, der bereits freigegeben wurde.
  • Die Passport-Authentifizierung ist nicht absolut sicher. Jedes cookiebasierte Authentifizierungsschema ist anfällig für Angriffe. Passport Version 1.4 ist cookiebasiert und unterliegt daher den Sicherheitsrisiken im Zusammenhang mit einem cookie- oder formularbasierten Authentifizierungsschema. Die Passport-Unterstützung ist in WinHTTP standardmäßig deaktiviert. Sie kann mit WinHttpSetOption aktiviert werden.
  • Die Standardauthentifizierung sollte nur über eine sichere Verbindung verwendet werden. Die Standardauthentifizierung, die den Benutzernamen und das Kennwort in Klartext sendet (siehe RFC 2617), sollte nur über verschlüsselte SSL- oder TLS-Verbindungen verwendet werden.
  • Das Festlegen der Richtlinie für die automatische Anmeldung auf „Niedrig“ kann ein Risiko darstellen. Wenn die Richtlinie für die automatische Anmeldung auf „Niedrig“ festgelegt ist, können die Anmeldeinformationen eines Benutzers zur Authentifizierung für jede Website verwendet werden. Es empfiehlt sich jedoch nicht, sich bei Websites zu authentifizieren, denen Sie nicht vertrauen.
  • SSL 2.0-Verbindungen werden nur verwendet, wenn sie explizit aktiviert sind. Die TLS 1.0- und SSL 3.0-Sicherheitsprotokolle gelten als sicherer als SSL 2.0. Standardmäßig erfordert WinHTTP TLS 1.0 oder SSL 3.0 beim Aushandeln einer SSL-Verbindung, nicht SSL 2.0. DIE SSL 2.0-Unterstützung in WinHTTP kann nur durch Aufrufen von WinHttpSetOption aktiviert werden.
  • Die Überprüfung der Zertifikatsperre muss explizit angefordert werden. Bei der Zertifikatauthentifizierung überprüft WinHTTP standardmäßig nicht, ob das Serverzertifikat widerrufen wurde. Die Überprüfung der Zertifikatsperre kann mit WinHttpSetOption aktiviert werden.
  • Anwendungen müssen sicherstellen, dass eine Sitzung einer einzelnen Identität zugeordnet ist. Eine WinHTTP-Sitzung sollte nur einer Identität zugeordnet werden. Das bedeutet, dass eine WinHTTP-Sitzung verwendet wird, um die Internetaktivität eines einzelnen authentifizierten Benutzers oder einer Gruppe anonymer Benutzer zu verwalten. Da WinHTTP diese Zuordnung jedoch nicht automatisch erzwingt, muss Ihre Anwendung Maßnahmen ergreifen, um sicherzustellen, dass nur eine einzelne Identität beteiligt ist.
  • Vorgänge in einem WinHTTP-Anforderungshandle sollten synchronisiert werden. Beispielsweise sollte eine Anwendung das Schließen eines Anforderungshandles in einem Thread vermeiden, während ein anderer Thread eine Anforderung sendet oder empfängt. Um eine asynchrone Anforderung zu beenden, schließen Sie den Anforderungshandle während einer Rückrufbenachrichtigung. Um eine synchrone Anforderung zu beenden, schließen Sie das Handle, wenn der vorherige WinHTTP-Aufruf zurückgegeben wird.
  • Ablaufverfolgungsdateien können vertrauliche Informationen enthalten. Ablaufverfolgungsdateien werden mithilfe von Zugriffssteuerungslisten (Access Control Lists, ACLs) geschützt, sodass darauf normalerweise nur vom lokalen Administrator oder von dem Benutzerkonto zugegriffen werden kann, das sie erstellt hat. Vermeiden Sie die Kompromittierung von Ablaufverfolgungsdateien durch unbefugten Zugriff.
  • Vermeiden Sie das Übergeben vertraulicher Daten über WinHttpSetOption. Geben Sie keinen Benutzernamen, kein Kennwort und keine anderen Anmeldeinformationen für WinHttpSetOption ein, da Sie keine Kontrolle über das verwendete Authentifizierungsschema haben, und die vertraulichen Daten unerwartet als Klartext gesendet werden könnten. Verwenden Sie WinHttpQueryAuthSchemes und WinHttpSetCredentials anstelle von WinHttpSetOption zum Festlegen von Anmeldeinformationen.
  • Die automatische Umleitung kann ein Sicherheitsrisiko darstellen. Standardmäßig erfolgt die Umleitung (eine 302-Meldung) auch bei einem POST-Vorgang automatisch. Um falsche Umleitungen zu vermeiden, sollten Anwendungen die automatische Umleitung deaktivieren oder die erneute Umleitung in Rückrufen überwachen, wenn vertrauliche Informationen gesendet werden.
  • Benutzerdefinierte Header werden bei Umleitungen unverändert übertragen. Benutzerdefinierte Header, z. B. Cookies, die mit WinHTTPAddRequestHeaders hinzugefügt wurden, werden bei Umleitungen ohne Änderung übertragen, während von WinHTTP generierte Header automatisch aktualisiert werden. Wenn die Übertragung eines benutzerdefinierten Headers über Umleitungen ein Sicherheitsrisiko darstellt, verwenden Sie den Rückruf WINHTTP_STATUS_CALLBACK mit der Vervollständigung WINHTTP_CALLBACK_STATUS_REDIRECT, um den betreffenden Header bei jeder Umleitung zu ändern.
  • WinHTTP ist im synchronen Modus nicht eintrittsinvariant. Da WinHTTP im synchronen Modus nicht eintrittsinvariant ist, planen Sie keine asynchronen Prozeduraufrufe (Asynchronous Procedure Calls, APC), die WinHTTP in einem Anwendungsthread aufrufen können, der in einer WinHTTP-Funktion ausgeführt wird. Im synchronen Modus führt WinHTTP eine „warnungsfähige Wartebedingung“ aus. Wenn der wartende Thread zum Ausführen eines APC vorzeitig abgebrochen wird und dann später erneut zu WinHTTP wechselt, kann der interne Zustand von WinHTTP beschädigt werden.