10. Sicherheitsüberlegungen
10.1. Server-Autorität
HTTP/2 stützt sich auf die HTTP/1.1-Definition von Autorität, um zu bestimmen, ob ein Server autorisiert ist, eine bestimmte Antwort bereitzustellen (siehe Abschnitt 17.1 von [HTTP]). Dies basiert auf lokaler Namensauflösung für das "https"-Schema und der authentifizierten Server-Identität für das "https"-Schema (wie in Abschnitt 4.2.2 von [HTTP] definiert). Alternative Dienste ([ALT-SVC]), die zur Feststellung der Autorität verwendet werden, können erhebliche zusätzliche Komplexität einführen.
10.2. Protokollübergreifende Angriffe
Bei TLS verwendet HTTP/2 die Application-Layer Protocol Negotiation (ALPN)-Erweiterung [TLS-ALPN], um die Verwendung des Protokolls auszuhandeln. Dies erzeugt ein positives Signal, dass der Server HTTP/2 unterstützt und reduziert die Exposition von HTTP/2 gegenüber protokollübergreifenden Angriffen.
Im Klartext oder wenn ALPN nicht in TLS verwendet wird, könnte das HTTP/2-Client-Verbindungs-Präfix (Abschnitt 3.4) jedoch mit anderen Protokollen verwechselt werden. Das HTTP/2-Verbindungs-Präfix ist so konzipiert, dass diese Möglichkeit minimiert wird, indem eine Sequenz ausgewählt wird, die wahrscheinlich kein gültiger Start für andere Protokolle ist.
Jedes Protokoll, das für einen HTTP/2-Endpunkt zugänglich ist, kann verwendet werden, um eine scheinbar gültige HTTP/2-Verbindung herzustellen. Aus diesem Grund muss das Verbindungs-Präfix, das von einem serverseitigen Endpunkt empfangen wird, gültig sein, damit das Protokoll einen protokollübergreifenden Angriff bildet.
Das Client-Verbindungs-Präfix (Abschnitt 3.4) reicht nicht aus, um sicherzustellen, dass das Protokoll nicht verwechselt wird, bietet aber einen gewissen Schutz. HTTP/2-Client-Implementierungen müssen möglicherweise zusätzliche Prüfungen durchführen, bevor sie HTTP-Semantik anwenden. Insbesondere müssen Clients sicherstellen, dass die anfängliche Antwort eine legitime Antwort auf eine vom Client gesendete Nachricht ist.
Ein Server könnte einen Client angreifen, indem er eine Anfrage an einen Zielserver sendet, die der Client an einen anderen Server senden wollte. Wenn der empfangende Server ein anderes HTTP-Schema als HTTP/2 unterstützt, kann der Server eine an einen anderen Server gesendete Anfrage lesen und wiederholen. Ein Angreifer kann die Antwort, die der Client erhält, abfangen und ändern, wodurch der Client Informationen in der Antwort mit einer Antwort auf eine Anfrage verknüpft, zu der sie nicht gehört.
10.3. Intermediary Encapsulation Attacks
Die HTTP/2-Feldkodierung ermöglicht den Ausdruck von Feldnamen und -werten, die keine gültigen Feldnamen und -werte in HTTP/1.1 sind oder die in HTTP/1.1 nicht ausgedrückt werden können. Anfragen oder Antworten, die ungültige Feldnamen oder -werte enthalten, machen Implementierungen anfällig, die eine unzureichende Validierung von Feldnamen und -werten durchführen. Ein Angreifer könnte möglicherweise einen Intermediär verwenden, um eine Anfrage oder Antwort so zu kapseln, dass eine ungültige Nachricht gültig erscheint.
Ein HTTP/2-zu-HTTP/1.1-Translator, der Anfragen und Antworten nicht vollständig validiert, könnte es einem böswilligen Client ermöglichen, Feldwerte einzuschleusen oder Felder mit irreführenden Feldnamen zu erstellen.
10.4. Zwischenspeicherbarkeit von Push-Antworten
Push-Antworten haben keine explizite Anfrage von einem Client; die Anfrage wird vom Server in einem PUSH_PROMISE-Frame bereitgestellt.
Das Zwischenspeichern von Push-Antworten kann problematisch sein. Abhängig von den zur Herstellung der Verbindung verwendeten Informationen könnte eine Push-Antwort versehentlich einem neuen Client zur Verfügung gestellt werden, der die Verbindung teilt, aber unbeabsichtigt die Ressource angefordert hat.
Beispielsweise könnte bei der Verwendung von TLS zur Authentifizierung ein böswilliger Client eine Push-Antwort über sensible Informationen eines authentifizierten Benutzers erhalten, der dieselbe Verbindung verwendet.
Server MÜSSEN nur Werte einschließen, die in Anfragen zwischenspeicherbar sind, die gepusht werden (siehe Abschnitt 9.2.3 von [HTTP]); gepushte Anfragen enthalten keine Werte für Anfrageinhalte. Push-Antworten werden als nicht zwischenspeicherbar markiert, indem ein Cache-Control-Header-Feld mit der no-cache- oder private-Cache-Response-Direktive eingefügt wird (siehe Abschnitt 5.2.2.4 von [HTTP-CACHING]).
Wenn dieselbe gepushte Antwort für Antworten bereitgestellt werden kann, die sowohl zwischenspeicherbar als auch nicht zwischenspeicherbar sind, könnten Clients die gepushte Antwort fälschlicherweise unter Verwendung der zwischenspeicherbaren Antwort zwischenspeichern.
Daher SOLLTEN Server ein Cache-Control-Header-Feld mit dem Wert "no-cache" im HEADERS-Frame eines gepushten Streams einfügen, es sei denn, es gibt ein explizites Signal, dass der Client die Antwort zwischenspeichert.
10.5. Überlegungen zu Denial-of-Service
Die Verwendung von HTTP/2 führt zu mehreren neuen Denial-of-Service (DoS)-Möglichkeiten.
10.5.1. Grenzen für Feldsektionsgröße
Eine Feldsektion, die eine große Anzahl von Feldern oder lange Feldnamen oder -werte enthält, kann dazu führen, dass eine Implementierung übermäßige Mengen an Speicher, CPU-Zeit oder beides verbraucht.
Implementierungen SOLLTEN Grenzen für die Gesamtzahl und Größe der Feldzeilen festlegen, die sie akzeptieren, und für die Gesamtzahl und Größe, die sie senden, wodurch die Gesamtgröße der Frames begrenzt wird, die eine Feldsektion umfassen. Server möchten möglicherweise eine Whitelist von Feldzeilen führen, und Clients möchten möglicherweise Feldzeilen ablehnen, aber beide SOLLTEN Grenzen protokollieren und berücksichtigen, die die Interoperabilität behindern könnten.
10.5.2. CONNECT-Probleme
Die CONNECT-Methode kann verwendet werden, um eine Verbindung zu nicht vertrauenswürdigen Zielen herzustellen. Die TCP-Verbindung für CONNECT unterliegt keiner Kontrolle und könnte versuchen, sich mit Endpunkten oder anderen Geräten zu verbinden, wodurch eine Verbindungsflut entsteht. Implementierungen SOLLTEN Grenzen für die Ziele festlegen, die als CONNECT-Ziele zulässig sind, und SOLLTEN diese Grenzen protokollieren.
10.5.3. Verwendung von Komprimierung
Die Komprimierung von Feldblöcken in HTTP/2 basiert auf Algorithmen und Zuständen, die von einem Angreifer verwendet werden können, um Denial-of-Service zu verursachen.
Ein Angreifer kann Anfragen mit sorgfältig gestalteten Feldern senden, um eine Feldsektion zu erstellen, die große Mengen an Decoder-Ressourcen erfordert. Dies kann durch die Verwendung großer Mengen Huffman-codierter Zeichenfolgen oder durch viele Aktualisierungen der dynamischen Tabelle erfolgen. Das sofortige Starten einer neuen Feldsektion nach Beendigung einer (z. B. leere DATA-Frames gefolgt von einem HEADERS-Frame) könnte auch verwendet werden, um verfügbare Decoder-Ressourcen zu begrenzen.
Ähnliche Angriffe können gesendet werden, um den Feldsektions-Komprimierungsstatus aggressiv zu nutzen, um Antworten zu erstellen, die große Mengen an Encoder-Ressourcen erfordern.
Implementierungen SOLLTEN Grenzen für die Größe der Felder festlegen, die sie dekomprimieren.
10.5.4. Verwendung von Flusskontrolle
Die Flusskontrolle in HTTP/2 ermöglicht es einem Gegner, die Datenmenge zu begrenzen, die ein Peer senden kann. Die Implementierung von Fensteraktualisierungen oder die Verwaltung von Flusskontrollfenstern könnte dazu führen, dass Streams kein verfügbares Fenster erhalten, wodurch der Stream keinen Fortschritt machen kann.
10.5.5. Verwendung von Einstellungen
Ein SETTINGS-Frame kann verwendet werden, um einen Peer zu veranlassen, zusätzliche Verarbeitungszeit aufzuwenden. Dies kann durch sinnloses Ändern von Einstellungen, Senden von SETTINGS-Frames ohne Änderung von Einstellungen oder häufiges Ändern von Einstellungen erfolgen.
Andere SETTINGS-Parameter, die Werte begrenzen, könnten verwendet werden, um Ressourcen zu verbrauchen, wie z. B. das Deaktivieren der dynamischen HPACK-Tabelle durch Festlegen eines sehr kleinen Werts für den SETTINGS_HEADER_TABLE_SIZE-Parameter.
Endpunkte SOLLTEN diese Verhaltensweisen erkennen und sie als Verbindungsfehler (Abschnitt 5.4.1) vom Typ ENHANCE_YOUR_CALM behandeln.
10.5.6. Verwendung von Prioritäten
Prioritäten können verwendet werden, um einen Peer zu veranlassen, übermäßige Ressourcen aufzuwenden. Häufige Änderungen am Prioritätsbaum oder unangemessene Komplexität in Prioritätsbäumen können beide zu übermäßigem CPU-Verbrauch führen.
10.5.7. Verwendung von HTTP/2 ohne TLS
HTTP/2 kann ohne Verwendung von TLS bereitgestellt werden. Dieser Modus hat die gleichen Schwachstellen für bestimmte Angriffe wie HTTP/1.1. Implementierungen, die diesen Betriebsmodus verwenden, SOLLTEN auf HTTP/1.1 anwendbare Schutzmaßnahmen anwenden.
Implementierungen müssen sich auch bewusst sein, dass viele HTTP/2-Funktionen ohne TLS möglicherweise anfälliger für Angriffe sind. Insbesondere bedeutet das Fehlen von Vertraulichkeitsschutz und Integritätsschutz durch TLS, dass Verschlüsselung oder Integrität der Daten gefährdet ist.
10.6. Verwendung von Komprimierung
Komprimierung kann es einem Angreifer ermöglichen, geheime Inhalte verschlüsselter Kommunikation wiederherzustellen, wenn diese Komprimierung mit Daten kombiniert wird, die vom Angreifer kontrolliert werden, und mit geheimen Daten, deren Übertragungsgröße der Angreifer beobachten kann.
HTTP/2 bietet Komprimierung an mehreren Stellen: Feldblöcke verwenden HPACK [COMPRESSION], und der Inhalt von DATA-Frames kann Inhaltscodierung verwenden (siehe Abschnitt 8.4.1 von [HTTP]).
HPACK ist so konzipiert, dass die Ausnutzung der Offenlegung von Geheimnissen schwieriger wird; der Kompromiss zwischen Implementierungsoptionen oder Anwendungsschutz, der in einigen Fällen realisiert werden kann, ist jedoch unvollkommen. Angriffe können die Wiederverwendung des Feldkomprimierungszustands über mehrere Anfragen hinweg ausnutzen. Implementierungen und Anwendungen können wählen, die Menge des über Anfragen hinweg verwendeten Komprimierungszustands zu begrenzen, um den Schutz zu verbessern, jedoch auf Kosten einer Vergrößerung der Nachrichtengröße.
Das Komprimieren des Inhalts von DATA-Frames wird im Allgemeinen als sicherer angesehen, da der Inhalt von DATA-Frames weniger wahrscheinlich mit vom Angreifer kontrollierten Daten über mehrere Anfragen hinweg gemischt wird. Die Komprimierungsinhaltscodierung kombiniert jedoch Informationen aus verschiedenen Quellen. Obwohl die Verwendung einer anderen Ursprungskennung Informationen aus verschiedenen Quellen unterscheidet (siehe Abschnitt 11.5 von [HTTP]), kann die Komprimierung diese Trennzeichen entfernen, wie in [BREACH] beschrieben.
Das Deaktivieren oder Begrenzen der Komprimierung für Inhaltscodierung wird im Allgemeinen als ausreichend angesehen, um diese Angriffe zu mildern, aber dies ist möglicherweise nicht ausreichend, um alle Angriffe zu verhindern.
10.7. Verwendung von Padding
Padding kann verwendet werden, um die genaue Größe von Frame- und Nachrichteninhalten zu verschleiern. Padding kann verwendet werden, um Angriffe zu mildern, die darauf beruhen, Traffic-Analyse zu verwenden, um Informationen über Nachrichten abzuleiten, was für HTTP von besonderer Bedeutung ist, wo die Länge komprimierter Nachrichten Informationen über den von ihnen enthaltenen Inhalt preisgeben könnte.
Ein Beispiel für die Verwendung von Padding wäre das Senden einer großen Anzahl von HEADERS- und DATA-Frames mit Payload-Größen, die zwischen Frames variieren, um die genaue Größe einer Nachricht zu verschleiern. Die Verwendung von Padding kann einige Angriffe reduzieren (z. B. [BREACH]).
Im Allgemeinen bedeutet die Existenz von Traffic-Analyse-Angriffen, dass Padding auf eine feste Größe für jedes Feld oder jeden Frame nicht ausreicht, um Schutz zu bieten. Um effizient zu sein und ein gewisses Maß an Schutz zu bieten, SOLLTE Padding zufällig gewählt werden.
Padding ist kein perfekter Schutz zum Verschleiern der Nachrichtengröße. Ein Angreifer könnte möglicherweise statistische Eigenschaften über die Größe von Nachrichten verwenden, die es einem Angreifer ermöglichen könnten, die Länge von Nachrichten zu verwenden, ob mit Padding versehen oder nicht, um mit einer gewissen Wahrscheinlichkeit Informationen über den Inhalt abzuleiten.
10.8. Datenschutzüberlegungen
Mehrere Merkmale von HTTP/2 bieten einem Beobachter die Möglichkeit, eine Reihe von Anfragen zu korrelieren. Dazu gehören der Wert von Einstellungen, der Komprimierungskontext für Feldblöcke, die Verwaltung des Flusskontrollfensters und das Timing eintreffender Nachrichten.
Insbesondere HTTP-Felder, die Informationen über die Benutzeridentität enthalten, können mit anderen Kommunikationen korreliert werden, selbst wenn verschiedene Server verwendet werden.
HTTP/2 bietet keine spezifischen Mechanismen zum Schutz der Privatsphäre der Benutzer.
Kapitel 10 abgeschlossen!
Referenzen
- [HTTP] RFC 9110
- [HTTP-CACHING] RFC 9111
- [TLS-ALPN] RFC 7301
- [ALT-SVC] RFC 7838
- [COMPRESSION] RFC 7541
- [BREACH] "BREACH: Reviving the CRIME Attack"