9. Sicherheitsüberlegungen (Security Considerations)
Dieser Abschnitt soll Entwickler, Informationsanbieter und Benutzer über bekannte Sicherheitsbedenken informieren, die für HTTP-Semantik und ihre Verwendung zur Übertragung von Informationen über das Internet relevant sind. Überlegungen zur Nachrichtensyntax, -analyse und -routing werden in [RFC7230] diskutiert, und Überlegungen zum HTTP-Caching werden in [RFC7234] diskutiert.
Die nachfolgende Liste von Überlegungen ist nicht erschöpfend. Die meisten Sicherheitsbedenken im Zusammenhang mit HTTP-Semantik betreffen die Sicherung serverseitiger Anwendungen (Code hinter der HTTP-Schnittstelle), die Sicherung der User Agent-Verarbeitung von über HTTP empfangenem Inhalt oder die sichere Verwendung von Informationen, die aus HTTP-Header-Feldern gewonnen werden. Viele dieser Bedenken sind voneinander abhängig; eine Schwachstelle in Client-Software kann verwendet werden, um Schwachstellen in Server-Software auszunutzen, und umgekehrt.
9.1. Angriffe basierend auf Datei- und Pfadnamen (Attacks Based on File and Path Names)
Origin-Server verwenden häufig ihr lokales Dateisystem, um das Mapping von Ziel-URI zu Ressourcendarstellungen zu verwalten. Die meisten Dateisysteme sind nicht zum Schutz vor bösartigen Datei- oder Pfadnamen ausgelegt. Daher muss ein Origin-Server beim Mapping der Zielressource auf Dateien, Ordner oder Verzeichnisse den Zugriff auf Namen vermeiden, die für das System eine besondere Bedeutung 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 Benennungskonventionen können in anderen Arten von Speichersystemen existieren. Ebenso haben lokale Speichersysteme eine ärgerliche Tendenz, Benutzerfreundlichkeit gegenüber Sicherheit zu bevorzugen, wenn sie mit ungültigen oder unerwarteten Zeichen umgehen, und sie auf Weisen neu zusammenzusetzen, die zu unbeabsichtigten Mustern führen können.
Implementierungen müssen darauf achten, denselben String nicht mehr als einmal zu escapen oder zu unescapen, da das Unescapen eines zuvor escapten Strings zu unsicheren Zeichen führen kann. Insbesondere ist es nicht sicher, einfach das Request-Target zu unescapen und es ohne zusätzliche Überprüfungen als Dateisystempfad zu verwenden.
Beachten Sie, dass die Einschränkungen für Ziel-URIs in dieser Spezifikation nicht ausreichen, um diese Art von Angriffen zu verhindern; sie müssen durch implementierungsspezifische Prüfungen ergänzt werden.
9.2. Angriffe basierend auf Kommando-, Code- oder Query-Injection (Attacks Based on Command, Code, or Query Injection)
Origin-Server verwenden oft Parameter innerhalb der URI als Mittel zur Identifizierung von Systemdiensten, zur Auswahl von Datenbankeinträgen oder zur Auswahl einer Datenquelle. Allerdings können in einer Anfrage empfangene Daten nicht vertraut werden. Ein Angreifer könnte jedes der Request-Datenelemente (Methode, Request-Target, Header-Felder oder Body) so konstruieren, dass sie Daten enthalten, die als Befehl, Code oder Query fehlinterpretiert werden könnten, wenn sie durch einen Befehlsaufruf, Sprachinterpreter oder Datenbankschnittstelle übergeben werden.
Zum Beispiel ist SQL-Injection ein häufiger Angriff, bei dem zusätzliche Query-Sprache in einen Teil des Request-Targets oder von Header-Feldern (z. B. Host, Referer usw.) eingefügt wird. Wenn die empfangenen Daten direkt in einer SQL SELECT-Anweisung verwendet werden, könnte die Query-Sprache als Datenbankbefehl statt als einfacher Stringwert interpretiert werden. Diese Art von Implementierungsschwachstelle ist äußerst häufig, obwohl sie leicht zu verhindern ist.
Im Allgemeinen sollten (ought to) Ressourcenimplementierungen die Verwendung von Request-Daten bei der Zusammenstellung von Shell-Befehlen oder Queries vermeiden. Wenn eine solche Verwendung erforderlich ist, müssen die Daten vor der Verwendung ordnungsgemäß escaped werden (entsprechend dem System, das die Daten empfängt).
9.3. Offenlegung persönlicher Informationen (Disclosure of Personal Information)
Clients haben oft Zugriff auf große Mengen persönlicher Informationen, einschließlich sowohl Informationen, die vom Benutzer bereitgestellt werden, um mit Ressourcen zu interagieren (z. B. Name des Benutzers, Standort, E-Mail-Adresse, Passwörter, Verschlüsselungsschlüssel usw.) als auch Informationen über die Browsing-Aktivität des Benutzers im Laufe der Zeit (z. B. Verlauf, Lesezeichen usw.). Implementierungen müssen unbeabsichtigtes Durchsickern solcher Informationen verhindern.
9.3.1. Offenlegung über Anwendungsdaten (Disclosure via Application Data)
Anwendungen sollten (ought to) ihre Offenlegung von Informationen auf das beschränken, was zur Vervollständigung der Anfrage erforderlich ist, und die Offenlegung von Informationen vermeiden, die spezifisch für den Benutzer oder die interne Struktur der Anwendung sind (Abschnitt 5.5.3 und Abschnitt 7.4.2).
9.3.2. Offenlegung über Referer (Disclosure via Referer)
Das Referer-Header-Feld ermöglicht es einem Client, dem Server mitzuteilen, woher der Client das Request-Target erhalten hat, was Informationen über den Kontext oder die Browsing-Historie des Benutzers offenlegen kann. In dem Fall, in dem das Request-Target von einer Drittquelle bereitgestellt wurde, könnte der Benutzer diese Informationen vertraulich halten wollen (z. B. ein Link von medizinischen Informationen). Der User Agent sollte daher (ought to) dem Benutzer die Option geben, das Referer-Feld nicht zu senden oder eine weniger aufschlussreiche (z. B. nur der Origin) Version des Felds zu senden (Abschnitt 5.5.2).
Clients sollten (ought not to) kein Referer-Header-Feld in eine (nicht-sichere) HTTP-Anfrage aufnehmen, wenn die verweisende Seite mit einem sicheren Protokoll empfangen wurde.
Autoren von Diensten, die das HTTP-Protokoll verwenden, sollten (ought not to) GET- und POST-Anfragen mit formularkodierten Inhalten verwenden, um sensible Informationen wie persönlich identifizierende Informationen, Kontonummern, Passwörter usw. zu übertragen, da dies dazu führt, dass diese Daten unverschlüsselt und im Request-Target oder Inhalt übertragen werden. Servicedesigner sollten (ought to) die POST-Methode mit Message-Bodies verwenden, um solche sensiblen Informationen zu übertragen, wobei darauf zu achten ist, solche Informationen nicht im Request-Target aufzunehmen, da diese in Logs, Lesezeichen usw. offengelegt werden könnten.
9.3.3. Offenlegung über User-Agent (Disclosure via User-Agent)
Das User-Agent-Header-Feld enthält oft genug Informationen, um ein bestimmtes Gerät eindeutig zu identifizieren, normalerweise wenn es mit anderen Merkmalen kombiniert wird, insbesondere wenn der User Agent übermäßige Details über das System oder Erweiterungen des Benutzers sendet. Implementierungen sollten (ought to) solche Informationen einschränken (Abschnitt 5.5.3).
9.4. Datenschutz von Server-Log-Informationen (Privacy of Server Log Information)
Ein Server ist in der Lage, persönliche Daten über die Anfragen eines Benutzers im Laufe der Zeit zu speichern, die deren Lesemuster oder Interessenthemen identifizieren könnten. Insbesondere enthalten an einem Intermediär gesammelte Log-Informationen oft eine Historie der User Agent-Interaktion über eine Vielzahl von Websites, die auf einzelne Benutzer zurückgeführt werden kann.
HTTP-Log-Informationen sind von vertraulicher Natur; ihre Handhabung ist oft durch Gesetze und Vorschriften eingeschränkt. Log-Informationen müssen sicher gespeichert werden, und angemessene Richtlinien müssen für ihre Analyse befolgt werden. Die Anonymisierung persönlicher Informationen innerhalb einzelner Einträge hilft, ist jedoch im Allgemeinen nicht ausreichend, um zu verhindern, dass echte Log-Traces basierend auf Korrelation mit anderen Zugangsmerkmalen re-identifiziert werden. Daher sollten (ought to) Zugangsspuren, die mit einem bestimmten Client verknüpft sind, entweder anonymisiert oder als vertraulich betrachtet werden.
Um das Risiko von Diebstahl oder versehentlicher Veröffentlichung zu minimieren, sollten (ought to) Log-Informationen so schnell wie möglich gelöscht werden.
9.5. Offenlegung von Fragment nach Redirects (Disclosure of Fragment after Redirects)
Obwohl Fragmentbezeichner, die in URI-Referenzen verwendet werden, nicht in Anfragen gesendet werden, sollten (ought to) Implementierer sich bewusst sein, dass sie für den User Agent und alle Erweiterungen oder Skripte, die als Ergebnis der Antwort ausgeführt werden, sichtbar sein werden. Insbesondere wenn ein Redirect auftritt und der Fragmentbezeichner der ursprünglichen Anfrage von der neuen Referenz in Location geerbt wird (Abschnitt 7.1.2), könnte dies Sicherheitsfolgen haben.
9.6. Offenlegung von Produktinformationen (Disclosure of Product Information)
Die Server- und User-Agent-Header-Felder offenbaren oft Informationen über die Softwaresysteme des jeweiligen Absenders. In der Theorie kann dies es einem Angreifer erleichtern, bekannte Sicherheitslücken auszunutzen; in der Praxis neigen Angreifer dazu, alle potenziellen Löcher zu versuchen, unabhängig von den offensichtlichen Softwareversionen, die verwendet werden.
Proxys, die als Portal durch eine Netzwerkfirewall dienen, sollten (ought to) besondere Vorsichtsmaßnahmen bezüglich der Übertragung von Header-Informationen treffen, die Hosts hinter der Firewall identifizieren könnten. Das Via-Header-Feld erlaubt es Intermediären, sensible Maschinennamen durch Pseudonyme zu ersetzen.
9.7. Browser-Fingerprinting (Browser Fingerprinting)
Browser-Fingerprinting ist eine Reihe von Techniken zur Identifizierung eines bestimmten User Agents im Laufe der Zeit durch seine einzigartige Merkmalskombination. Diese Merkmale können Informationen darüber enthalten, wie es das zugrunde liegende Transportprotokoll verwendet, Funktionsmerkmale und Skriptumgebung, obwohl hier besonders die Menge einzigartiger Merkmale von Interesse ist, die über HTTP kommuniziert werden könnten. Fingerprinting wird als Datenschutzproblem angesehen, weil es das Tracking des Verhaltens eines User Agents im Laufe der Zeit ermöglicht (Abschnitt 9.4), ohne die entsprechenden Kontrollen, die der Benutzer möglicherweise über andere Datenformen wie Cookies hat.
Es gibt eine Reihe von Request-Header-Feldern, die Servern Informationen offenbaren könnten, die ausreichend eindeutig 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 bewusst so gestaltet, dass sie Re-Identifikation ermöglichen, sodass Fingerprinting-Bedenken nur gelten, wenn Cookies vom User Agent deaktiviert oder eingeschränkt werden.
Das User-Agent-Header-Feld kann genug Informationen enthalten, um ein bestimmtes Gerät eindeutig zu identifizieren, normalerweise wenn es mit anderen Merkmalen kombiniert wird, insbesondere wenn der User Agent übermäßige Details über das System oder Erweiterungen des Benutzers sendet. Die Quelle eindeutiger Informationen, die von Benutzern am wenigsten erwartet wird, ist jedoch die proaktive Verhandlung (Abschnitt 3.4.1), einschließlich der Accept-, Accept-Charset-, Accept-Encoding- und Accept-Language-Header-Felder.
Zusätzlich zu den Fingerprinting-Bedenken kann die detaillierte Verwendung des Accept-Language-Header-Felds Informationen offenlegen, die der Benutzer als privater Natur betrachten könnte. Zum Beispiel könnte das Verständnis eines bestimmten Sprachsets stark mit der Zugehörigkeit zu einer bestimmten ethnischen Gruppe korreliert sein. Ein Ansatz, der einen solchen Verlust der Privatsphäre begrenzt, wäre für einen User Agent, das Senden von Accept-Language wegzulassen, außer für Sites, die auf eine Whitelist gesetzt wurden, möglicherweise über Interaktion, nachdem ein Vary-Header-Feld erkannt wurde, das anzeigt, dass Sprachverhandlung nützlich sein könnte.
In Umgebungen, in denen Proxys zur Verbesserung der Privatsphäre verwendet werden, sollten (ought to) User Agents beim Senden proaktiver Verhandlungs-Header-Felder konservativ sein. Allzweck-User Agents, die ein hohes Maß an Header-Feld-Konfigurierbarkeit bieten, sollten (ought to) Benutzer über den Verlust der Privatsphäre informieren, der auftreten könnte, wenn zu viele Details bereitgestellt werden. Als extreme Datenschutzmaßnahme könnten Proxys die proaktiven Verhandlungs-Header-Felder in weitergeleiteten Anfragen filtern.
9.8. Validator-Aufbewahrung (Validator Retention)
Die in Response-Metadaten (Abschnitt 7.2) enthaltenen Validatoren sollten (ought to) von einem Cache nur so lange aufbewahrt werden, wie für die normale Verarbeitung und das Ablaufen der gecachten Antwort erforderlich. Das Aufbewahren von Validatoren über längere Zeiträume kann zu Datenschutzproblemen führen, da alte Validatoren verwendet werden könnten, um die Aktivität eines einzelnen Benutzers über mehrere Anfragen hinweg zu korrelieren, selbst wenn der Server Validator-Werte nicht explizit mit einzelnen Benutzern verknüpft. User Agents, die nicht als Cache fungieren, sollten (ought not to) Validatoren über längere Zeiträume aufbewahren.