Moderne Frontend, alte Backoffice: eine hybride Landschaft auditieren

TL;DR: Ein modernes Framework auf der Hauptdomain, ein uraltes Content-System auf einem nackten Origin dahinter. Ich habe beide Landschaften getrennt geprüft, und die Legacy-Seite definierte das Risiko. So sehen Sie Ihre eigene andere Generation.

Ausgangslage

Ich habe das Ziel als Black-Box geprüft: keine Zugangsdaten, nur die öffentlich sichtbare Fläche. Das ist, was ich sah, bevor ich etwas angefasst habe.

Eine gemeinnützige Beteiligungsplattform mit moderner vorgerenderter Anwendung auf der Hauptdomain und einem Legacy-Content-System auf einer Subdomain hinter einem ungeschützten Originserver sowie mehreren Drittanbieter-Diensten. Geprüft wurden beide Landschaften getrennt, E-Mail-Authentifizierung, Header-Policy und Drittanbieter-Skript-Inventar.

Ich habe alle identifizierenden Informationen entfernt. Das Ziel wird ausschließlich nach Branche und Technologieklasse beschrieben, damit das Muster übertragbar bleibt.

Das Muster

Das Muster, das ich erkannt habe — und das ich in ähnlichen Landschaften immer wieder finde:

Hybride Landschaften sind die Norm für alles, was eine Neugestaltung, ein Rebranding oder eine Fusion durchlaufen hat, und sie erzeugen einen bestimmten Governance-Fehler: die moderne Fläche hat einen Besitzer, die Legacy-Fläche hat einen Hostnamen, den niemand besitzt.

Der technische Kontrast verschärft das. Die moderne Seite steht hinter einem globalen CDN mit automatischer Zertifikatsverwaltung, und alle Sicherheits-Header der Landschaft werden dort gesetzt, weil dort die Konfiguration liegt. Die Legacy-Seite steht auf einem nackten Origin.

Die Lehre generalisiert über Content-Management-Systeme hinaus. Wenn eine Landschaft zwei Technologie-Generationen hat, lautet die Frage nicht, welche besser ist, sondern welche niemand ansieht.

Befunde

Der Angriffspfad

Reproduktion im Labor

Jeder Befehl unten zielt auf einen Lab-Container, den ich selbst kontrolliere. Nichts davon ist auf ein laufendes System gerichtet.

Die andere Generation in der eigenen Landschaft finden

# welche Technologie antwortet auf welchem Host
$ for h in example.org legacy.example.org archive.example.org cms.example.org; do
    printf '%-26s %s %s\n' "$h" \
      "$(curl -so /dev/null -w '%{http_code}' https://$h/)" \
      "$(curl -s https://$h/ | grep -oiE 'generator[^>]*content="[^"]+"' | head -1)"
done

# trägt der Legacy-Host irgendeinen Schutz
$ curl -sI https://legacy.example.org/ \
  | grep -icE 'strict-transport|content-security-policy|x-frame-options|x-content-type'

Erkennung in eigener Infrastruktur

Subdomains einer eigenen Domain enumerieren

$ for sub in www legacy archive cms old blog admin shop help intranet; do
    printf '%-12s %s\n' "$sub" "$(dig +short "$sub.example.org" | tr '\n' ' ')"
done

# dann in die Zertifikatstransparenz schauen, was existiert
$ dig +short TXT example.org | grep -i spf

Behebung

Dieselbe Perimeter vor jeden Host stellen, auch vor Legacy-Hosts

# die moderne CDN-Konfiguration ist nicht die Landschaftskonfiguration, solange nicht jeder Host dahinter liegt
# für einen Legacy-Host mindestens einen Origin-Schutz davorstellen
server {
    listen 443 ssl http2;
    server_name legacy.example.org;

    # dieselbe Basislinie wie die moderne Oberfläche
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    # und die Content-Management-Version nie exponieren
    server_tokens off;
    proxy_hide_header X-Powered-By;
}

Fazit — was ich daraus mitnehme

• Die Landschaft ist nur so geschützt wie ihr am wenigsten besessener Hostname.
• Ein CDN auf der Hauptdomain ist keine Perimeter für die Subdomain.
• Archive Systeme überleben, weil sie jemand noch nutzt; das ist eine Abschaltentscheidung.
• Subdomains zuerst enumerieren. Die andere Generation liegt immer auf einem vorhersagbaren Namen.