Verhindern Sie CSRF-, XSSI- und ursprungsübergreifende Informationslecks.
Warum sollten Sie Ihre Webressourcen isolieren?
Viele Webanwendungen sind anfällig für Cross-Origin-Angriffe wie Cross-Site Request Forgery (CSRF), Cross-Site Script Inclusion (XSSI), Timing-Angriffe, Cross-Origin Information Leaks oder Spectre-Angriffe (spekulative Execution Side-Channel).
Metadatenabruf-Anfrageheader ermöglichen es Ihnen, einen starken, gestaffelten Mechanismus zur Verteidigung bereitzustellen – eine Richtlinie zur Ressourcenisolierung –, um Ihre Anwendung vor diesen gängigen ursprungsübergreifenden Angriffen zu schützen.
Ressourcen, die von einer bestimmten Webanwendung verfügbar gemacht werden, werden häufig nur von der Anwendung selbst und nicht von anderen Websites geladen. In solchen Fällen ist das Bereitstellen einer Ressourcenisolierungsrichtlinie auf der Grundlage von Fetch Metadata-Anfrageheadern wenig Aufwand und schützt die Anwendung gleichzeitig vor websiteübergreifenden Angriffen.
Browserkompatibilität
Anfrageheader für Metadatenabruf werden in allen modernen Browser-Engines unterstützt.
Hintergrund
Viele websiteübergreifende Angriffe sind möglich, da das Web standardmäßig offen ist und Ihr Anwendungsserver sich nicht so einfach vor der Kommunikation von externen Anwendungen schützen kann. Ein typischer ursprungsübergreifender Angriff ist die Cross-Site Request Forgery (CSRF), bei der ein Angreifer einen Nutzer auf eine Website lockt, die er verwaltet, und dann ein Formular an den Server sendet, auf dem er angemeldet ist. Da der Server nicht feststellen kann, ob die Anfrage von einer anderen Domain (websiteübergreifend) stammt, und der Browser automatisch Cookies an websiteübergreifende Anfragen anhängt, führt der Server die vom Angreifer angeforderte Aktion im Namen des Nutzers aus.
Andere websiteübergreifende Angriffe wie Cross-Site-Script-Inclusion (XSSI) oder ursprungsübergreifende Informationslecks ähneln CSRF und beruhen darauf, dass Ressourcen einer Opferanwendung in ein von einem Angreifer kontrolliertes Dokument geladen werden und Informationen über die betroffenen Anwendungen preisgegeben werden. Da Anwendungen vertrauenswürdige Anfragen nicht problemlos von nicht vertrauenswürdigen Anfragen unterscheiden können, können sie keinen schädlichen websiteübergreifenden Traffic verwerfen.
Jetzt neu: Metadaten abrufen
Anforderungsheader für den Metadatenabruf sind eine neue Sicherheitsfunktion für Webplattformen, mit der sich Server vor ursprungsübergreifenden Angriffen schützen sollen. Indem in einem Satz von Sec-Fetch-*-Headern Informationen zum Kontext einer HTTP-Anfrage bereitgestellt werden, kann der antwortende Server vor der Verarbeitung der Anfrage Sicherheitsrichtlinien anwenden. So können Entwickler je nach Art und Kontext, in dem sie verwendet wird, eine Anfrage annehmen oder ablehnen. So ist es möglich, nur auf legitime Anfragen ihrer eigenen Anwendung zu reagieren.
Sec-Fetch-*-Headern bereitgestellt wird, abgelehnt werden.
Sec-Fetch-Site
Sec-Fetch-Site teilt dem Server mit, von welcher Website die Anfrage gesendet wurde. Der Browser legt diesen Wert auf einen der folgenden Werte fest:
same-origin, wenn die Anfrage von Ihrer eigenen Anwendung gestellt wurde (z.B.site.example)same-site, wenn die Anfrage von einer Subdomain Ihrer Website stammt (z.B.bar.site.example)none, wenn die Anfrage explizit durch die Interaktion eines Nutzers mit dem User-Agent ausgelöst wurde (z.B. Klicken auf ein Lesezeichen)cross-site, wenn die Anfrage von einer anderen Website gesendet wurde (z.B.evil.example)
Sec-Fetch-Mode
Sec-Fetch-Mode gibt den Modus der Anfrage an. Dies entspricht in etwa dem Typ der Anfrage und ermöglicht es Ihnen, Ressourcenladevorgänge von Navigationsanfragen zu unterscheiden. Das Ziel navigate steht beispielsweise für eine Navigationsanfrage der obersten Ebene, während no-cors Ressourcenanfragen wie das Laden eines Bildes angibt.
Sec-Fetch-Dest
Sec-Fetch-Dest gibt das Ziel einer Anfrage an, z.B. wenn ein script- oder img-Tag dazu geführt hat, dass eine Ressource vom Browser angefordert wurde.
Abruf von Metadaten zum Schutz vor ursprungsübergreifenden Angriffen verwenden
Die zusätzlichen Informationen, die diese Anfrageheader liefern, sind recht einfach, aber der zusätzliche Kontext ermöglicht es Ihnen, mit nur wenigen Codezeilen eine leistungsstarke Sicherheitslogik auf Serverseite zu erstellen, die auch als Ressourcenisolierungsrichtlinie bezeichnet wird.
Richtlinie zur Ressourcenisolierung implementieren
Mit einer Richtlinie zur Ressourcenisolierung wird verhindert, dass Ihre Ressourcen von externen Websites angefordert werden. Durch das Blockieren solcher Zugriffe lassen sich häufige websiteübergreifende Sicherheitslücken wie CSRF, XSSI, Timing-Angriffe und ursprungsübergreifende Datenlecks minimieren. Diese Richtlinie kann für alle Endpunkte Ihrer Anwendung aktiviert werden und lässt alle Ressourcenanfragen von Ihrer eigenen Anwendung sowie direkte Navigationen (über eine HTTP-GET-Anfrage) zu. Für Endpunkte, die in einem websiteübergreifenden Kontext geladen werden sollen (z.B. mit CORS geladene Endpunkte), kann diese Logik deaktiviert werden.
Schritt 1: Anfragen von Browsern zulassen, die keine Abrufmetadaten senden
Da nicht alle Browser das Abrufen von Metadaten unterstützen, müssen Sie Anfragen ohne Sec-Fetch-*-Header zulassen, indem Sie prüfen, ob sec-fetch-site vorhanden ist.
if not req['sec-fetch-site']:
return True # Allow this request
Schritt 2: Von derselben Website und vom Browser initiierte Anfragen zulassen
Alle Anfragen, die nicht aus einem ursprungsübergreifenden Kontext wie evil.example stammen, werden zugelassen. Im Einzelnen sind dies folgende Anfragen:
- Ihre Anfragen stammen aus Ihrer eigenen Anwendung (z.B. ist eine Same-Origin-Anfrage, bei der
site.example-Anfragen ansite.example/foo.jsongesendet werden, immer zulässig). - Sie stammen aus Ihren Subdomains.
- werden explizit durch die Interaktion eines Nutzers mit dem User-Agent verursacht, z. B. durch direkte Navigation oder durch Klicken auf ein Lesezeichen.
if req['sec-fetch-site'] in ('same-origin', 'same-site', 'none'):
return True # Allow this request
Schritt 3: Einfache Navigation auf oberster Ebene und iFrame zulassen
Damit Ihre Website weiterhin über andere Websites verlinkt werden kann, müssen Sie die einfache Navigation auf oberster Ebene (HTTP GET) zulassen.
if req['sec-fetch-mode'] == 'navigate' and req.method == 'GET'
# <object> and <embed> send navigation requests, which we disallow.
and req['sec-fetch-dest'] not in ('object', 'embed'):
return True # Allow this request
Schritt 4: Endpunkte deaktivieren, die für websiteübergreifenden Traffic bestimmt sind (optional)
In einigen Fällen stellt Ihre Anwendung möglicherweise Ressourcen bereit, die websiteübergreifend geladen werden sollen. Diese Ressourcen müssen pro Pfad oder Endpunkt ausgenommen werden. Beispiele für solche Endpunkte sind:
- Endpunkte, auf die ursprungsübergreifend zugegriffen werden soll: Wenn Ihre Anwendung Endpunkte bereitstellt, für die
CORSaktiviert ist, müssen Sie die Ressourcenisolation für diese Endpunkte explizit deaktivieren, damit websiteübergreifende Anfragen an diese Endpunkte weiterhin möglich sind. - Öffentliche Ressourcen (z.B. Bilder, Stile usw.): Alle öffentlichen und nicht authentifizierten Ressourcen, die ursprungsübergreifend von anderen Websites geladen werden können, können ebenfalls ausgenommen werden.
if req.path in ('/my_CORS_endpoint', '/favicon.png'):
return True
Schritt 5: Alle anderen websiteübergreifenden und nicht Navigationsanfragen ablehnen
Alle anderen websiteübergreifenden Anfragen werden von dieser Richtlinie zur Ressourcenisolierung abgelehnt und schützen so Ihre Anwendung vor gängigen websiteübergreifenden Angriffen.
Beispiel:Der folgende Code zeigt eine vollständige Implementierung einer robusten Ressourcenisolierungsrichtlinie auf dem Server oder als Middleware, um potenziell schädliche websiteübergreifende Ressourcenanfragen abzulehnen und gleichzeitig einfache Navigationsanfragen zu ermöglichen:
# Reject cross-origin requests to protect from CSRF, XSSI, and other bugs
def allow_request(req):
# Allow requests from browsers which don't send Fetch Metadata
if not req['sec-fetch-site']:
return True
# Allow same-site and browser-initiated requests
if req['sec-fetch-site'] in ('same-origin', 'same-site', 'none'):
return True
# Allow simple top-level navigations except <object> and <embed>
if req['sec-fetch-mode'] == 'navigate' and req.method == 'GET'
and req['sec-fetch-dest'] not in ('object', 'embed'):
return True
# [OPTIONAL] Exempt paths/endpoints meant to be served cross-origin.
if req.path in ('/my_CORS_endpoint', '/favicon.png'):
return True
# Reject all other requests that are cross-site and not navigational
return False
Ressourcenisolierungsrichtlinie bereitstellen
- Installieren Sie ein Modul wie das obige Code-Snippet, um das Verhalten Ihrer Website zu protokollieren und zu überwachen. So sorgen Sie dafür, dass die Einschränkungen keinen legitimen Traffic beeinträchtigen.
- Beheben Sie potenzielle Verstöße, indem Sie legitime ursprungsübergreifende Endpunkte ausnehmen.
- Richtlinie durch Löschen nicht konformer Anfragen erzwingen
Richtlinienverstöße erkennen und beheben
Es wird empfohlen, Ihre Richtlinie ohne Nebeneffekte zu testen. Aktivieren Sie dazu die Richtlinie zuerst im Berichterstellungsmodus in Ihrem serverseitigen Code. Alternativ können Sie diese Logik in Middleware oder in einem Reverse-Proxy implementieren, der alle Verstöße protokolliert, die Ihre Richtlinie möglicherweise bei der Anwendung auf Produktionstraffic verursacht.
Unsere Erfahrung bei der Einführung einer Richtlinie zur Isolierung von Metadatenressourcen bei Google hat gezeigt, dass die meisten Anwendungen standardmäßig mit einer solchen Richtlinie kompatibel sind und nur selten Endpunkte ausnehmen müssen, um websiteübergreifenden Traffic zuzulassen.
Ressourcenisolierungsrichtlinie erzwingen
Nachdem Sie sich vergewissert haben, dass Ihre Richtlinie keine Auswirkungen auf legitimen Produktionstraffic hat, können Sie Einschränkungen erzwingen. So sorgen Sie dafür, dass keine anderen Websites Ihre Ressourcen anfordern können und Ihre Nutzer vor websiteübergreifenden Angriffen geschützt sind.
Weitere Informationen
- Spezifikation für W3C Fetch Metadata Request Headers
- Playground für Metadaten abrufen
- Google I/O Talk: Securing Web Apps with Modern Platform Features (Google Präsentationen)