CORS-Fehlkonfiguration (CWE-942): Wie gespiegelte Origins Daten preisgeben und wie man sie behebt

Kernkonzepte & Begriffe

Same-Origin-Policy

Browser lassen ein Skript nur Antworten seiner eigenen Origin (Schema, Host und Port) lesen. CORS-Antwortheader sind der Weg, auf dem ein Server diese Regel bewusst für benannte Origins lockert.

Access-Control-Allow-Origin mit Credentials

Nennt die Antwort die Origin des Aufrufers in Access-Control-Allow-Origin und sendet Access-Control-Allow-Credentials: true, kann ein Skript auf dieser Origin Antworten auf Requests lesen, die die Cookies des Nutzers trugen. Browser lehnen * zusammen mit Credentials ab, deshalb spiegeln falsch konfigurierte Server die Origin.

Gespiegelte Origin und Suffix-Prüfung

Den Origin-Header in die Antwort zu kopieren vertraut jeder Website. Prüfungen wie endsWith('example.com'), Teilstring-Suchen oder reguläre Ausdrücke ohne Anker und mit unmaskierten Punkten akzeptieren auch https://attacker-example.com.

Die null-Origin

Sandbox-iframes, data:-URLs und manche Weiterleitungen senden Origin: null. Jeder Angreifer kann sie erzeugen, null zu erlauben heißt also, alle zu erlauben.

Vary: Origin

Hängt Access-Control-Allow-Origin vom Request ab, muss die Antwort Vary: Origin tragen, damit gemeinsame Caches die CORS-Header einer Origin nicht an eine andere ausliefern. Das Paket cors ergänzt ihn bei dynamischen Origins.

Schritt-für-Schritt Angriffsablauf

Quellcode: Verwundbar vs. Sicher

// server.js: jede Origin auf example.com, dazu null, darf mit Cookies lesen
import express from 'express';
import cors from 'cors';
import { accountFor, requireSession } from './account.js';

const app = express();

// true lässt cors die Origin des Aufrufers samt Credentials spiegeln
app.use(cors({
  origin: (origin, callback) => callback(null, !origin || origin === 'null' || origin.endsWith('example.com')),
  credentials: true,
}));

// private Kontodaten, lesbar für die erlaubten Origins
app.get('/api/account', requireSession, (req, res) => {
  res.json(accountFor(req.session.userId));
});

// server.js: zwei exakte Origins, sonst nichts
import express from 'express';
import cors from 'cors';
import { accountFor, requireSession } from './account.js';

const app = express();

// vollständige Origins mit Schema und Host, exakt verglichen
const ALLOWED_ORIGINS = new Set(['https://app.example.com', 'https://admin.example.com']);

// unbekannte oder fehlende Origin bekommt keine CORS-Header; cors ergänzt Vary: Origin
app.use(cors({
  origin: (origin, callback) => callback(null, origin !== undefined && ALLOWED_ORIGINS.has(origin)),
  credentials: true,
  methods: ['GET', 'POST'],
  maxAge: 600,
}));

// personenbezogene Daten landen nie in gemeinsamen Caches
app.get('/api/account', requireSession, (req, res) => {
  res.set('Cache-Control', 'no-store');
  res.json(accountFor(req.session.userId));
});

Checkliste für Engineering & Systemsicherheit

• Eine Allowlist vollständiger Origins (Schema, Host und Port) mit exakter Übereinstimmung führen und per Set-Abfrage vergleichen; Origin nie spiegeln und keine Suffix-, Teilstring- oder ankerlosen Regex-Prüfungen verwenden.
• Die null-Origin nie erlauben und Credentials nie für eine Origin erlauben, die Sie nicht kontrollieren.
• Vary: Origin senden, wann immer Access-Control-Allow-Origin pro Request gewählt wird, und Cache-Control: no-store bei Antworten mit personenbezogenen Daten.
• Sitzungscookies auf SameSite=Lax oder Strict setzen, damit websiteübergreifende Requests sie nicht mitsenden.
• Einen CI-Test ergänzen, der Origin: https://attacker.example und Origin: null an authentifizierte Routen sendet und fehlschlägt, wenn Access-Control-Allow-Origin zurückkommt.

Quellen

• CWE-942: Permissive Cross-domain Policy with Untrusted Domains
• MDN — Cross-Origin Resource Sharing (CORS)
• expressjs/cors — configuration options
• PortSwigger Research — Exploiting CORS misconfigurations for Bitcoins and bounties (2016)