4. Sicherheitsüberlegungen

Anwendungen, die neue Well-Known-URIs einführen, sowie Administratoren, die sie bereitstellen, müssen mehrere sicherheitsrelevante Aspekte bedenken, darunter (ohne Beschränkung auf diese) die Offenlegung sensibler Daten, Denial-of-Service-Angriffe (zusätzlich zu normalen Lastproblemen), Server- und Client-Authentifizierung, Anfälligkeit für DNS-Rebinding-Angriffe sowie Angriffe, bei denen begrenzter Serverzugriff die Art und Weise beeinflussen kann, wie Well-Known-URIs ausgeliefert werden.

[RFC3552] enthält Beispiele für mögliche Sicherheitsüberlegungen, die für Anwendungsprotokolle und Administratoren bei der Bereitstellung relevant sein können.

4.1. Schutz well-known-Ressourcen

Well-known locations repräsentieren faktisch die gesamte Origin; Serverbetreiber sollten daher angemessen steuern, wer dorthin schreiben darf. Das gilt besonders, wenn mehrere Entitäten auf derselben Origin colocated sind. Selbst bei Origins, die von einer einzigen Entität kontrolliert werden und diese vertreten, ist darauf zu achten, dass Schreibzugriff auf well-known locations weder über die Serverkonfiguration nach außen noch lokal über Implementierungsrechte (z. B. auf einem Dateisystem) unbeabsichtigt gewährt wird.

4.2. Wechselwirkung mit dem Webbrowsen

Anwendungen, die Well-Known-URIs in http- oder https-URLs nutzen, müssen wissen, dass well-known-Ressourcen für Webbrowser erreichbar sind und daher von Inhalten aus anderen Teilen derselben Origin manipuliert werden können. Kann ein Angreifer Inhalte einschleusen (z. B. über eine Cross-Site-Scripting-Schwachstelle), kann er potenziell beliebige Anfragen an die well-known-Ressource stellen.

HTTP und HTTPS nutzen Origins außerdem als Sicherheitsgrenze für viele andere Mechanismen, darunter (ohne Beschränkung) Cookies [RFC6265], Web Storage [WEBSTORAGE] und verschiedene Fähigkeiten.

Eine Anwendung, die well-known locations definiert, sollte nicht annehmen, dass sie alleinigen Zugriff auf diese Mechanismen hat oder die einzige Anwendung auf der Origin ist. Je nach Art der Anwendung können Abhilfen u. a. umfassen:

Verschlüsselung sensibler Informationen
Flexibilität bei der Verwendung von Identifikatoren (z. B. Cookienamen), um Kollisionen mit anderen Anwendungen zu vermeiden
Verwendung des HttpOnly-Flags bei Cookies, damit Cookies nicht an Browserskriptsprachen exponiert werden [RFC6265]
Verwendung des Path-Parameters bei Cookies, damit sie für andere Teile der Origin nicht verfügbar sind [RFC6265]
Verwendung von X-Content-Type-Options: nosniff [FETCH], damit Inhalte unter Angreiferkontrolle nicht in eine Form gebracht werden können, die der Webbrowser als aktiven Inhalt interpretiert

Weitere gute Praktiken:

Verwendung eines anwendungsspezifischen Medientyps im Content-Type-Headerfeld und Anforderung, dass Clients fehlschlagen, wenn er nicht verwendet wird
Verwendung von Content-Security-Policy [CSP], um die Fähigkeiten aktiven Inhalts (wie HTML [HTML5]) einzuschränken und Cross-Site-Scripting-Angriffe zu mildern
Verwendung von Referrer-Policy [REFERRER-POLICY], um zu verhindern, dass sensible Daten in URLs im Referer-Anfrageheaderfeld preisgegeben werden
Vermeidung von Komprimierung bei sensiblen Informationen (z. B. Authentifizierungstoken, Passwörter), da die Skriptumgebung von Webbrowsern es einem Angreifer erlaubt, den Kompressionsraum wiederholt zu sondieren; hat er Zugriff auf den Kommunikationspfad, kann er diese Fähigkeit nutzen, um diese Informationen zu rekonstruieren.

4.3. Abgrenzung von Anwendungen

Dieses Memo legt weder den Geltungsbereich der aus einem Well-Known-URI gewonnenen Informationen fest noch, wie ein Well-Known-URI für eine bestimmte Anwendung gefunden wird.

Jede Anwendung, die diesen Mechanismus nutzt, muss beides definieren; andernfalls können Sicherheitsprobleme durch Implementierungsabweichungen und Unklarheiten über Grenzen zwischen Anwendungen entstehen.

Metadaten aus einem Well-Known-URI auf Ressourcen anzuwenden, die nicht auf derselben Origin colocated sind, birgt administrative und sicherheitsrelevante Risiken. Beispielsweise setzt die Zulassung, dass https://example.com/.well-known/example Richtlinien für https://department.example.com, https://www.example.com oder sogar https://www.example.com:8000 festlegt, eine Beziehung zwischen Hosts voraus, die möglicherweise nicht besteht, und gibt damit potenziell einem Angreifer die Kontrolle.

Ebenso kann die Vorgabe, einen Well-Known-URI auf einem bestimmten Hostnamen zum Hochfahren eines Protokolls zu verwenden, eine große Zahl unerwünschter Anfragen auslösen. Wird beispielsweise ein well-known-HTTPS-URI genutzt, um Richtlinien für einen separaten Dienst wie E-Mail zu finden, kann dies zu einer Flut von Anfragen an Webserver führen, selbst wenn diese den Well-Known-URI nicht implementieren. Solche unerwünschten Anfragen können einer Denial-of-Service-Attacke ähneln.

4.4. Verborgene Fähigkeiten

Anwendungen mit well-known locations sollten bedenken, dass einige Serveradministratoren ihrer Existenz möglicherweise nicht bewusst sind (insbesondere auf Betriebssystemen, die Verzeichnisse verbergen, deren Namen mit . beginnen). Das bedeutet: Hat ein Angreifer Schreibzugriff auf das Verzeichnis .well-known, kann er dessen Inhalt kontrollieren, möglicherweise ohne dass der Administrator es merkt.