Sicherheit, die davon ausgeht, dass der Angreifer die Vordertür nimmt

TL;DR: Drei Kontrollen, eine gemeinsame Annahme. Das CDN und die WAF funktionieren nur, wenn der Angreifer an der Vordertür klopft — der Origin-Server war direkt erreichbar, also waren beide optional. Consent wurde nicht umgangen, sondern war schlicht nie eingebaut — Analytics und Video-Embeds liefen vor jedem Banner. Mail-Vertrauen beruhte auf p=none und einem Softfail, also wurde eine gefälschte Nachricht zugestellt. Nichts davon ist eine CVE. Die Gefährdung ist architektonisch.

Die Ausgangslage

Ein mittelgroßer WordPress-Verleger beauftragte eine externe Prüfung seiner öffentlichen Web-Präsenz. Auf dem Papier wirkte alles gesund: der Core war aktuell, die Fokus-Plugins trugen keine offenen Advisories, und die Seite lief hinter einem CDN und der verwalteten Web-Application-Firewall des Hosters. Es gab kein „Box geknackt"-Befund-Erlebnis — und genau das wurde zum Kern der Geschichte.

Ich begann an der Edge, weil das ist, was der Betreiber sieht, wenn er sein Setup prüft. Die Antwort-Header waren aufgeräumt: HTTPS erzwungen, HTTP/2 und HTTP/3 verhandelt, das CDN antwortet, die WAF ist da. Jedes grüne Licht, das ein Admin prüft, war grün. Dann hörte ich auf, an der Vordertür zu prüfen, und suchte den Weg daran vorbei.

Ich habe alle identifizierenden Informationen entfernt. Das Ziel wird nur nach Branche und Technologieklasse beschrieben, damit das Muster wiederverwendbar bleibt.

Innerhalb weniger Minuten antwortete der Origin-Server direkt, auf seiner eigenen Adresse, ohne CDN und WAF im Pfad. Derselbe Review brachte zwei weitere Lücken mit derselben Form ans Licht: Tracking, das ohne jedes Consent-Gate feuerte, und Mail im Namen der Marke, die jeder Empfänger bereitwillig annähme. Drei Befunde, drei Kontrollen — und jede setzte voraus, dass sich der Angreifer benimmt.

Das Muster

Eine Kontrolle, die neben dem einzigen Pfad liegt, ist keine

Das CDN und die WAF waren echt und korrekt konfiguriert. Sie waren trotzdem optional, weil sie nicht auf dem einzigen Pfad zur Anwendung lagen. Wer die Origin-Adresse auflöste — ein Certificate-Transparency-Log, ein alter DNS-Eintrag, eine Subdomain, die nie hinter den Proxy wanderte — konnte direkt mit dem Server sprechen. Die Edge wird dann keine Sicherheitskontrolle mehr, sondern ein Performance-Feature: Sie schützt genau die Requests, die ohnehin höflich gewesen wären.

Die Lehre ist nicht „die WAF war schwach". Es ist: Eine Kontrolle ist nur so stark wie die Zahl der Pfade zu dem, was sie schützt. Erst die Pfade aufzählen, dann die Kontrolle auf allen platzieren.

„Kein Consent" ist kein Bypass — es ist ein fehlendes Gate

Es ist verlockend, „Analytics lädt vor Einwilligung" als Bypass abzulegen. Das war keiner. Es gab überhaupt keinen Consent-Manager auf der Seite. Das Analytics-Tag und die Video-Embeds liefen beim ersten Paint, schrieben Endgeräte-Speicher und pingten Third-Party-Werbe-Endpunkte — ohne Banner, ohne Opt-in, ohne jede Konfiguration, die sie je hätte gaten können. Man kann kein Gate umgehen, das nie gebaut wurde.

Diese Unterscheidung zählt beim Review: Ein „Bypass" impliziert eine funktionierende Kontrolle mit einem Loch. Ein fehlendes Gate bedeutet, dass das Risiko nie modelliert wurde. Am schmerzhaftesten war es auf den Seiten, die ein datenschutzbewusster Besucher genau deshalb öffnet, um zu verstehen, was mit seinen Daten passiert.

Mail-Vertrauen ist nur so stark wie das schwächste von drei Records

Die Domain veröffentlichte einen SPF-Record — mit Softfail. Sie veröffentlichte einen DMARC-Record — mit p=none. Einen DKIM-Selector veröffentlichte sie nicht. Für sich allein sieht jeder wie „etwas ist konfiguriert" aus. Zusammen bedeuten sie: Die Empfängerwelt hat keine Anweisung, eine Nachricht zurückzuweisen, die vorgibt, von der Marke zu kommen. SPF-Softfail sagt „das war ich nicht, aber macht, was ihr wollt"; p=none sagt „keine Maßnahme"; keine Signatur heißt, es gibt nichts, wogegen zu prüfen wäre. Eine gefälschte Rechnung oder Support-Mail landet im Posteingang.

Befunde

Der Angriffspfad

Der bequeme Pfad ist der, den der Betreiber verkabelt hat. Der echte Pfad ist der, der ihn überspringt.

Reproduktion im Labor

Jeder Probe unten adressiert eine Labor-Instanz, die ich kontrolliere. Nichts davon richtet sich gegen ein Live-System, und nichts davon ist ein Payload — der Punkt ist, dass kein Payload nötig ist.

# 1. die Vordertür sieht korrekt aus
curl -sSI https://lab.beispiel-verlag.test/ | grep -iE 'server|cf-|x-ws-|strict-transport'
# <- CDN antwortet, WAF vorhanden, HTTPS erzwungen

# 2. antwortet der Origin ohne die Edge?
dig +short origin.lab.beispiel-verlag.test
curl -sSI --resolve 'lab.beispiel-verlag.test:443:<origin-ip>' \
     https://lab.beispiel-verlag.test/ | grep -iE 'server|x-ws-|cf-'
# <- die Anwendung antwortet; keine Edge-Header; WAF nicht im Pfad

# 3. Consent: frisches Profil, keine Interaktion, pro Routenklasse
TARGET=https://lab.beispiel-verlag.test node consent-audit.js
# <- Third-Party-Requests vor Consent, Cookies geschrieben, Banner: keins

# 4. Mail: drei Records, zusammen gelesen
dig +short TXT lab.beispiel-verlag.test | grep -i spf      # <- ~all (Softfail)
dig +short TXT _dmarc.lab.beispiel-verlag.test             # <- p=none
# kein DKIM-Selector veröffentlicht

# consent-audit.js prüft, vor jeder Interaktion:
#   Third-Party-Requests == 0
#   geschriebene Cookies == 0
# Verletzt eine Route eine der Bedingungen, ist das ein Befund — Banner hin oder her.

Erkennung im eigenen Bestand

• Zählt die Pfade zu eurem Origin, nicht die Kontrollen, die ihr gekauft habt. Fragt: Wie viele Adressen antworten vom öffentlichen Internet für diese Anwendung? Wenn irgendeine ohne Edge davor antwortet, ist die Edge Deko.
• Beweist Consent am Ergebnis, nicht an der Existenz eines Banners. Ein frisches Profil mit null Third-Party-Requests und null Cookies vor Interaktion ist der einzige ehrliche Test — und er muss auf jeder Routenklasse bestehen, auch auf den Rechtsseiten.
• Lest SPF-, DMARC- und DKIM-Records nie isoliert. Softfail plus p=none plus keine Signatur ist eine Sende-doch-einfach-Konfiguration im Kostüm dreier Checklisten-Häkchen.
• Sucht das Muster statt des Einzelbefunds: eine Kontrolle, die auf dem Happy Path vorhanden ist und auf einem parallelen fehlt. Der Origin ist der offensichtliche Fall; eine unproxte Subdomain, ein Staging-Host oder ein Direct-IP-Endpunkt sind derselbe Bug in anderer Kleidung.

Was die Lücke wert ist

Nichts davon braucht eine Schwachstelle. Es braucht Geduld und ein stilles Fenster.

T+0m    Origin-Adresse aufgelöst und Antwort bestätigt
T+2m    WAF, Rate-Limits und Bot-Defense aus der Gleichung entfernt
        (sie haben nur den höflichen Traffic je gesehen)
T+30m   die Seite wird frei gelesen: Autoren, Medien, Kommentare, der interne
        Knowledge-Graph, die KI-/Automatisierungs-Endpunkte
T+1d    Mail im Namen der Marke wird entworfen und zugestellt — keine Signatur
        zum Scheitern, keine Policy, die sie ablehnt
T+n     jede spätere Lücke wird am rohen Origin ausgenutzt: ungeloggt,
        ungefiltert, in jedem Tempo, das dem Angreifer gefällt

Der Schaden ist keine verunstaltete Startseite. Es ist eine Marke, die man imitieren kann, Leser, die man phishen kann, eine interne Struktur, die bereits kartiert ist, und eine Monitoring-Geschichte, die genau deshalb blind ist, weil der Traffic nie die Edge berührte.

Die konkrete Behebung und Härtung ist eine eigene, beauftragte Leistung — dieser Beitrag zeigt bewusst nur die Gefährdung und was sie einem Angreifer wert ist.

Fazit

• Führt den Review aus der Position des Angreifers, nicht des Admins. Das Dashboard zeigt nur die Vordertür; der Befund lag auf der Adresse daneben.
• Trennt „umgangen" von „nie eingebaut". Ein fehlendes Consent-Gate ist ein Modellierungsfehler und taucht in einem Banner-Audit nicht auf.
• Drei Mail-Records sind ein System. Softfail, p=none und kein DKIM sind kein Teilkredit — zusammen sind sie eine offene Tür für Impersonation.
• Die vereinheitlichende Frage ist billig und mächtig: Für jede Kontrolle — wie viele Pfade führen daran vorbei? Ist die Antwort größer als null, ist die Kontrolle ein Vorschlag.
• Eine gepatchte Seite ist keine verteidigte Seite. Aktualität schließt CVEs; Architektur entscheidet, ob jemals eine nötig war.