LONDON (IT BOLTWISE) – Neue Forschung beschreibt eine Cache-Key-Injection-Attacke, die Nginx-Zugriffskontrollen umgehen kann, indem sie kollidierende Cache-Schlüssel erzeugt. Kritisch ist dabei nicht der fehlende Schlüssel an sich, sondern die Art, wie Nginx Schlüssel aus variablen HTTP-Werten ohne saubere Trennzeichen zusammensetzt. In Proof-of-Concepts reichen kleine Varianten von Pfad- oder Header-Werten, um zuerst gespeicherte Antworten später für andere Requests auszuliefern. Zusätzlich werden Szenarien mit Cache-induziertem Denial of Service und sogar stored XSS bei anfälligen Setups diskutiert.
Unternehmen schützen Web-Endpoints typischerweise über Pfadregeln, Reverse-Proxy-Policies und Zugriffstests direkt vor der Anwendung. Genau diese Annahme gerät ins Wanken, wenn Zwischenspeicher (Caches) zwar “keyed” arbeiten, aber die Cache-Schlüssel nicht eindeutig genug bilden. In der von YesWeHack-Researcher Alex Brumen beschriebenen Technik “Cache Key Injection” liegt die Schwachstelle darin, dass Web Caches mehrere Request-Werte ohne klare Trennzeichen aneinanderhängen. Dadurch können zwei unterschiedliche Requests denselben finalen Cache-Key erzeugen – mit der Folge, dass eine Antwort für einen Request später für einen anderen ausgeliefert wird. Das ist weniger eine klassische Cache-Poisoning-Variante, bei der typischerweise ungesicherte Header oder Parameter “unkeyed” bleiben, sondern eine gezielte Manipulation der Werte, die bereits Teil des Cache-Schlüssels sind.
Technisch betrachtet nutzt das Angriffsmuster die Grenzenlosigkeit variabler Zeichenketten: Wenn ein Cache-Key aus Komponenten wie Scheme, Host, URI, Query-String, Cookies oder einem Header wie $http_accept besteht, aber zwischen den Bestandteilen kein Separator steckt, wird die resultierende Zeichenkette in der Praxis zu einem Mehrdeutigkeitsproblem. Ein Beispiel aus der Forschung: Eine Konfiguration, die sinngemäß proxy_cache_key "$scheme$host$request_uri$http_accept"; verwendet, wirkt zunächst korrekt, weil jede Komponente “mit in den Schlüssel” einfließt. Ohne Grenzen können jedoch zwei unterschiedliche Eingaben dieselbe finale Zeichenkette ergeben. Konkret kann eine legitime Anfrage für den Pfad /home mit einem Accept-Header Accept: */* denselben Cache-Key erzeugen wie eine attacker-gesteuerte Anfrage für /h mit Accept: ome*/*. Wenn die Angreifer-Antwort den Cache zuerst befüllt, bekommen spätere /home-Requests die manipulierte Response – auch wenn die Anwendung selbst den Pfad korrekt verarbeitet.
Besonders problematisch wird das Muster, sobald Zugriffsregeln und Cache-Auslieferung auseinanderlaufen. In einem Proof-of-Concept diente ein Nginx-Setup dazu, /admin nur für localhost verfügbar zu machen. Der Angriffsidee: Ein externer Akteur ruft nicht /admin direkt auf, sondern nutzt die Tatsache, dass der Cache-Eintrag durch einen kollidierenden Key erreichbar bleibt. Ein Request auf /ad kann dabei so konstruiert werden, dass der resultierende Cache-Key auf denjenigen von /admin kollidiert. Damit landet im Cache ein Objekt, das formal aus Sicht des Pfads auf den Angreifer-Request passt, aber praktisch in späteren “berechtigten” oder “eingeschränkten” Kontexten für den Zugriff auf sensible Inhalte genutzt wird, weil beide Requests im Cache auf denselben Schlüssel abgebildet werden. Für Security-Teams ist das ein klassischer Blind Spot: Tests, die nur den Anwendungscode oder die Request-Auswertung prüfen, erkennen den Cache-Kollisionseffekt häufig nicht.
Die Forschung zeigt außerdem, wie sich Cache Key Injection in Cache-poisoned Denial of Service (CPDoS) übersetzen kann. Dabei versucht ein Angreifer, einen Request auf eine nicht existierende URL abzusetzen, deren Cache-Key mit demjenigen einer existierenden Ressource kollidiert. Wenn das Origin-System für den nicht existierenden Endpoint einen zwischengespeicherten Fehler (etwa eine 404) erzeugt oder ausliefert, kann dieser Fehler später Nutzer treffen, die eigentlich auf die echte Seite zugreifen wollen. Das dauert an, bis der Cache-Eintrag abläuft oder explizit gelöscht wird. In der Praxis bedeutet das: Selbst korrekte Seiten können “flattern” zwischen gültiger und falscher Auslieferung, abhängig davon, wer zuerst einen passenden Cache-Key triggert und wie lange der Cache den Eintrag behält. Für Betriebs- und Incident-Response-Prozesse ist das tückisch, weil die Fehlerbilder wie klassische Verfügbarkeitsprobleme wirken können, obwohl die Ursache im Cache-Key-Design steckt.
Noch einen Schritt tiefer geht das Szenario mit HTTP Scheme Confusion. Wenn ein Cache-Key mit $scheme$host beginnt, und ein Server zugleich beliebige Host-Header akzeptiert sowie sowohl HTTP als auch HTTPS für dieselbe Anwendung bereitstellt, entsteht ein weiterer Kollisionsraum: Ein Angreifer kann einen HTTP-Request so gestalten, dass der Host-Wert mit einem String beginnt, der in Kombination mit $scheme die Zeichenkette so formt, dass sie mit einer legitimen HTTPS-Variante kollidiert. Besonders gefährlich wird das, wenn die Anwendung den Host-Wert in einen Script-Source-Context reflektiert. Dann kann eine vergiftete, gespeicherte gecachte Seite statt nur im falschen Pfad “falsch” ausfallen, sondern auf der Clientseite attacker-kontrolliertes JavaScript nachladen. Die Konsequenz ist stored XSS in Kombination mit Cache-Miss oder Cache-Kollision – ein Setup, das in Audits schnell unterschätzt wird, weil die XSS-Bedingungen in der Regel als reine Anwendungsschicht betrachtet werden, während hier die Cache-Schicht die Auslieferung der Poisoning-Payload ermöglicht.
Auch Edge-Caching ist nicht automatisch ein Schutzschild. Laut den beschriebenen Beobachtungen kann ein Dienst wie Cloudflare als Edge-Cache unter bestimmten Bedingungen umgangen werden: Requests mit einem Authorization-Header können am Edge nicht cachen, erreichen aber dennoch einen Nginx-Origin-Cache, der authentifizierte Inhalte eventuell weiterhin in einen gemeinsamen Cache einspeist. Das widerspricht der Annahme “Der Edge nimmt gefährliche Requests aus”: Wenn die Authentifizierung zwar am Edge zu einem anderen Cachingverhalten führt, aber der Origin weiterhin eine geteilte Cache-Logik hat, kann sich das Poisoning dennoch im Backend fortsetzen. Für Organisationen, die Mehrschicht-Caching betreiben, heißt das: Die Sicherheitslogik muss durchgehend verstanden und konsistent umgesetzt werden – nicht nur in der letzten Meile vom Browser bis zum Edge.
Als Gegenmaßnahmen empfiehlt die Forschung vor allem eindeutige Cache-Key-Formalisierung. Eine zentrale Regel lautet: Vermeiden sollten Administratoren das direkte Aneinanderreihen von Rohwerten, die in Länge und Zeichensatz variieren, ohne strukturelle Trennzeichen oder geordnete Serialisierung. Praktisch heißt das, Separatoren oder strukturierte Kodierung einzuführen, etwa über ein Format wie $scheme|$host|$request_uri|$http_accept. Zusätzlich rät die Arbeit zur Validierung von Host-Headern, zur sauberen Trennung von HTTP- und HTTPS-Verhalten sowie dazu, zu verhindern, dass authentifizierte Requests in shared Caches landen. Für Teams bedeutet das in der Umsetzung: Sie müssen ihre Nginx-proxy_cache_key-Definitionen systematisch gegen Kollisionsfälle testen, nicht nur gegen offensichtliche Falscheingaben. Wer Caches für Sicherheitskontexte nutzt, sollte den Cache-Key damit wie eine sicherheitsrelevante Schnittstelle behandeln – nicht als reine Performance-Variable.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- 【MEHR LEBEN FÜR DEINEN SCHREIBTISCH】 Lerne Eilik kennen – deinen kleinen Roboter-Freund mit Persönlichkeit. Mit liebevollen Animationen, ausdrucksstarken Reaktionen und spielerischen Interaktionen bringt Eilik mehr Freude in deinen Alltag. Ob auf dem Schreibtisch, im Büro oder am Nachttisch – Eilik wird schnell zu einem vertrauten Begleiter für besondere Momente.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "Nginx Cache Key Injection: Wenn Zugriffsregeln am Cache scheitern" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "Nginx Cache Key Injection: Wenn Zugriffsregeln am Cache scheitern" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »Nginx Cache Key Injection: Wenn Zugriffsregeln am Cache scheitern« bei Google Deutschland suchen, bei Bing oder Google News!