Gemeinsam mit unserem Partner, der SnapSec GmbH und deren blacklens.io Plattform veröffentlichen wir heute eine Responsible Disclosure zu einer CORS-Schwachstelle im Azure Application Routing Add-on für Azure Kubernetes Service (AKS). Während der ursprüngliche Bericht von SnapSec den Pentesting-Fokus beleuchtet, möchten wir als Softwareentwicklungsunternehmen die Entwicklerperspektive aufzeigen: Was bedeutet diese Schwachstelle für uns als Entwickler? Welche fundamentalen Prinzipien wurden hier verletzt? Und wie schützen wir unsere Anwendungen besser?

Das Problem in Kürze

Die Schwachstelle betrifft den verwalteten NGINX Ingress Controller in Azure Application Routing. Unter bestimmten Bedingungen validiert dieser die Origin-Header bei CORS-Anfragen nicht korrekt – konkret wenn mehrere Origin-Werte übermittelt werden und ein legitimer Origin an zweiter Stelle steht.

Das klingt zunächst technisch und abstrakt. Doch die Konsequenzen können gravierend sein: Von der Umgehung von Origin-basierten Authentifizierungen über Token-Diebstahl bis hin zu unautorisiertem API-Zugriff in Microservice-Architekturen.

Was ist CORS und warum ist es wichtig?

CORS (Cross-Origin Resource Sharing) ist ein Browser-Sicherheitsmechanismus, der Webservern erlaubt zu kontrollieren, welche Origins (Domains) auf ihre Ressourcen zugreifen dürfen. Ohne CORS könnte jede beliebige Website AJAX-Anfragen an Ihre API senden und dabei die Cookies des eingeloggten Users mitschicken.

CORS Flow: So sollte es funktionieren

1. Browser sendet Preflight-Request (OPTIONS) mit Origin: https://trusted-app.com
2. Server prüft den Origin gegen Whitelist
3. Server antwortet mit Access-Control-Allow-Origin: https://trusted-app.com
4. Browser erlaubt die eigentliche Anfrage

Wichtig: CORS ist ein Browser-Feature. Server-zu-Server-Kommunikation ist nicht betroffen. Das ist ein entscheidendes Detail, das wir später noch benötigen werden.

Die Schwachstelle: Header-Injection via Multiple Origins

Normalerweise sendet ein Browser genau einen Origin-Header. Doch HTTP erlaubt es, Header mehrfach zu setzen oder mehrere Werte kommasepariert zu übergeben. Genau hier liegt das Problem.

✅ Korrektes Verhalten (Angriff schlägt fehl)

Wenn ein Angreifer nur einen bösartigen Origin sendet:

GET /api/secrets HTTP/1.1
Host: vulnerable-app.azurewebsites.net
Origin: https://evil.com

Ergebnis: Der Ingress lehnt die Anfrage korrekt ab, da evil.com nicht in der Whitelist steht.

🛑 Fehlverhalten (Angriff erfolgreich)

Wenn der Angreifer jedoch zuerst den bösartigen Origin und danach einen legitimen Origin sendet:

GET /api/secrets HTTP/1.1
Host: vulnerable-app.azurewebsites.net
Origin: https://evil.com, https://trusted-app.com

Oder mit zwei separaten Header-Zeilen:

GET /api/secrets HTTP/1.1
Host: vulnerable-app.azurewebsites.net
Origin: https://evil.com
Origin: https://trusted-app.com

Ergebnis: Der Ingress akzeptiert die Anfrage und reflektiert beide Origins in der Antwort:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://evil.com, https://trusted-app.com
Access-Control-Allow-Credentials: true
Content-Type: application/json

{"secret": "sensitive-data-here"}

Dies verstößt gegen die W3C CORS-Spezifikation, die nur einen einzigen Origin oder * (alle) erlaubt.

Die technische Ursache

Die Validierungslogik im Azure Application Routing Ingress prüft offenbar, ob mindestens ein gültiger Origin in der Liste vorhanden ist – unabhängig von der Position. Statt die gesamte Anfrage abzulehnen, reflektiert der Ingress alle übergebenen Origins zurück.

Warum moderne Browser trotzdem schützen

Die gute Nachricht: Moderne Browser blockieren solche Antworten, da sie der CORS-Spezifikation widersprechen. Chrome, Firefox und Safari würden diese Antwort verwerfen und JavaScript den Zugriff auf die Daten verweigern.

Die schlechte Nachricht: Nicht alle Clients sind Browser.

Reale Angriffsszenarien

In folgenden Szenarien kann die Schwachstelle trotzdem ausgenutzt werden:

• Microservice-Architekturen: Service A vertraut auf CORS-Header von Service B zur Authentifizierung
• API-Gateways: Gateway routet Anfragen basierend auf Origin-Validierung
• Server-seitige Request-Validierung: Backend prüft Access-Control-Allow-Origin für Trust-Entscheidungen
• Cross-Tenant Isolation: Multi-Tenant-Apps verwenden Origin zur Tenant-Trennung
• OAuth/OIDC Flows: Token-Endpoints verlassen sich auf Origin-Validierung

Ein konkretes Beispiel ist die EmojiDeploy-Schwachstelle (CVE-2023-36414), bei der CORS-Misconfiguration zu Remote Code Execution in Azure Web Services führte – bewertet mit einem $30.000 Bug Bounty.

Was Entwickler daraus lernen sollten

Diese Schwachstelle ist ein Lehrbuchbeispiel für mehrere fundamentale Sicherheitsprinzipien, die verletzt wurden:

1. Defense in Depth

Das wohl wichtigste Prinzip: Niemals auf einen einzigen Sicherheitsmechanismus vertrauen.

CORS ist ein Browser-Sicherheitsmechanismus, keine serverseitige Authentifizierung. Entwickler sollten auf Backend-Ebene immer folgende zusätzliche Kontrollen implementieren:

• JWT- oder Session-basierte Authentifizierung unabhängig von Origin-Headern
• API Keys oder OAuth 2.0 Tokens für Service-zu-Service-Kommunikation
• Explizite Authorization Checks auf Ressourcen-Ebene
• Rate Limiting und Request Validation als zusätzliche Schutzmechanismen

2. Never Trust the Client (Secure Coding Prinzip)

HTTP-Header können immer vom Client manipuliert werden. Dies gilt speziell für:

• Origin
• Referer
• User-Agent
• X-Forwarded-For
• aber auch alle anderen HTTP-Header

Entwickler dürfen niemals Sicherheitsentscheidungen ausschließlich auf Basis von Client-kontrollierten Daten treffen. Stattdessen sollten kryptographisch signierte und validierte Tokens (z.B. JWT) verwendet werden:

// ✅ JWT Validierung mit Signature Check
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidIssuer = "https://trusted-issuer.com",
            ValidateAudience = true,
            ValidAudience = "my-api",
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true,
            IssuerSigningKey = new SymmetricSecurityKey(
                Encoding.UTF8.GetBytes(Configuration["Jwt:SecretKey"]))
        };
    });

3. Input Validation auf allen Ebenen

Die Schwachstelle zeigt, dass unerwartete oder manipulierte Inputs zu Sicherheitsproblemen führen können. In diesem Fall waren es mehrere Origin-Werte, die die Validierungslogik aushebelten.

Best Practices für Input Validation:

• Whitelist statt Blacklist: Nur explizit erlaubte Werte akzeptieren
• Strict Parsing: Unerwartete Formate ablehnen (z.B. mehrfache Header-Werte)
• Normalisierung: Inputs in ein einheitliches Format bringen vor der Validierung
• Fail Secure: Bei Validierungsfehlern immer ablehnen, niemals „durchwinken“

4. Zero Trust Architektur

In modernen Cloud- und Microservice-Architekturen sollte jede Verbindung authentifiziert und autorisiert werden – auch innerhalb des eigenen Netzwerks.

Konkret bedeutet das:

• Mutual TLS (mTLS) für Service-zu-Service-Kommunikation
• Service Mesh mit integrierten Security Policies
• Workload Identities statt API Keys (z.B. Azure Managed Identities, AWS IAM Roles)
• Policy Enforcement Points auf jeder Netzwerk-Ebene

Was betroffene Teams jetzt tun sollten

Wenn Sie Azure Application Routing mit aktiviertem CORS in Produktion einsetzen, empfehlen wir folgende Schritte:

Kurzfristig: Zusätzliche Validierung implementieren

1. Backend-Validierung hinzufügen: Implementieren Sie eine zusätzliche Origin-Validierung in Ihrer Anwendung (siehe Code-Beispiel oben)
2. Authentication verstärken: Stellen Sie sicher, dass sensible Endpoints niemals nur auf CORS vertrauen
3. Monitoring aktivieren: Loggen Sie verdächtige Anfragen mit mehrfachen Origin-Headern
4. WAF Regeln erweitern: Falls vorhanden, Azure Application Gateway oder Azure Front Door mit Custom Rules konfigurieren

Mittelfristig: Migration planen

Microsoft hat angekündigt, dass der Ingress-NGINX Controller ab März 2026 das End-of-Life erreicht und der Azure-Support für Application Routing am 30. November 2026 endet:

• Kubernetes Blog: Ingress-NGINX Retirement
• Azure Updates: Application Routing Deprecation

Betroffene Teams sollten eine Migration auf alternative Ingress-Lösungen oder die Kubernetes Gateway API evaluieren:

• NGINX Ingress Controller (Community-Version) mit selbstverwalteten Updates
• Traefik als moderne Alternative mit integrierter Service Mesh-Unterstützung
• Istio Gateway für umfassende Zero-Trust-Architekturen
• Gateway API als Kubernetes-nativer Standard (aktuell Beta)

Langfristig: Security Testing etablieren

Diese Schwachstelle wurde durch manuelle Penetrationstests entdeckt – ein wichtiger Reminder, dass automatisierte Scans allein nicht ausreichen.

In Zusammenarbeit mit blacklens.io bieten wir unseren Kunden kontinuierliches 24/7-Scanning und optionales Pentesting-as-a-Service an. Die Plattform hilft dabei:

• Schwachstellen in externer, interner und Cloud-Infrastruktur frühzeitig zu erkennen
• Reale Angriffspfade sichtbar zu machen (z.B. Active Directory Misconfigurations)
• Kubernetes- und API-Infrastruktur kontinuierlich zu überwachen
• Die Angriffsoberfläche zu visualisieren und Risiken zu priorisieren

Unsere Perspektive als Entwickler

Diese Schwachstelle hat uns (glücklicherweise) nicht direkt betroffen, da wir in unseren Projekten mehrschichtige Sicherheitskonzepte implementieren. Dennoch ist sie ein wertvolles Beispiel dafür, dass auch vertrauenswürdige, verwaltete Cloud-Komponenten Schwachstellen aufweisen können.

„Wir setzen in unseren Software-Lösungen konsequent auf Zero-Trust und etablierte DevSecOps-Methoden – auch wenn dieses Finding bei unseren Kundenlösungen für keine kritische Sicherheitslücke gesorgt hat, zeigt es uns, dass trotz größter Sorgfalt immer wieder externe Faktoren Angriffsfläche bieten können und regelmäßige manuelle Penetration-Tests zur Vermeidung blinder Flecken wichtig sind.“
– Mario te Best, WareTec IT Solutions GmbH

Die wichtigsten Takeaways für uns als Entwicklerteam:

• ✅ Defense in Depth ist kein optionales Nice-to-have, sondern Pflicht
• ✅ CORS ist kein Ersatz für Authentication
• ✅ Managed Services sind nicht automatisch sicher – auch Azure-Services benötigen zusätzliche Härtung
• ✅ Regelmäßige Security-Audits (automatisiert + manuell) sind essenziell
• ✅ Security muss von Anfang an mitgedacht werden, nicht als nachträgliches Add-on

Timeline der Disclosure

• 02. Dezember 2025: Meldung an Microsoft Security Response Center (MSRC)
• 03. Dezember 2025: Vergabe der Case-Nummer VULN-167454, Status „Review/Repro“
• 21. Dezember 2025: Microsoft bestätigt Reproduktion, Techniker arbeiten an Analyse
• 02. Februar 2026: Weiterleitung der Informationen an zuständige Produktteams
• 09. März 2026: Öffentliche Bekanntgabe (heute)

Microsoft wurde ausreichend Zeit zur Analyse und Behebung eingeräumt. Die Veröffentlichung erfolgt nach vollständigem Ablauf der Responsible Disclosure Timeline.

Weiterführende Ressourcen

Für Entwickler, die tiefer in das Thema CORS-Sicherheit einsteigen möchten, empfehlen wir folgende Ressourcen:

• PortSwigger: Exploiting CORS Misconfigurations
• HackerOne Report #430249: CORS Vulnerability
• Identity-Aware Proxy Misconfiguration in Google Cloud
• EmojiDeploy: Azure Web Service RCE via CORS
• W3C CORS Specification

Fazit: Trust No Origin

Diese Schwachstelle ist ein Paradebeispiel dafür, wie scheinbar kleine Implementierungsdetails zu gravierenden Sicherheitsproblemen führen können. Für uns als Entwickler ist die wichtigste Lektion:

Vertraue niemals einem einzigen Sicherheitsmechanismus – schon gar nicht einem, der vom Client kontrolliert wird.

CORS ist ein wichtiges Browser-Feature, aber es ersetzt weder Authentication noch Authorization. In komplexen Cloud-Architekturen mit Microservices, API-Gateways und Multi-Tenant-Szenarien müssen wir als Entwickler auf robuste, mehrschichtige Sicherheitskonzepte setzen.

Mit dem absehbaren End-of-Life des Ingress-NGINX Controllers werden viele bestehende Deployments weiterhin in Betrieb bleiben – und damit potenzielle Schwachstellen in sich tragen. Genau deshalb sind regelmäßige Security-Audits, Penetrationstests und kontinuierliches Monitoring so wichtig.

Wenn Sie Unterstützung bei der Absicherung Ihrer Cloud-Infrastruktur oder bei der Migration zu sichereren Ingress-Lösungen benötigen, kontaktieren Sie uns gerne.