Sicherheits-Fehlkonfiguration

Was ist Sicherheits-Fehlkonfiguration?

Der Anwendungscode ist korrekt, trotzdem ist die API unsicher, weil eine sicherheitsrelevante Einstellung gefährlich konfiguriert wurde. Hier geht es um CORS: Die API übernimmt jeden Origin aus einer Anfrage als Access-Control-Allow-Origin und setzt Access-Control-Allow-Credentials auf true. Dadurch darf ein Browser jeder Website eine Antwort mit dem Sitzungs-Cookie des Besuchers zugänglich machen. Sie nutzen eine Prämienseite, um die Antwort der Konto-API an Ihren Server zu senden, und begrenzen danach die erlaubten Origins auf eine explizite serverseitige Allowlist. Bei der Wiederholung des Angriffs zeigt sich, dass der Browser CORS durchsetzt, nicht der Server.

Was Sie lernen in Sicherheits-Fehlkonfiguration

• Eine Sicherheits-Fehlkonfiguration in einer API erkennen: eine sicherheitsrelevante Einstellung, die unsicher bleibt — etwa eine zu großzügige CORS-Richtlinie, ausführliche Fehlermeldungen, Debug-Flags oder eine Standardkonfiguration
• Verstehen, warum ein beliebiger Origin in Access-Control-Allow-Origin zusammen mit aktiviertem Access-Control-Allow-Credentials jeder Website, die ein angemeldeter Nutzer besucht, das Lesen seiner Kontodaten mit dessen Sitzungs-Cookie ermöglicht
• Nachvollziehen, wie ein Angreifer die Fehlkonfiguration mit einer einzigen Anfrage nachweist und dann eine unauffällige Seite für den Angriff vorbereitet. Ein Opfer muss nur den Link öffnen, damit seine Kontodaten über eine Origin-Grenze hinweg abfließen
• Sie von der fehlerhaften Autorisierung auf Objektebene (fehlende Eigentümerprüfung pro Datensatz) und der übermäßigen Datenoffenlegung (zu viele zurückgegebene Felder) unterscheiden; hier ist der Handler in Ordnung, der Fehler steckt in der Konfiguration
• Den Fix anwenden: die erlaubten Origins auf eine explizite Allowlist auf dem Server begrenzen, einen zurückgespiegelten oder Wildcard-Origin nie mit Access-Control-Allow-Credentials: true kombinieren und verstehen, dass CORS vom Browser durchgesetzt wird und nicht vom Server

Sicherheits-Fehlkonfiguration — Trainingsschritte

1. Eine browserfreundliche API

   Corvexa ist eine App für die persönliche Finanzverwaltung: Kunden verknüpfen ihr Bankkonto und verfolgen ihre Ausgaben. Die Corvexa-Web-App liest ihre Kontodaten direkt im Browser aus der Corvexa-API. Bob hat es auf Corvexa abgesehen. Er will per Phishing Kontodaten von Kunden abgreifen und weiterverkaufen. Er hat selbst ein nur dafür angelegtes Corvexa-Konto und sieht sich zunächst die öffentliche Entwicklerdokumentation an, um herauszufinden, wie die API im Browser verwendet wird.

2. Jede Website ist erlaubt

   Eine Karte in der Dokumentation beschreibt, wie die API mit Anfragen von anderen Websites umgeht. Bob liest sie genau.

3. Als Angreifer-Website anfragen

   Bob stellt die Anfrage nach, die seine schädliche Seite später senden wird. Er ruft den Konto-Endpunkt mit einem API-Client auf und setzt den Header Origin wie ein Browser auf seine eigene Website. Er ist bei seinem nur dafür angelegten Corvexa-Konto angemeldet, daher trägt die Anfrage ein gültiges Sitzungs-Cookie. Ihn interessiert nicht der Inhalt der Antwort, sondern welche Zugriffsrechte die API dem Browser für diese Antwort einräumt.

4. Die API sagt Ja

   Sehen Sie sich die Antwort-Header an, die die API zusammen mit dem Konto zurückgeschickt hat.

5. Die Köderseite

   Bob erstellt für seine Website eine harmlos wirkende Seite mit einem Corvexa-Prämienbanner. Links sehen Sie die Darstellung im Browser, rechts den Quelltext im Editor. Bislang zeigt die Seite lediglich ein Angebot über 50 $.

6. Die Seite für den Angriff vorbereiten

   Jetzt fügt Bob die Payload hinzu. Für Besucher sieht das Banner unverändert aus. Im Hintergrund ruft die Seite jedoch aus deren Browser die Corvexa-Konto-API auf und sendet die Antwort an Bobs Server. Weil die API Bobs Origin auch für Antworten auf Anfragen mit Sitzungs-Cookies freigibt, liefert das Cookie des Besuchers den Zugang zum Konto.

7. Wie der Diebstahl abläuft

   Für Besucher zeigt die Seite nach wie vor nur die Prämie. Gehen Sie durch, was das eingefügte Skript tut, sobald ein angemeldeter Corvexa-Kunde sie öffnet.

8. Den Köder verschicken

   Die Falle ist vorbereitet. Bob braucht nur noch einen angemeldeten Corvexa-Kunden, der die Seite öffnet. Deshalb sendet er einen Prämienlink per E-Mail, gestaltet als echte Corvexa-Aktion und verschickt von seiner täuschend ähnlichen Domain.

9. Eine Prämie im Posteingang

   Sie nutzen Corvexa selbst und sind im Browser gerade bei Ihrem Konto angemeldet. Nun erhalten Sie eine E-Mail mit dem Angebot einer Corvexa-Prämie über 50 $. Das Angebot klingt plausibel und die Gestaltung wirkt stimmig.

10. Den Link öffnen

    Sie klicken auf den Link, um die Prämie einzulösen, wie es viele tun würden. Die Seite öffnet sich im Browser, in dem Ihre Corvexa-Sitzung weiterhin aktiv ist.