CSRF und CORS: Browser-Anfragen richtig absichern

Sie haben eine Web-App mit einer sauberen API erstellt, aber dann bemerken Sie seltsame Anfragen in Ihren Logs – oder schlimmer, ein Sicherheitsscanner markiert Ihre Website wegen CSRF- und CORS-Fehlkonfigurationen. Diese beiden Akronyme werden oft in einen Topf geworfen, aber sie lösen unterschiedliche Probleme. Missverständnisse können Ihre Benutzer gefährden oder legitime Cross-Origin-Anfragen unterbrechen.

In diesem Artikel erklären wir, was CSRF und CORS tatsächlich sind, wie sie mit der Browsersicherheit interagieren, und geben Ihnen konkrete Schritte, um Ihre Anwendungen abzusichern, ohne die Funktionalität zu beeinträchtigen.

Was ist CSRF und warum sollten Sie sich darum kümmern?

Cross-Site Request Forgery (CSRF) ist ein Angriff, bei dem der Browser eines Benutzers dazu verleitet wird, eine Anfrage an eine Website zu senden, bei der er authentifiziert ist. Stellen Sie sich vor, Sie sind bei Ihrer Bank unter bank.com angemeldet. Dann besuchen Sie eine bösartige Website, die ein Image-Tag wie <img src="https://bank.com/transfer?to=attacker&amount=1000"> enthält. Ihr Browser fügt automatisch Ihre Bank-Cookies mit der Anfrage ein, und wenn die Bank keine CSRF-Schutzmaßnahmen hat, wird die Überweisung durchgeführt.

Der entscheidende Punkt: CSRF nutzt das Vertrauen aus, das eine Website in den Browser des Benutzers hat. Der Angreifer muss nicht Ihre Sitzung stehlen; er muss nur Ihren Browser dazu bringen, eine Anfrage in Ihrem Namen zu stellen.

Wie CSRF-Angriffe funktionieren

Damit ein CSRF-Angriff erfolgreich ist, müssen drei Bedingungen erfüllt sein:

• Das Opfer muss authentifiziert sein (z. B. ein gültiges Session-Cookie haben).
• Der Angreifer muss die Struktur der Anfrage kennen (Endpunkt, Parameter).
• Die Anfrage darf keine unvorhersehbaren Parameter enthalten, die der Angreifer nicht erraten kann.

Häufige Ziele sind zustandsändernde Operationen: Ändern der E-Mail-Adresse, Überweisen von Geld, Veröffentlichen von Inhalten oder Ändern von Berechtigungen.

Was ist CORS und warum existiert es?

Cross-Origin Resource Sharing (CORS) ist ein Browser-Mechanismus, der es Webseiten erlaubt oder verbietet, Anfragen an eine andere Domain als die, die die Seite ausgeliefert hat, zu stellen. Es ist eine Erweiterung der Same-Origin-Policy (SOP), die einschränkt, wie ein Dokument oder Skript, das von einem Ursprung geladen wurde, mit Ressourcen eines anderen Ursprungs interagieren kann.

Ohne CORS könnte eine bösartige Website JavaScript verwenden, um Daten von der API Ihrer Bank zu lesen, wenn Sie angemeldet sind. CORS gibt Servern eine Möglichkeit, bestimmte Cross-Origin-Anfragen explizit zu erlauben.

Die Same-Origin-Policy (SOP)

Zwei URLs haben denselben Ursprung, wenn Protokoll, Host und Port identisch sind. Zum Beispiel teilen https://example.com/app und https://example.com/api denselben Ursprung, aber http://example.com (anderes Protokoll) und https://api.example.com (anderer Host) nicht.

SOP verhindert, dass Skripte von einem Ursprung Antworten von einem anderen Ursprung lesen. CORS lockert dies, indem HTTP-Header hinzugefügt werden, die dem Browser mitteilen, ob die Anfrage erlaubt werden soll.

CSRF vs. CORS: Hauptunterschiede

Es ist entscheidend zu verstehen, dass CSRF und CORS keine Gegensätze sind; sie adressieren unterschiedliche Sicherheitsbedenken. CSRF zielt darauf ab, unbefugte zustandsändernde Anfragen zu verhindern, während CORS kontrolliert, welche Ursprünge Antworten lesen dürfen.

Wie man sich gegen CSRF verteidigt

Es gibt mehrere bewährte Strategien zur Abschwächung von CSRF. Sie brauchen nicht alle, aber eine mehrschichtige Verteidigung ist ratsam.

1. Anti-CSRF-Tokens verwenden

Die robusteste Verteidigung besteht darin, ein eindeutiges, unvorhersehbares Token in jede zustandsändernde Anfrage aufzunehmen. Der Server validiert das Token vor der Verarbeitung. Tokens sollten an die Sitzung des Benutzers gebunden und nicht in URLs offengelegt werden (um ein Leck über Referrer-Header zu vermeiden).

// Beispiel: Generieren und Validieren eines CSRF-Tokens in Node.js/Express
const csrf = require('csurf');
const csrfProtection = csrf({ cookie: true });

app.get('/form', csrfProtection, (req, res) => {
  res.render('form', { csrfToken: req.csrfToken() });
});

app.post('/process', csrfProtection, (req, res) => {
  // Token wird automatisch validiert
  res.send('OK');
});

2. SameSite-Cookies setzen

Moderne Browser unterstützen das SameSite-Attribut für Cookies. Wenn es auf Lax oder Strict gesetzt ist, verhindert der Browser das Senden von Cookies bei Cross-Site-Anfragen, was viele CSRF-Angriffe blockiert. Lax erlaubt Cookies bei Top-Level-Navigationen (z. B. Klicken auf einen Link), während Strict alle Cross-Site-Anfragen blockiert.

Set-Cookie: sessionId=abc123; SameSite=Lax; Secure; HttpOnly

3. Origin- und Referer-Header überprüfen

Überprüfen Sie den Origin- oder Referer-Header bei eingehenden Anfragen. Wenn sie nicht mit Ihrer erwarteten Domain übereinstimmen, lehnen Sie die Anfrage ab. Dies ist eine einfache, aber effektive zusätzliche Schutzschicht.

4. Benutzerdefinierte Header für AJAX verwenden

Wenn Ihre API über JavaScript genutzt wird, verlangen Sie einen benutzerdefinierten Header wie X-Requested-With. Browser erzwingen CORS-Preflight für benutzerdefinierte Header, sodass ein einfaches Formular-POST von einer bösartigen Website ihn nicht enthalten wird.

CORS richtig konfigurieren

CORS-Fehlkonfigurationen können ebenfalls zu Sicherheitsproblemen führen. Der häufigste Fehler ist, Access-Control-Allow-Origin: * zu setzen und gleichzeitig Anmeldeinformationen zu erlauben. Diese Kombination ist von Browsern verboten, aber Entwickler versuchen manchmal, sie unsicher zu umgehen.

Best Practices für CORS-Header

• Geben Sie genaue Ursprünge anstelle von Wildcards an, wenn Anmeldeinformationen beteiligt sind.
• Beschränken Sie erlaubte Methoden auf das, was Ihre API unterstützt (z. B. GET, POST).
• Beschränken Sie erlaubte Header auf die, die Ihre App tatsächlich verwendet.
• Setzen Sie Access-Control-Max-Age, um Preflight-Antworten zu cachen und Overhead zu reduzieren.
• Vermeiden Sie es, den Origin-Header blind zurückzugeben; validieren Sie ihn gegen eine Whitelist.

# Beispiel: Nginx-Konfiguration für CORS
location /api/ {
  if ($http_origin ~* (https://(app|admin)\.example\.com)) {
    add_header 'Access-Control-Allow-Origin' $http_origin;
    add_header 'Access-Control-Allow-Credentials' 'true';
    add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
    add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';
  }
  if ($request_method = 'OPTIONS') {
    return 204;
  }
}

Denken Sie daran, dass CORS vom Browser durchgesetzt wird, nicht vom Server. Es ist kein Ersatz für Authentifizierung oder Autorisierung; es ist eine Möglichkeit, die Same-Origin-Policy sicher zu lockern.

Alles zusammenfügen

Die Absicherung von Browser-Anfragen erfordert einen mehrschichtigen Ansatz. Hier ist eine kurze Checkliste:

1. Verwenden Sie Anti-CSRF-Tokens für alle zustandsändernden Operationen.
2. Setzen Sie SameSite-Cookies auf Lax oder Strict.
3. Validieren Sie Origin/Referer-Header auf dem Server.
4. Konfigurieren Sie CORS präzise: Whitelist von Ursprüngen, Einschränkung von Methoden und Vermeidung von Wildcards mit Anmeldeinformationen.
5. Testen Sie regelmäßig Ihre App mit Sicherheitsscannern und manuellen Checks.

Indem Sie die unterschiedlichen Rollen von CSRF und CORS verstehen, können Sie häufige Fallstricke vermeiden und eine sicherere Webanwendung erstellen.

FAQ

Kann CORS CSRF-Angriffe verhindern?

Nein, CORS verhindert keine CSRF. CSRF-Angriffe basieren nicht auf dem Lesen von Antworten; sie lösen einfach Anfragen aus. CORS kontrolliert, welche Ursprünge Antworten lesen dürfen, aber es blockiert nicht das Senden der Anfrage. Um CSRF zu verhindern, benötigen Sie Tokens, SameSite-Cookies oder Ursprungsvalidierung.

Ist es sicher, Access-Control-Allow-Origin auf '*' zu setzen?

Es ist nur dann sicher, '*' zu setzen, wenn Ihre API keine Anmeldeinformationen (Cookies, HTTP-Authentifizierung) verwendet. Wenn Anmeldeinformationen beteiligt sind, lehnen Browser die Antwort ab. Für authentifizierte APIs geben Sie immer genaue Ursprünge an.

Brauche ich CSRF-Schutz, wenn ich JWT in Authorization-Headern verwende?

Wenn Sie JWTs in Cookies speichern, benötigen Sie weiterhin CSRF-Schutz, da Cookies automatisch gesendet werden. Wenn Sie JWTs im Speicher speichern und sie über den Authorization-Header senden, ist CSRF kein Problem, da der Angreifer keine benutzerdefinierten Header cross-origin setzen kann. Sie müssen jedoch gegen XSS schützen, um das Token sicher zu halten.

Bereit, die CORS-Header Ihrer API zu testen? Verwenden Sie unseren Nginx Log Analyzer, um Anforderungsmuster zu überprüfen und verdächtige Cross-Origin-Versuche zu erkennen.