Überlegungen zur WinHTTP-Sicherheit
Die folgenden Sicherheitsüberlegungen 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, was darauf hinweist, dass sich das Zertifikat nicht geändert hat, wird das Zertifikat weiterhin erneut überprüft. Daher wird jede Änderung der Validierungskriterien über die Flags protokoll, revocation-check oder 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. Ebenso 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 der automatischen Proxyermittlung umfasst die Erkennung über DHCP oder DNS, das Herunterladen und Ausführen von Proxyskripts wie Java-Skripts. Um ein höheres Maß an Sicherheit zu erreichen, muss eine Anwendung die Übergabe des WINHTTP _ AUTOPROXY _ RUN _ INPROCESS-Flags vermeiden, damit 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 werden kann. Wenn Sie der Meinung sind, dass dieses Fallbackverhalten ein unzulässiges Risiko darstellt, deaktivieren Sie das Fallbackverhalten mit dem WINHTTP _ AUTOPROXY _ RUN _ OUTPROCESS _ ONLY-Flag.
- WINHTTP _ STATUS _ CALLBACK-Funktionen müssen sofort zurückgegeben werden. Wenn Sie eine dieser Rückruffunktionen schreiben, achten Sie darauf, dass sie nicht blockiert wird. Beispielsweise sollte weder der Rückruf noch eine funktion, die aufgerufen wird, ein Benutzerdialogfeld anzeigen oder auf ein Ereignis warten. Wenn eine WINHTTP _ STATUS _ CALLBACK-Funktion blockiert wird, wirkt sie sich auf die interne Planung von WinHTTP aus und bewirkt, dass andere Anforderungen innerhalb desselben Prozesses den Dienst verweigert werden.
- WINHTTP _ STATUS _ CALLBACK-Funktionen müssen reentrant sein. Vermeiden Sie beim Schreiben eines Rückrufs statische Variablen oder andere Konstrukte, die unter reentrance unsicher sind, und vermeiden Sie das Aufrufen anderer Funktionen, die nicht wiedererfüllt sind.
- Wenn ein asynchroner Vorgang möglich ist, übergeben Sie NULLs für OUT-Parameter. Wenn Sie den 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 WinHttpReadDataoder lpdwBytesWritten für WinHttpWriteData. Unter bestimmten Umständen wird der aufrufende Thread beendet, bevor der Vorgang abgeschlossen wird. Wenn die OUT-Parameter nicht NULL sind, kann die Funktion am Ende in den Arbeitsspeicher schreiben, der bereits freigegeben wurde.
- Die Passport-Authentifizierung ist nicht lösbar. Jedes cookiebasierte Authentifizierungsschema ist anfällig für Angriffe. Passport Version 1.4 ist cookiebasiert und unterliegt daher den Sicherheitsrisiken, die einem Cookie oder formularbasierten Authentifizierungsschema zugeordnet sind. Die Passport-Unterstützung ist in WinHTTP standardmäßig deaktiviert. sie kann mit WinHttpSetOptionaktiviert 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 für die Authentifizierung bei einer beliebigen Website verwendet werden. Es ist jedoch nicht sinnvoll, sich bei Websites zu authentifizieren, denen Sie nicht vertrauen.
- SSL 2.0-Verbindungen werden nur verwendet, wenn sie explizit aktiviert sind. Die Sicherheitsprotokolle TLS 1.0 und SSL 3.0 gelten als sicherer als SSL 2.0. Standardmäßig fordert WinHTTP TLS 1.0 oder SSL 3.0 an, wenn eine SSL-Verbindung und nicht SSL 2.0 ausgehandelt wird. Die SSL 2.0-Unterstützung in WinHTTP kann nur durch Aufrufen von WinHttpSetOptionaktiviert werden.
- Die Zertifikatsperrüberprüfung muss explizit angefordert werden. Bei der Zertifikatauthentifizierung überprüft WinHTTP standardmäßig nicht, ob das Zertifikat des Servers widerrufen wurde. Die Zertifikatsperrüberprüfung kann mit WinHttpSetOptionaktiviert werden.
- Anwendungen müssen sicherstellen, dass eine Sitzung einer einzelnen Identität zugeordnet wird. Eine WinHTTP-Sitzung sollte nur einer Identität zugeordnet werden. Das heißt, eine WinHTTP-Sitzung wird verwendet, 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 für ein WinHTTP-Anforderungshandle sollten synchronisiert werden. Beispielsweise sollte eine Anwendung vermeiden, ein Anforderungshandle für einen Thread zu schließen, während ein anderer Thread eine Anforderung sendet oder empfängt. Schließen Sie das Anforderungshandle während einer Rückrufbenachrichtigung, um eine asynchrone Anforderung zu beenden. Um eine synchrone Anforderung zu beenden, schließen Sie das Handle, wenn der vorherige WinHTTP-Aufruf zurückgegeben wird.
- Ablaufverfolgungsdateien enthalten vertrauliche Informationen. Ablaufverfolgungsdateien werden mithilfe Access-Control Listen (ACLs) geschützt, sodass normalerweise nur der lokale Administrator oder das Benutzerkonto darauf zugreifen kann, das sie erstellt hat. Vermeiden Sie die Gefährdung von Ablaufverfolgungsdateien durch nicht autorisierten Zugriff.
- Vermeiden Sie die Übergabe vertraulicher Daten über WinHttpSetOption. Geben Sie winHttpSetOption keinen Benutzernamen, kein Kennwort oder andere Anmeldeinformationen an, da Sie keine Kontrolle über das verwendete Authentifizierungsschema haben und die sensiblen 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 wird die Umleitung (eine 302-Nachricht) automatisch auch für einen POST-Auftrag ausgeführt. Um die Möglichkeit von falschen Umleitungen zu vermeiden, sollten Anwendungen die automatische Umleitung deaktivieren oder die Richtungsumleitung in Rückrufen überwachen, wenn vertrauliche Informationen veröffentlicht werden.
- Benutzerdefinierte Header werden unverändert über Umleitungen übertragen. Benutzerdefinierte Header, z. B. mit WinHTTPAddRequestHeaders hinzugefügte Cookies, werden ohne Änderungen über Umleitungen übertragen, während von WinHTTP generierte Header automatisch aktualisiert werden. Wenn die Übertragung eines benutzerdefinierten Headers über Umleitungen ein Sicherheitsrisiko darstellt, verwenden Sie den WINHTTP _ STATUS _ CALLBACK-Rückruf mit der VERvollständigung WINHTTP _ CALLBACK _ STATUS _ REDIRECT, um den betreffenden Header bei jeder Umleitung zu ändern.
- WinHTTP ist im synchronen Modus nicht wiedererfüllt. Da WinHTTP im synchronen Modus nicht wiedererfüllt wird, planen Sie keine asynchronen Prozeduraufrufe (APC), die WinHTTP in einem Anwendungsthread aufrufen können, der innerhalb einer WinHTTP-Funktion ausgeführt wird. Im synchronen Modus führt WinHTTP einen "warnungsfähigen Wartezustand" aus, und wenn der wartende Thread für die Ausführung eines APC vorab aufgefordert wird und später erneut in WinHTTP eintritt, kann der interne WinHTTP-Zustand beschädigt sein.