9. Sicherheitserwägungen
Dieser Abschnitt soll Entwickler, Informationsanbieter und Nutzer über bekannte Sicherheitserwägungen in Bezug auf HTTP-Nachrichtensyntax, Parsing und Routing informieren. Sicherheitserwägungen zu HTTP-Semantik und Payloads werden in [RFC7231] behandelt.
9.1. Etablierung von Authority
HTTP stützt sich auf den Begriff der maßgeblichen Antwort (authoritative response): eine Antwort, die von der innerhalb des Ziel-URI identifizierten Authority (oder in deren Auftrag) als die für diese Anfrage angemessenste Antwort bestimmt wurde, gegeben den Zustand der Zielressource zum Zeitpunkt der Erzeugung der Antwortnachricht. Eine Antwort von einer nicht maßgeblichen Quelle, etwa einem gemeinsam genutzten Cache, bereitzustellen, ist oft nützlich, um Leistung und Verfügbarkeit zu verbessern, aber nur in dem Maße, wie die Quelle vertrauenswürdig ist oder die nicht vertrauenswürdige Antwort sicher verwendet werden kann.
Leider kann die Etablierung von Authority schwierig sein. Phishing beispielsweise ist ein Angriff auf die Wahrnehmung von Authority durch den Nutzer, wobei diese Wahrnehmung durch die Präsentation ähnlichen Brandings im Hypertext irregeführt werden kann, möglicherweise unterstützt durch userinfo, das die Authority-Komponente verschleiert (siehe Abschnitt 2.7.1). User Agents können die Auswirkung von Phishing-Angriffen verringern, indem sie Nutzern ermöglichen, einen Ziel-URI vor einer Aktion leicht zu prüfen, indem sie userinfo, sofern vorhanden, deutlich hervorheben (oder ablehnen) und indem sie gespeicherte Anmeldeinformationen und Cookies nicht senden, wenn das verweisende Dokument aus einer unbekannten oder nicht vertrauenswürdigen Quelle stammt.
Wird ein registrierter Name in der Authority-Komponente verwendet, verlässt sich das "http"-URI-Schema (Abschnitt 2.7.1) auf den lokalen Namensauflösungsdienst des Nutzers, um zu bestimmen, wo maßgebliche Antworten zu finden sind. Dies bedeutet, dass jeder Angriff auf die Netzwerk-Hosttabelle, die zwischengespeicherten Namen oder die Namensauflösungsbibliotheken eines Nutzers zu einem Angriffsvektor auf die Etablierung von Authority wird. Ebenso könnte die Wahl des Servers für den Domain Name Service (DNS) durch den Nutzer und die Hierarchie der Server, von denen er Auflösungsergebnisse bezieht, die Authentizität von Adresszuordnungen beeinträchtigen; DNS Security Extensions (DNSSEC, [RFC4033]) sind eine Möglichkeit, die Authentizität zu verbessern.
Darüber hinaus ist nach dem Erhalt einer IP-Adresse die Etablierung von Authority für einen "http"-URI anfällig für Angriffe auf das Internet-Protocol-Routing.
Das "https"-Schema (Abschnitt 2.7.2) soll viele dieser potenziellen Angriffe auf die Etablierung von Authority verhindern (oder zumindest offenlegen), vorausgesetzt, die ausgehandelte TLS-Verbindung ist gesichert und der Client überprüft ordnungsgemäß, dass die Identität des kommunizierenden Servers mit der Authority-Komponente des Ziel-URI übereinstimmt (siehe [RFC2818]). Die korrekte Implementierung einer solchen Überprüfung kann schwierig sein (siehe [Georgiev]).
9.2. Risiken von Vermittlern
Von ihrer Natur her sind HTTP-Vermittler Man-in-the-Middle und stellen daher eine Gelegenheit für Man-in-the-Middle-Angriffe dar. Die Kompromittierung der Systeme, auf denen die Vermittler laufen, kann zu ernsthaften Sicherheits- und Datenschutzproblemen führen. Vermittler können Zugriff auf sicherheitsrelevante Informationen, persönliche Informationen über einzelne Nutzer und Organisationen sowie proprietäre Informationen haben, die Nutzern und Inhaltsanbietern gehören. Ein kompromittierter Vermittler oder ein Vermittler, der ohne Rücksicht auf Sicherheits- und Datenschutzerwägungen implementiert oder konfiguriert wurde, könnte für die Durchführung einer breiten Palette potenzieller Angriffe genutzt werden.
Vermittler, die einen gemeinsam genutzten Cache enthalten, sind besonders anfällig für Cache-Poisoning-Angriffe, wie in Abschnitt 8 von [RFC7234] beschrieben.
Implementierer müssen die Datenschutz- und Sicherheitsauswirkungen ihrer Design- und Codierungsentscheidungen sowie der Konfigurationsoptionen berücksichtigen, die sie Betreibern anbieten (insbesondere die Standardkonfiguration).
Nutzer müssen sich darüber im Klaren sein, dass Vermittler nicht vertrauenswürdiger sind als die Personen, die sie betreiben; HTTP selbst kann dieses Problem nicht lösen.
9.3. Angriffe über die Länge von Protokollelementen
Da HTTP größtenteils textuelle, zeichenbegrenzte Felder verwendet, sind Parser oft anfällig für Angriffe, die auf dem Senden sehr langer (oder sehr langsamer) Datenströme beruhen, insbesondere dort, wo eine Implementierung ein Protokollelement ohne vordefinierte Länge erwartet.
Zur Förderung der Interoperabilität werden spezifische Empfehlungen für Mindestgrößengrenzen für die Anfragezeile (Abschnitt 3.1.1) und Header-Felder (Abschnitt 3.2) gegeben. Dies sind Mindestempfehlungen, die so gewählt wurden, dass sie selbst von Implementierungen mit begrenzten Ressourcen unterstützt werden können; es wird erwartet, dass die meisten Implementierungen deutlich höhere Grenzen wählen.
Ein Server kann eine Nachricht ablehnen, die ein zu langes Anfrageziel (Abschnitt 6.5.12 von [RFC7231]) oder einen zu großen Anforderungs-Payload hat (Abschnitt 6.5.11 von [RFC7231]). Zusätzliche Statuscodes im Zusammenhang mit Kapazitätsgrenzen wurden durch Erweiterungen von HTTP [RFC6585] definiert.
Empfänger sollten sorgfältig begrenzen, in welchem Umfang sie andere Protokollelemente verarbeiten, darunter (aber nicht beschränkt auf) Anforderungsmethoden, Antwortstatusphrasen, Header-Feldnamen, numerische Werte und Body-Chunks. Die Unterlassung einer solchen Begrenzung kann zu Pufferüberläufen, Arithmetiküberläufen oder erhöhter Anfälligkeit für Denial-of-Service-Angriffe führen.
9.4. Response-Splitting
Response-Splitting (auch CRLF-Injection genannt) ist eine gängige Technik, die bei verschiedenen Angriffen auf die Webnutzung verwendet wird und die zeilenbasierte Natur des HTTP-Nachrichten-Framings sowie die geordnete Zuordnung von Anfragen zu Antworten auf persistenten Verbindungen [Klein] ausnutzt. Diese Technik kann besonders schädlich sein, wenn die Anfragen einen gemeinsam genutzten Cache passieren.
Response-Splitting nutzt eine Schwachstelle in Servern (üblicherweise innerhalb eines Anwendungsservers) aus, bei der ein Angreifer kodierte Daten innerhalb eines Parameters der Anfrage senden kann, die später dekodiert und innerhalb eines der Antwort-Header-Felder der Antwort wiedergegeben werden. Ist die dekodierte Zeichenfolge so gestaltet, dass sie aussieht, als hätte die Antwort geendet und eine nachfolgende Antwort begonnen, wurde die Antwort aufgeteilt und der Inhalt innerhalb der scheinbaren zweiten Antwort wird vom Angreifer kontrolliert. Der Angreifer kann dann eine beliebige andere Anfrage auf derselben persistenten Verbindung stellen und die Empfänger (einschließlich Vermittler) dazu bringen zu glauben, dass die zweite Hälfte der Aufteilung eine maßgebliche Antwort auf die zweite Anfrage ist.
Beispielsweise könnte ein Parameter innerhalb des Anfrageziels von einem Anwendungsserver gelesen und innerhalb einer Weiterleitung wiederverwendet werden, sodass derselbe Parameter im Header-Feld Location der Antwort wiedergegeben wird. Wird der Parameter von der Anwendung dekodiert und beim Einfügen in das Antwortfeld nicht ordnungsgemäß kodiert, kann der Angreifer kodierte CRLF-Oktette und anderen Inhalt senden, die die einzelne Antwort der Anwendung wie zwei oder mehr Antworten aussehen lassen.
Eine gängige Verteidigung gegen Response-Splitting besteht darin, Anfragen auf Daten zu filtern, die wie kodiertes CR und LF aussehen (z. B. "%0D" und "%0A"). Dies setzt jedoch voraus, dass der Anwendungsserver nur URI-Dekodierung durchführt und nicht obskurere Datentransformationen wie Zeichensatz-Transkodierung, XML-Entity-Übersetzung, Base64-Dekodierung, sprintf-Neuformatierung usw. Eine wirksamere Gegenmaßnahme besteht darin, zu verhindern, dass irgendetwas außer den Kernprotokollbibliotheken des Servers ein CR oder LF innerhalb des Header-Abschnitts sendet, was bedeutet, die Ausgabe von Header-Feldern auf APIs zu beschränken, die auf fehlerhafte Oktette filtern, und Anwendungsservern nicht zu erlauben, direkt in den Protokollstream zu schreiben.
9.5. Request-Smuggling
Request-Smuggling ([Linhart]) ist eine Technik, die Unterschiede beim Protokoll-Parsing zwischen verschiedenen Empfängern ausnutzt, um zusätzliche Anfragen (die sonst möglicherweise durch Richtlinien blockiert oder deaktiviert würden) innerhalb einer scheinbar harmlosen Anfrage zu verbergen. Wie Response-Splitting kann Request-Smuggling zu einer Vielzahl von Angriffen auf die HTTP-Nutzung führen.
Diese Spezifikation hat neue Anforderungen an das Parsing von Anfragen eingeführt, insbesondere hinsichtlich des Nachrichten-Framings in Abschnitt 3.3.3, um die Wirksamkeit von Request-Smuggling zu verringern.
9.6. Nachrichtenintegrität
HTTP definiert keinen spezifischen Mechanismus zur Gewährleistung der Nachrichtenintegrität und verlässt sich stattdessen auf die Fehlererkennungsfähigkeit der zugrunde liegenden Transportprotokolle und die Verwendung von längen- oder chunk-abgegrenztem Framing, um Vollständigkeit zu erkennen. Zusätzliche Integritätsmechanismen wie Hashfunktionen oder auf den Inhalt angewendete digitale Signaturen können über erweiterbare Metadaten-Header-Felder selektiv zu Nachrichten hinzugefügt werden. Historisch wurde das Fehlen eines einheitlichen Integritätsmechanismus durch die informelle Natur der meisten HTTP-Kommunikation gerechtfertigt. Die Verbreitung von HTTP als Informationszugriffsmechanismus hat jedoch zu seiner zunehmenden Nutzung in Umgebungen geführt, in denen die Überprüfung der Nachrichtenintegrität entscheidend ist.
User Agents werden ermutigt, konfigurierbare Mittel zum Erkennen und Melden von Fehlern der Nachrichtenintegrität zu implementieren, sodass diese Mittel in Umgebungen aktiviert werden können, in denen Integrität notwendig ist. Beispielsweise muss ein Browser, der zum Anzeigen von Krankengeschichten oder Informationen zu Arzneimittelwechselwirkungen verwendet wird, dem Nutzer anzeigen, wenn solche Informationen durch das Protokoll als unvollständig, abgelaufen oder während der Übertragung beschädigt erkannt werden. Solche Mechanismen könnten selektiv über User-Agent-Erweiterungen oder das Vorhandensein von Metadaten zur Nachrichtenintegrität in einer Antwort aktiviert werden. Mindestens sollten User Agents einen Hinweis bereitstellen, der es einem Nutzer ermöglicht, zwischen einer vollständigen und einer unvollständigen Antwortnachricht (Abschnitt 3.4) zu unterscheiden, wenn eine solche Überprüfung gewünscht wird.
9.7. Nachrichtenvertraulichkeit
HTTP verlässt sich auf zugrunde liegende Transportprotokolle, um Nachrichtenvertraulichkeit bereitzustellen, wenn diese gewünscht wird. HTTP wurde speziell so entworfen, dass es unabhängig vom Transportprotokoll ist, sodass es über viele verschiedene Formen verschlüsselter Verbindungen verwendet werden kann, wobei die Auswahl solcher Transporte durch die Wahl des URI-Schemas oder innerhalb der User-Agent-Konfiguration angegeben wird.
Das "https"-Schema kann verwendet werden, um Ressourcen zu identifizieren, die eine vertrauliche Verbindung erfordern, wie in Abschnitt 2.7.2 beschrieben.
9.8. Datenschutz von Server-Protokollinformationen
Ein Server ist in der Lage, personenbezogene Daten über die Anfragen eines Nutzers über die Zeit zu speichern, die deren Lesemuster oder Interessensgebiete identifizieren könnten. Insbesondere Protokollinformationen, die an einem Vermittler gesammelt werden, enthalten oft eine Historie der Interaktion von User Agents über eine Vielzahl von Websites hinweg, die auf einzelne Nutzer zurückgeführt werden kann.
HTTP-Protokollinformationen sind von Natur aus vertraulich; ihre Handhabung ist oft durch Gesetze und Vorschriften eingeschränkt. Protokollinformationen müssen sicher gespeichert und es müssen angemessene Richtlinien für ihre Analyse befolgt werden. Die Anonymisierung personenbezogener Informationen innerhalb einzelner Einträge hilft, reicht aber im Allgemeinen nicht aus, um zu verhindern, dass echte Protokollspuren anhand der Korrelation mit anderen Zugriffsmerkmalen re-identifiziert werden. Daher ist es unsicher, auf einen bestimmten Client bezogene Zugriffsspuren zu veröffentlichen, selbst wenn der Schlüssel pseudonym ist.
Um das Risiko von Diebstahl oder versehentlicher Veröffentlichung zu minimieren, sollten Protokollinformationen so bald wie möglich von personenbezogenen Daten befreit werden, darunter Benutzerkennungen, IP-Adressen und vom Nutzer bereitgestellte Query-Parameter, sobald diese Informationen nicht mehr benötigt werden, um betriebliche Anforderungen an Sicherheit, Auditing oder Betrugsbekämpfung zu unterstützen.