Coders Conquer Security OWASP Top 10 API-Serie – Deaktivierte Sicherheitsfunktionen/Aktivierte Debug-Modi/Unzureichende Berechtigungen

Während die meisten Schwachstellen auf dieser Liste spezifisch für APIs sind, kann das Problem deaktivierter Sicherheitsfunktionen, aktivierter Debug-Modi oder unzureichender Berechtigungen überall auftreten. Es ist bei APIs zwar etwas häufiger der Fall, doch Angreifer suchen überall im Netzwerk nach ungepatchten Schwachstellen sowie ungeschützten Dateien oder Verzeichnissen. Eine API mit aktiviertem Debugging oder deaktivierten Sicherheitsfunktionen macht ihre bösartige Arbeit nur noch einfacher. Schlimmer noch: Es gibt automatisierte Tools, um Sicherheitsfehlkonfigurationen zu erkennen und auszunutzen. Wenn diese in Ihrer Umgebung vorhanden sind, ist die Wahrscheinlichkeit hoch, dass sie ausgenutzt werden – genau deshalb hat es diese Schwachstelle auf die OWASP-Liste der gefährlichen API-Fehler geschafft.

Bevor wir zum spaßigen Teil kommen: Versuchen Sie, diese Debug-Herausforderung zu lösen:

Wie schleichen sich Fehler durch deaktivierte Sicherheitsfunktionen, aktivierte Debug-Modi oder unzureichende Berechtigungen in eine API ein?

Um zu verstehen, wie diese mehrdimensionale API-Schwachstelle in Netzwerke gelangt, müssen wir sie in ihre Bestandteile zerlegen. Beginnen wir mit dem Problem der aktivierten Debug-Funktionen. Debugging ist ein nützliches Werkzeug, das Entwicklern hilft, Fehler in Anwendungen zu finden. Bei aktiviertem Debugging erzeugen Fehler und Ausnahmen detaillierte Fehlerseiten, damit Entwickler sehen können, was schiefgelaufen ist. Während der Entwicklung einer Anwendung ist dies völlig in Ordnung.

Es gibt jedoch einen Grund, warum die meisten Frameworks Warnungen vor dem Debug-Modus in einer Produktionsumgebung enthalten – oft direkt im Code, wo das Debugging aktiviert wird. Zum Beispiel:

# SICHERHEITSWARNUNG: Nicht mit aktiviertem Debug-Modus in der Produktion ausführen!
DEBUG = True

In diesem Beispiel wurde das Debugging aktiviert. Die Django-Anwendung generiert detaillierte Fehlerseiten, wenn eine Ausnahme auftritt. Geschieht dies in einer Produktionsumgebung, hat ein Angreifer Zugriff auf diese Fehlerseiten, die Metadaten über die Umgebung enthalten. Obwohl die meisten Frameworks das Debugging standardmäßig deaktivieren, vergisst man leicht, es nach einem langen Entwicklungsprozess wieder auszuschalten. Wenn die Anwendung dann in die Produktion geht, liefert sie Angreifern wertvolle Informationen darüber, wie sie die Anwendung oder sogar das gesamte Netzwerk kompromittieren können.

Während die Aktivierung des Debug-Modus meist ein isoliertes Problem darstellt, treten unzureichende Berechtigungen und deaktivierte Sicherheitsfunktionen oft gemeinsam auf. In einem von OWASP beschriebenen Szenario nutzte ein Angreifer eine Suchmaschine, um eine Datenbank zu finden, die versehentlich mit dem Internet verbunden war. Da das Datenbanksystem die Standardkonfiguration verwendete, war die Authentifizierung deaktiviert. Durch die Kombination dieser Schwachstellen erhielt der Angreifer Zugriff auf Millionen von Datensätzen mit personenbezogenen Daten, persönlichen Präferenzen und Authentifizierungsdaten.

Beseitigung der Schwachstellen durch deaktivierte Sicherheitsfunktionen, aktivierte Debug-Modi und unzureichende Berechtigungen

Sie sollten einen zweigleisigen Ansatz verfolgen, um diese Schwachstelle zu beseitigen. Um das Problem mit dem aktivierten Debugging zu lösen, fügen Sie Ihrem Entwicklungsprozess eine Prüfung hinzu, die sicherstellt, dass das Debugging deaktiviert ist, bevor eine API oder Anwendung in die Produktionsumgebung überführt wird. Basierend auf unserem Beispiel lautet der korrekte Befehl dafür:

# SICHERHEITSWARNUNG: Nicht mit aktiviertem Debug-Modus in der Produktion ausführen!
DEBUG = False

Nun sind die Debug-Funktionen in der Django-Anwendung deaktiviert, da das DEBUG-Flag auf „False“ gesetzt ist. Bei Fehlern werden keine detaillierten Fehlerseiten mehr generiert. Sollte ein Angreifer dennoch Zugriff auf Fehlerseiten erhalten, enthalten diese keine nützlichen Metadaten und stellen kein Risiko für die Anwendung dar.

Die Beseitigung von deaktivierten Sicherheitsfunktionen und unzureichenden Berechtigungen ist etwas schwieriger, da sie eine Vielzahl spezifischer Schwachstellen umfassen können. Der beste Weg, sie zu stoppen, ist die Entwicklung eines standardisierten und wiederholbaren Prozesses, der eine schnelle und einfache Bereitstellung abgesicherter Assets in der Produktionsumgebung ermöglicht.

Darüber hinaus sollten Sie einen Prozess etablieren, bei dem Orchestrierungsdateien, API-Komponenten und Cloud-Dienste wie Amazon S3-Bucket-Berechtigungen kontinuierlich überprüft und aktualisiert werden. Diese Überprüfung sollte auch die Wirksamkeit der Sicherheitseinstellungen in der gesamten Umgebung bewerten, um sicherzustellen, dass die API-Sicherheit des Unternehmens stetig verbessert wird.

Besuchen Sie die Secure Code Warrior-Blogseiten für weitere Einblicke in diese Schwachstelle und erfahren Sie, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der Secure Code Warrior-Schulungsplattform ausprobieren, um Ihre Cybersicherheitskenntnisse stets auf dem neuesten Stand zu halten.