17. Security Considerations (Sicherheitsüberlegungen)

Dieser Abschnitt soll Entwickler, Informationsanbieter und Benutzer über bekannte Sicherheitsbedenken informieren, die für die HTTP-Semantik und ihre Verwendung zur Übertragung von Informationen über das Internet relevant sind. Überlegungen zur Zwischenspeicherung werden in Abschnitt 7 von [CACHING] besprochen, und Überlegungen zur HTTP/1.1-Nachrichtensyntax und -Parsing werden in Abschnitt 11 von [HTTP/1.1] besprochen.

Die nachfolgende Liste der Überlegungen ist nicht erschöpfend. Die meisten Sicherheitsbedenken im Zusammenhang mit der HTTP-Semantik betreffen die Sicherung von serverseitigen Anwendungen (Code hinter der HTTP-Schnittstelle), die Sicherung der Verarbeitung von über HTTP empfangenen Inhalten durch den User-Agent oder die sichere Nutzung des Internets im Allgemeinen, anstatt der Sicherheit des Protokolls selbst. Die Sicherheitsüberlegungen für URIs, die für den HTTP-Betrieb grundlegend sind, werden in Abschnitt 7 von [URI] besprochen. Verschiedene Organisationen pflegen thematische Informationen und Links zu aktueller Forschung über Webanwendungssicherheit (z.B. [OWASP]).

17.1. Establishing Authority (Autoritätsfeststellung)

HTTP stützt sich auf das Konzept einer "autoritativen Antwort": eine Antwort, die vom (oder auf Anweisung des) Origin-Server, der im Ziel-URI identifiziert wird, als die für diese Anfrage am besten geeignete Antwort bestimmt wurde, gegeben den Zustand der Zielressource zum Zeitpunkt der Entstehung der Antwortnachricht.

Wenn ein registrierter Name im Authority-Komponenten verwendet wird, verlässt sich das "http"-URI-Schema (Abschnitt 4.2.1) auf den lokalen Namensauflösungsdienst des Benutzers, um zu bestimmen, wo es autoritative Antworten finden kann. Dies bedeutet, dass jeder Angriff auf die Netzwerk-Host-Tabelle, zwischengespeicherte Namen oder Namensauflösungsbibliotheken des Benutzers zu einem Angriffsvektor für die Feststellung der Autorität für "http"-URIs wird. Ebenso könnten die Wahl des Servers für den Domain Name Service (DNS) durch den Benutzer und die Hierarchie der Server, von denen er Auflösungsergebnisse erhält, die Authentizität von Adresszuordnungen beeinflussen; DNS Security Extensions (DNSSEC, [RFC4033]) sind eine Möglichkeit, die Authentizität zu verbessern, ebenso wie die verschiedenen Mechanismen für DNS-Anfragen über sicherere Übertragungsprotokolle.

Darüber hinaus ist die Feststellung der Autorität für einen "http"-URI nach Erhalt einer IP-Adresse anfällig für Angriffe auf das Internet Protocol Routing.

Das "https"-Schema (Abschnitt 4.2.2) soll viele dieser potenziellen Angriffe auf die Autoritätsfeststellung verhindern (oder zumindest offenlegen), vorausgesetzt, die ausgehandelte Verbindung ist gesichert und der Client überprüft korrekt, dass die Identität des kommunizierenden Servers mit der Authority-Komponente des Ziel-URI übereinstimmt (Abschnitt 4.3.4). Die korrekte Implementierung einer solchen Verifizierung kann schwierig sein (siehe [Georgiev]).

Die Autorität für einen bestimmten Origin-Server kann durch Protokollerweiterungen delegiert werden; zum Beispiel [ALTSVC]. Ebenso kann die Menge der Server, für die eine Verbindung als autoritativ angesehen wird, mit einer Protokollerweiterung wie [RFC8336] geändert werden.

Die Bereitstellung einer Antwort von einer nicht-autoritativen Quelle, wie einem gemeinsam genutzten Proxy-Cache, ist oft nützlich, um Leistung und Verfügbarkeit zu verbessern, aber nur insoweit, als die Quelle vertrauenswürdig ist oder die nicht vertrauenswürdige Antwort sicher verwendet werden kann.

Leider kann die Kommunikation der Autorität an Benutzer schwierig sein. Zum Beispiel ist "Phishing" ein Angriff auf die Wahrnehmung der Autorität durch den Benutzer, bei dem diese Wahrnehmung durch die Präsentation ähnlicher Markenzeichen im Hypertext irregeführt werden kann, möglicherweise unterstützt durch Userinfo, das die Authority-Komponente verschleiert (siehe Abschnitt 4.2.1). User-Agents können die Auswirkungen von Phishing-Angriffen verringern, indem sie es Benutzern ermöglichen, einen Ziel-URI vor einer Aktion leicht zu überprüfen, indem sie Userinfo prominent hervorheben (oder ablehnen), wenn sie vorhanden sind, und indem sie keine gespeicherten Credentials an Ziel-URIs senden, die Userinfo enthalten.

17.2. Risks of Intermediaries (Risiken von Vermittlern)

HTTP-Vermittler sind von Natur aus für On-Path-Angriffe positioniert. Die Kompromittierung der Systeme, auf denen Vermittler laufen, kann zu ernsthaften Sicherheits- und Datenschutzproblemen führen. Vermittler können Zugriff auf sicherheitsrelevante Informationen, persönliche Informationen über einzelne Benutzer und Organisationen sowie proprietäre Informationen haben, die Benutzern und Content-Providern gehören. Ein kompromittierter Vermittler oder ein Vermittler, der ohne Rücksicht auf Sicherheits- und Datenschutzüberlegungen implementiert oder konfiguriert wurde, könnte zur Begehung einer Vielzahl potenzieller Angriffe verwendet werden.

Vermittler, die einen gemeinsam genutzten Cache enthalten, sind besonders anfällig für Cache-Poisoning-Angriffe, wie in Abschnitt 7 von [CACHING] beschrieben.

Implementierer müssen die Datenschutz- und Sicherheitsauswirkungen ihrer Entwurfs- und Codierungsentscheidungen sowie der Konfigurationsoptionen, die sie Betreibern bieten (insbesondere der Standardkonfiguration), berücksichtigen.

Vermittler sind nicht vertrauenswürdiger als die Menschen und Richtlinien, unter denen sie operieren; HTTP kann dieses Problem nicht lösen.

17.3. Attacks Based on File and Path Names (Angriffe basierend auf Datei- und Pfadnamen)

Origin-Server nutzen häufig ihr lokales Dateisystem, um die Zuordnung vom Ziel-URI zu Ressourcendarstellungen zu verwalten. Die meisten Dateisysteme sind nicht darauf ausgelegt, sich gegen böswillige Datei- oder Pfadnamen zu schützen. Daher muss ein Origin-Server beim Zuordnen der Zielressource zu Dateien, Ordnern oder Verzeichnissen vermeiden, auf Namen zuzugreifen, die eine besondere Bedeutung für das System haben.

Zum Beispiel verwenden UNIX, Microsoft Windows und andere Betriebssysteme ".." als Pfadkomponente, um eine Verzeichnisebene über der aktuellen anzuzeigen, und sie verwenden speziell benannte Pfade oder Dateinamen, um Daten an Systemgeräte zu senden. Ähnliche Namenskonventionen können in anderen Arten von Speichersystemen existieren. Ebenso haben lokale Speichersysteme eine ärgerliche Tendenz, Benutzerfreundlichkeit gegenüber Sicherheit zu bevorzugen, wenn sie ungültige oder unerwartete Zeichen, Rekombination zerlegter Zeichen und Groß-/Kleinschreibungsnormalisierung von groß-/kleinschreibungsunempfindlichen Namen handhaben.

Angriffe basierend auf solchen speziellen Namen konzentrieren sich tendenziell entweder auf Denial-of-Service (z.B. dem Server zu sagen, er solle von einem COM-Port lesen) oder auf die Offenlegung von Konfigurations- und Quelldateien, die nicht zum Servieren bestimmt sind.

17.4. Attacks Based on Command, Code, or Query Injection (Angriffe basierend auf Befehls-, Code- oder Abfrage-Injektion)

Origin-Server verwenden häufig Parameter innerhalb des URI als Mittel zur Identifizierung von Systemdiensten, zur Auswahl von Datenbankeinträgen oder zur Auswahl einer Datenquelle. In einer Anfrage empfangene Daten können jedoch nicht vertraut werden. Ein Angreifer könnte beliebige Anfragedatenelemente (Methode, Ziel-URI, Header-Felder oder Inhalt) konstruieren, um Daten zu enthalten, die als Befehl, Code oder Abfrage fehlinterpretiert werden könnten, wenn sie durch einen Befehlsaufruf, Sprachinterpreter oder eine Datenbankschnittstelle geleitet werden.

Zum Beispiel ist SQL-Injection ein häufiger Angriff, bei dem zusätzliche Abfragesprache in einen Teil des Ziel-URI oder der Header-Felder (z.B. Host, Referer usw.) eingefügt wird. Wenn die empfangenen Daten direkt in einer SELECT-Anweisung verwendet werden, könnte die Abfragesprache als Datenbankbefehl interpretiert werden, anstatt als einfacher Zeichenfolgenwert. Diese Art von Implementierungsvulnerabilität ist äußerst häufig, obwohl sie leicht zu verhindern ist.

Im Allgemeinen sollten Ressourcenimplementierungen die Verwendung von Anfragedaten in Kontexten vermeiden, die als Anweisungen verarbeitet oder interpretiert werden. Parameter sollten mit festen Zeichenfolgen verglichen und als Ergebnis dieses Vergleichs gehandelt werden, anstatt durch eine Schnittstelle geleitet zu werden, die nicht auf nicht vertrauenswürdige Daten vorbereitet ist. Empfangene Daten, die nicht auf festen Parametern basieren, sollten sorgfältig gefiltert oder codiert werden, um Fehlinterpretationen zu vermeiden.

Ähnliche Überlegungen gelten für Anfragedaten, wenn sie gespeichert und später verarbeitet werden, wie in Protokolldateien, Überwachungstools oder wenn sie in einem Datenformat enthalten sind, das eingebettete Skripte ermöglicht.

17.5. Attacks via Protocol Element Length (Angriffe über Protokollelement-Länge)

Da HTTP hauptsächlich textuelle, zeichenbegrenzte Felder verwendet, sind Parser oft anfällig für Angriffe, die auf dem Senden sehr langer (oder sehr langsamer) Datenströme basieren, insbesondere wenn eine Implementierung ein Protokollelement ohne vordefinierte Länge erwartet (Abschnitt 2.3).

Um Interoperabilität zu fördern, werden spezifische Empfehlungen für Mindestgrößengrenzen für Felder gemacht (Abschnitt 5.4). Dies sind Mindestempfehlungen, die so gewählt wurden, dass sie auch von Implementierungen mit begrenzten Ressourcen unterstützt werden können; es wird erwartet, dass die meisten Implementierungen wesentlich höhere Grenzen wählen werden.

Ein Server kann eine Nachricht ablehnen, die einen zu langen Ziel-URI (Abschnitt 15.5.15) oder zu großen Anforderungsinhalt (Abschnitt 15.5.14) hat. Zusätzliche Statuscodes im Zusammenhang mit Kapazitätsgrenzen wurden durch Erweiterungen zu HTTP definiert [RFC6585].

Empfänger sollten sorgfältig begrenzen, in welchem Umfang sie andere Protokollelemente verarbeiten, einschließlich (aber nicht beschränkt auf) Anforderungsmethoden, Antwortstatusphrasen, Feldnamen, numerische Werte und Chunk-Längen. Das Versäumnis, eine solche Verarbeitung zu begrenzen, kann zur Ausführung von willkürlichem Code aufgrund von Puffer- oder arithmetischen Überläufen und zu erhöhter Anfälligkeit für Denial-of-Service-Angriffe führen.

17.6. Attacks Using Shared-Dictionary Compression (Angriffe mit gemeinsam genutzter Wörterbuch-Kompression)

Einige Angriffe auf verschlüsselte Protokolle nutzen die durch dynamische Kompression erzeugten Größenunterschiede, um vertrauliche Informationen zu offenbaren; zum Beispiel [BREACH]. Diese Angriffe beruhen darauf, eine Redundanz zwischen vom Angreifer kontrollierten Inhalten und den vertraulichen Informationen zu schaffen, sodass ein dynamischer Kompressionsalgorithmus, der dasselbe Wörterbuch für beide Inhalte verwendet, effizienter komprimiert, wenn der vom Angreifer kontrollierte Inhalt mit Teilen des vertraulichen Inhalts übereinstimmt.

HTTP-Nachrichten können auf verschiedene Weise komprimiert werden, einschließlich der Verwendung von TLS-Kompression, Content-Codierungen, Transfer-Codierungen und anderen Erweiterungs- oder versionsspezifischen Mechanismen.

Die effektivste Abschwächung dieses Risikos besteht darin, die Kompression für sensible Daten zu deaktivieren oder sensible Daten strikt von vom Angreifer kontrollierten Daten zu trennen, sodass sie nicht dasselbe Kompressionswörterbuch teilen können. Mit sorgfältiger Gestaltung kann ein Kompressionsschema so entworfen werden, dass es in begrenzten Anwendungsfällen nicht als ausnutzbar angesehen wird, wie HPACK ([HPACK]).

17.7. Disclosure of Personal Information (Offenlegung persönlicher Informationen)

Clients haben oft Zugriff auf große Mengen persönlicher Informationen, einschließlich sowohl von Informationen, die vom Benutzer bereitgestellt werden, um mit Ressourcen zu interagieren (z.B. Name, Standort, E-Mail-Adresse, Passwörter, Verschlüsselungsschlüssel des Benutzers usw.) als auch Informationen über die Browsing-Aktivität des Benutzers im Laufe der Zeit (z.B. Verlauf, Lesezeichen usw.). Implementierungen müssen die unbeabsichtigte Offenlegung persönlicher Informationen verhindern.

17.8. Privacy of Server Log Information (Datenschutz von Server-Protokollinformationen)

Ein Server ist in der Lage, persönliche Daten über die Anfragen eines Benutzers im Laufe der Zeit zu speichern, die deren Lesemuster oder Interessensthemen identifizieren könnten. Insbesondere enthalten Protokollinformationen, die an einem Vermittler gesammelt werden, häufig eine Historie der User-Agent-Interaktion über eine Vielzahl von Websites hinweg, die zu einzelnen Benutzern zurückverfolgt werden kann.

HTTP-Protokollinformationen sind vertraulicher Natur; ihre Handhabung ist oft durch Gesetze und Vorschriften eingeschränkt. Protokollinformationen müssen sicher gespeichert werden und für ihre Analyse müssen angemessene Richtlinien befolgt werden. Die Anonymisierung persönlicher Informationen innerhalb einzelner Einträge hilft, ist aber im Allgemeinen nicht ausreichend, um zu verhindern, dass echte Protokollspuren basierend auf der Korrelation mit anderen Zugriffseigenschaften re-identifiziert werden. Daher sind Zugriffsspuren, die auf einen bestimmten Client abgestimmt sind, unsicher zu veröffentlichen, selbst wenn der Schlüssel pseudonym ist.

Um das Risiko von Diebstahl oder versehentlicher Veröffentlichung zu minimieren, sollten Protokollinformationen von personenbezogenen Daten, einschließlich Benutzer-IDs, IP-Adressen und vom Benutzer bereitgestellten Abfrageparametern, bereinigt werden, sobald diese Informationen nicht mehr zur Unterstützung operativer Bedürfnisse für Sicherheit, Prüfung oder Betrugskontrolle erforderlich sind.

17.9. Disclosure of Sensitive Information in URIs (Offenlegung sensibler Informationen in URIs)

URIs sollen geteilt werden, nicht gesichert, auch wenn sie sichere Ressourcen identifizieren. URIs werden häufig auf Displays angezeigt, Vorlagen hinzugefügt, wenn eine Seite gedruckt wird, und in einer Vielzahl ungeschützter Lesezeichenlisten gespeichert. Viele Server, Proxies und User-Agents protokollieren oder zeigen den Ziel-URI an Orten an, wo er für Dritte sichtbar sein könnte. Daher ist es unklug, Informationen in einen URI aufzunehmen, die sensibel, personenbezogen oder ein Offenlegungsrisiko sind.

Wenn eine Anwendung clientseitige Mechanismen verwendet, um einen Ziel-URI aus vom Benutzer bereitgestellten Informationen zu konstruieren, wie z.B. die Abfragefelder eines Formulars mit GET, könnten potenziell sensible Daten bereitgestellt werden, die nicht für die Offenlegung innerhalb eines URI geeignet wären. POST wird in solchen Fällen oft bevorzugt, da es normalerweise keinen URI konstruiert; stattdessen überträgt POST eines Formulars die potenziell sensiblen Daten im Anforderungsinhalt. Dies behindert jedoch das Caching und verwendet eine unsichere Methode für das, was ansonsten eine sichere Anfrage wäre. Alternative Workarounds umfassen das Transformieren der vom Benutzer bereitgestellten Daten vor dem Konstruieren des URI oder das Filtern der Daten, um nur häufige Werte einzuschließen, die nicht sensibel sind. Ebenso kann das Umleiten des Ergebnisses einer Abfrage zu einem anderen (vom Server generierten) URI potenziell sensible Daten aus späteren Links entfernen und eine cachefähige Antwort für die spätere Wiederverwendung bereitstellen.

Da das Referer-Header-Feld einer Zielseite den Kontext mitteilt, der zu einer Anfrage geführt hat, hat es das Potenzial, Informationen über die unmittelbare Browsing-Historie des Benutzers und alle persönlichen Informationen zu offenbaren, die im URI der verweisenden Ressource gefunden werden könnten. Einschränkungen des Referer-Header-Felds werden in Abschnitt 10.1.3 beschrieben, um einige seiner Sicherheitsüberlegungen zu adressieren.

17.10. Application Handling of Field Names (Anwendungsbehandlung von Feldnamen)

Server verwenden häufig Nicht-HTTP-Gateway-Schnittstellen und Frameworks, um eine empfangene Anfrage zu verarbeiten und Inhalt für die Antwort zu produzieren. Aus historischen Gründen übergeben solche Schnittstellen empfangene Feldnamen häufig als externe Variablennamen unter Verwendung eines für Umgebungsvariablen geeigneten Namensmappings.

Zum Beispiel wird das CGI-Mapping (Common Gateway Interface) protokollspezifischer Meta-Variablen, definiert in Abschnitt 4.1.18 von [RFC3875], auf empfangene Header-Felder angewendet, die keiner der Standard-CGI-Variablen entsprechen; das Mapping besteht darin, jedem Namen "HTTP_" voranzustellen und alle Vorkommen von Bindestrich ("-") in Unterstrich ("_") zu ändern. Dasselbe Mapping wurde von vielen anderen Anwendungs-Frameworks übernommen, um das Verschieben von Anwendungen von einer Plattform zur anderen zu vereinfachen.

In CGI würde ein empfangenes Content-Length-Feld als Meta-Variable "CONTENT_LENGTH" mit einem Zeichenfolgenwert übergeben, der dem empfangenen Feldwert entspricht. Im Gegensatz dazu würde ein empfangenes "Content_Length"-Header-Feld als protokollspezifische Meta-Variable "HTTP_CONTENT_LENGTH" übergeben, was zu Verwirrung führen könnte, wenn eine Anwendung fälschlicherweise die protokollspezifische Meta-Variable anstelle der Standard-Variable liest. (Diese historische Praxis ist der Grund, warum Abschnitt 16.3.2.1 von der Erstellung neuer Feldnamen abrät, die einen Unterstrich enthalten.)

Leider kann das Mapping von Feldnamen auf verschiedene Schnittstellennamen zu Sicherheitsvulnerabilitäten führen, wenn das Mapping unvollständig oder mehrdeutig ist. Wenn ein Angreifer beispielsweise ein Feld namens "Transfer_Encoding" senden würde, könnte eine naive Schnittstelle dies auf denselben Variablennamen wie das Feld "Transfer-Encoding" mappen, was zu einer potenziellen Request-Smuggling-Vulnerability führt (Abschnitt 11.2 von [HTTP/1.1]).

Um die damit verbundenen Risiken zu mindern, wird Implementierungen, die solche Mappings durchführen, empfohlen, das Mapping eindeutig und vollständig für den gesamten Bereich potenzieller Oktette zu machen, die als Name empfangen werden (einschließlich solcher, die durch die HTTP-Grammatik entmutigt oder verboten sind). Zum Beispiel könnte ein Feld mit einem ungewöhnlichen Namenzeichen dazu führen, dass die Anfrage blockiert, das spezifische Feld entfernt oder der Name mit einem anderen Präfix übergeben wird, um es von anderen Feldern zu unterscheiden.

17.11. Disclosure of Fragment after Redirects (Offenlegung von Fragment nach Umleitungen)

Obwohl Fragment-Identifikatoren, die in URI-Referenzen verwendet werden, nicht in Anfragen gesendet werden, sollten Implementierer sich bewusst sein, dass sie für den User-Agent und alle Erweiterungen oder Skripte sichtbar sind, die als Ergebnis der Antwort ausgeführt werden. Insbesondere wenn eine Umleitung erfolgt und der Fragment-Identifikator der ursprünglichen Anfrage von der neuen Referenz in Location (Abschnitt 10.2.2) geerbt wird, könnte dies den Effekt haben, das Fragment einer Site einer anderen Site offenzulegen. Wenn die erste Site persönliche Informationen in Fragmenten verwendet, sollte sie sicherstellen, dass Umleitungen zu anderen Sites eine (möglicherweise leere) Fragment-Komponente enthalten, um diese Vererbung zu blockieren.

17.12. Disclosure of Product Information (Offenlegung von Produktinformationen)

Die Header-Felder User-Agent (Abschnitt 10.1.5), Via (Abschnitt 7.6.3) und Server (Abschnitt 10.2.4) offenbaren häufig Informationen über die jeweiligen Softwaresysteme des Absenders. Theoretisch kann dies es einem Angreifer erleichtern, bekannte Sicherheitslücken auszunutzen; in der Praxis neigen Angreifer dazu, alle potenziellen Lücken unabhängig von den scheinbar verwendeten Softwareversionen zu versuchen.

Proxies, die als Portal durch eine Netzwerk-Firewall dienen, sollten besondere Vorsichtsmaßnahmen bezüglich der Übertragung von Header-Informationen treffen, die Hosts hinter der Firewall identifizieren könnten. Das Via-Header-Feld ermöglicht es Vermittlern, sensible Maschinennamen durch Pseudonyme zu ersetzen.

17.13. Browser Fingerprinting (Browser-Fingerprinting)

Browser-Fingerprinting ist eine Reihe von Techniken zur Identifizierung eines bestimmten User-Agents im Laufe der Zeit durch seine einzigartigen Merkmale. Diese Merkmale können Informationen darüber umfassen, wie er das zugrunde liegende Transportprotokoll verwendet, Funktionskapazitäten und die Skriptumgebung, obwohl hier besonders die Reihe einzigartiger Merkmale von Interesse ist, die über HTTP kommuniziert werden könnten. Fingerprinting wird als Datenschutzbedenken angesehen, da es die Verfolgung des Verhaltens eines User-Agents im Laufe der Zeit ermöglicht ([Bujlow]) ohne die entsprechenden Kontrollen, die der Benutzer über andere Formen der Datenerfassung haben könnte (z.B. Cookies). Viele Allzweck-User-Agents (d.h. Webbrowser) haben Schritte unternommen, um ihre Fingerprints zu reduzieren.

Es gibt eine Reihe von Anforderungs-Header-Feldern, die Informationen an Server offenbaren könnten, die ausreichend einzigartig sind, um Fingerprinting zu ermöglichen. Das From-Header-Feld ist das offensichtlichste, obwohl erwartet wird, dass From nur gesendet wird, wenn eine Selbstidentifikation vom Benutzer gewünscht wird. Ebenso sind Cookie-Header-Felder absichtlich so konzipiert, dass sie eine Re-Identifikation ermöglichen, sodass Fingerprinting-Bedenken nur für Situationen gelten, in denen Cookies durch die Konfiguration des User-Agents deaktiviert oder eingeschränkt sind.

Das User-Agent-Header-Feld könnte genügend Informationen enthalten, um ein bestimmtes Gerät eindeutig zu identifizieren, normalerweise in Kombination mit anderen Merkmalen, insbesondere wenn der User-Agent übermäßige Details über das System oder Erweiterungen des Benutzers sendet. Die für Benutzer am wenigsten erwartete Quelle einzigartiger Informationen ist jedoch die proaktive Aushandlung (Abschnitt 12.1), einschließlich der Header-Felder Accept, Accept-Charset, Accept-Encoding und Accept-Language.

Zusätzlich zur Fingerprinting-Besorgnis kann die detaillierte Verwendung des Accept-Language-Header-Felds Informationen offenbaren, die der Benutzer als privat betrachten könnte. Zum Beispiel könnte das Verstehen einer bestimmten Sprachmenge stark mit der Zugehörigkeit zu einer bestimmten ethnischen Gruppe korreliert sein. Ein Ansatz, der einen solchen Verlust der Privatsphäre begrenzt, wäre, dass ein User-Agent das Senden von Accept-Language außer für Websites unterlässt, die explizit erlaubt wurden, möglicherweise über Interaktion nach Erkennung eines Vary-Header-Felds, das anzeigt, dass Sprachverhandlung nützlich sein könnte.

In Umgebungen, in denen Proxies zur Verbesserung der Privatsphäre verwendet werden, sollten User-Agents beim Senden proaktiver Aushandlungs-Header-Felder konservativ sein. Allzweck-User-Agents, die ein hohes Maß an Header-Feld-Konfigurierbarkeit bieten, sollten Benutzer über den Verlust der Privatsphäre informieren, der entstehen könnte, wenn zu viele Details bereitgestellt werden. Als extreme Datenschutzmaßnahme könnten Proxies die proaktiven Aushandlungs-Header-Felder in weitergeleiteten Anfragen filtern.

17.14. Validator Retention (Validator-Aufbewahrung)

Die von dieser Spezifikation definierten Validatoren sind nicht dazu gedacht, die Gültigkeit einer Darstellung zu gewährleisten, vor böswilligen Änderungen zu schützen oder On-Path-Angriffe zu erkennen. Bestenfalls ermöglichen sie effizientere Cache-Updates und optimistische gleichzeitige Schreibvorgänge, wenn sich alle Teilnehmer ordentlich verhalten. Schlimmstenfalls werden die Bedingungen fehlschlagen und der Client erhält eine Antwort, die nicht schädlicher ist als ein HTTP-Austausch ohne bedingte Anfragen.

Ein Entity-Tag kann auf Weisen missbraucht werden, die Datenschutzrisiken schaffen. Zum Beispiel könnte eine Site absichtlich ein semantisch ungültiges Entity-Tag konstruieren, das für den Benutzer oder User-Agent eindeutig ist, es in einer cachefähigen Antwort mit einer langen Frischzeit senden und dann dieses Entity-Tag in späteren bedingten Anfragen als Mittel zur Re-Identifikation dieses Benutzers oder User-Agents lesen. Ein solches identifizierendes Tag würde zu einem persistenten Identifikator werden, solange der User-Agent den ursprünglichen Cache-Eintrag beibehält. User-Agents, die Darstellungen cachen, sollten sicherstellen, dass der Cache gelöscht oder ersetzt wird, wenn der Benutzer datenschutzerhaltende Aktionen durchführt, wie das Löschen gespeicherter Cookies oder den Wechsel in einen privaten Browsing-Modus.

17.15. Denial-of-Service Attacks Using Range (Denial-of-Service-Angriffe mit Range)

Unbeschränkte mehrfache Bereichsanfragen sind anfällig für Denial-of-Service-Angriffe, da der Aufwand für die Anforderung vieler überlappender Bereiche derselben Daten winzig ist im Vergleich zu Zeit, Speicher und Bandbreite, die durch den Versuch verbraucht werden, die angeforderten Daten in vielen Teilen bereitzustellen. Server sollten unverschämte Bereichsanfragen ignorieren, zusammenführen oder ablehnen, wie z.B. Anfragen nach mehr als zwei überlappenden Bereichen oder nach vielen kleinen Bereichen in einem einzigen Set, insbesondere wenn die Bereiche ohne ersichtlichen Grund außer der Reihe angefordert werden. Multipart-Bereichsanfragen sind nicht für zufälligen Zugriff konzipiert.

17.16. Authentication Considerations (Authentifizierungsüberlegungen)

Alles zum Thema HTTP-Authentifizierung ist eine Sicherheitsüberlegung, daher ist die nachfolgende Liste der Überlegungen nicht erschöpfend. Darüber hinaus beschränkt sie sich auf Sicherheitsüberlegungen bezüglich des Authentifizierungs-Frameworks im Allgemeinen, anstatt alle potenziellen Überlegungen für spezifische Authentifizierungsschemata zu diskutieren (die in den Spezifikationen dokumentiert werden sollten, die diese Schemata definieren). Verschiedene Organisationen pflegen thematische Informationen und Links zu aktueller Forschung über Webanwendungssicherheit (z.B. [OWASP]), einschließlich häufiger Fallstricke für die Implementierung und Verwendung der in der Praxis gefundenen Authentifizierungsschemata.

17.16.1. Confidentiality of Credentials (Vertraulichkeit von Credentials)

Das HTTP-Authentifizierungs-Framework definiert keinen einzelnen Mechanismus zur Wahrung der Vertraulichkeit von Credentials; stattdessen definiert jedes Authentifizierungsschema, wie die Credentials vor der Übertragung codiert werden. Während dies Flexibilität für die Entwicklung zukünftiger Authentifizierungsschemata bietet, ist es unzureichend für den Schutz bestehender Schemata, die keine eigene Vertraulichkeit bieten oder nicht ausreichend vor Replay-Angriffen schützen. Wenn der Server außerdem Credentials erwartet, die für jeden einzelnen Benutzer spezifisch sind, hat der Austausch dieser Credentials den Effekt, diesen Benutzer zu identifizieren, auch wenn der Inhalt der Credentials vertraulich bleibt.

HTTP hängt von den Sicherheitseigenschaften der zugrunde liegenden Transport- oder Session-Level-Verbindung ab, um eine vertrauliche Übertragung von Feldern zu gewährleisten. Dienste, die auf individuelle Benutzerauthentifizierung angewiesen sind, erfordern eine gesicherte Verbindung vor dem Austausch von Credentials (Abschnitt 4.2.2).

17.16.2. Credentials and Idle Clients (Credentials und inaktive Clients)

Bestehende HTTP-Clients und User-Agents behalten Authentifizierungsinformationen typischerweise unbegrenzt bei. HTTP bietet keinen Mechanismus für den Origin-Server, um Clients anzuweisen, diese zwischengespeicherten Credentials zu verwerfen, da das Protokoll keine Kenntnis davon hat, wie Credentials vom User-Agent erhalten oder verwaltet werden. Die Mechanismen zum Ablaufen oder Widerrufen von Credentials können als Teil einer Authentifizierungsschema-Definition spezifiziert werden.

Umstände, unter denen das Caching von Credentials mit dem Sicherheitsmodell der Anwendung interferieren kann, umfassen, sind aber nicht beschränkt auf:

• Clients, die für einen längeren Zeitraum inaktiv waren, nach dem der Server den Client veranlassen möchte, den Benutzer erneut zur Eingabe der Credentials aufzufordern.

• Anwendungen, die eine Sitzungsbeendigungsanzeige enthalten (wie eine "Logout"- oder "Commit"-Schaltfläche auf einer Seite), nach der die Serverseite der Anwendung "weiß", dass es keinen weiteren Grund für den Client gibt, die Credentials zu behalten.

User-Agents, die Credentials cachen, werden ermutigt, einen leicht zugänglichen Mechanismus zum Verwerfen zwischengespeicherter Credentials unter Benutzerkontrolle bereitzustellen.

17.16.3. Protection Spaces (Schutzbereiche)

Authentifizierungsschemata, die sich ausschließlich auf den "realm"-Mechanismus zur Festlegung eines Schutzbereichs verlassen, werden Credentials für alle Ressourcen auf einem Origin-Server offenlegen. Clients, die erfolgreich authentifizierte Anfragen mit einer Ressource durchgeführt haben, können dieselben Authentifizierungs-Credentials für andere Ressourcen auf demselben Origin-Server verwenden. Dies ermöglicht es einer anderen Ressource, Authentifizierungs-Credentials für andere Ressourcen zu sammeln.

Dies ist besonders besorgniserregend, wenn ein Origin-Server Ressourcen für mehrere Parteien unter demselben Origin hostet (Abschnitt 11.5). Mögliche Abschwächungsstrategien umfassen die Beschränkung des direkten Zugriffs auf Authentifizierungs-Credentials (d.h. den Inhalt des Authorization-Anforderungs-Header-Felds nicht verfügbar zu machen) und die Trennung von Schutzbereichen durch Verwendung eines anderen Hostnamens (oder Portnummer) für jede Partei.

17.16.4. Additional Response Fields (Zusätzliche Antwortfelder)

Das Hinzufügen von Informationen zu Antworten, die über einen unverschlüsselten Kanal gesendet werden, kann Sicherheit und Datenschutz beeinträchtigen. Allein die Anwesenheit der Header-Felder Authentication-Info und Proxy-Authentication-Info zeigt an, dass HTTP-Authentifizierung verwendet wird. Zusätzliche Informationen könnten durch den Inhalt der authentifizierungsschema-spezifischen Parameter offengelegt werden; dies muss in den Definitionen dieser Schemata berücksichtigt werden.