Coders Conquer Security OWASP Top 10 API Series - Deaktivierte Sicherheitsfunktionen/Debug-Funktionen aktiviert/unzulässige Berechtigungen

Während die meisten Schwachstellen in dieser Liste ziemlich spezifisch für APIs sind, ist das Problem der deaktivierten Sicherheitsfunktionen/aktivierten Debug-Funktionen/unzulässigen Berechtigungen eines, das überall auftreten kann. Es ist wahrscheinlich etwas häufiger in APIs anzutreffen, aber Angreifer werden oft versuchen, ungepatchte Schwachstellen und ungeschützte Dateien oder Verzeichnisse irgendwo in einem Netzwerk zu finden. Wenn sie auf eine API stoßen, bei der das Debugging aktiviert oder die Sicherheitsfunktionen deaktiviert sind, macht das ihre schändliche Arbeit nur ein wenig einfacher. Schlimmer noch, es gibt automatisierte Tools, um Sicherheitsfehlkonfigurationen zu erkennen und auszunutzen. Wenn Sie diese also in Ihrer Umgebung haben, besteht eine gute Chance, dass sie ausgenutzt werden, weshalb diese Schwachstelle es auf die OWASP-Liste der gefährlichen API-Schwachstellen geschafft hat.

Bevor wir mit dem Spaß beginnen, sehen Sie, ob Sie diese Debug-Herausforderung lösen können:

Wie schleicht sich der Fehler deaktivierte Sicherheitsfunktionen/aktivierte Debug-Funktionen/unzulässige Berechtigungen in eine API ein?

Um zu sehen, wie dieser mehrdimensionale API-Fehler in die Netzwerke gelangt, müssen wir ihn in seine Bestandteile zerlegen. Beginnen wir mit dem Problem der aktivierten Debugging-Funktionen. Debugging ist ein nützliches Werkzeug, das Entwicklern hilft, herauszufinden, warum Anwendungen nicht richtig funktionieren oder Fehler machen. Wenn Debugging aktiviert ist, werden bei Fehlern und Ausnahmen detaillierte Fehlerseiten generiert, so dass Entwickler sehen können, was schief gelaufen ist und Probleme beheben können. Es ist völlig in Ordnung, diese Funktion zu aktivieren, während sich eine Anwendung noch in der Entwicklung befindet.

Es gibt jedoch einen Grund, warum die meisten Frameworks mit Warnungen über die Ausführung des Debug-Modus in einer Produktionsumgebung kommen, wahrscheinlich direkt im Code, wo das Debugging aktiviert ist. Zum Beispiel:

# SICHERHEITSWARNUNG: nicht mit eingeschaltetem Debug in der Produktion ausführen!
DEBUG = True

In diesem Beispiel wurde das Debugging aktiviert. Die Django-Anwendung generiert detaillierte Fehlerseiten, wenn eine Ausnahme ausgelöst wird. Wenn dies in einer Produktionsumgebung geschieht, hätte ein Angreifer Zugriff auf diese Fehlerseiten, die Metadateninformationen über die Umgebung enthalten. Obwohl bei den meisten Frameworks das Debugging standardmäßig ausgeschaltet ist, vergisst man leicht, es wieder auszuschalten, wenn es während eines langen Entwicklungsprozesses aktiviert wurde. Wenn die Anwendung dann in eine Produktionsumgebung übergeht, bietet sie Angreifern viele Informationen darüber, wie sie eine Anwendung oder sogar einen ganzen Server oder ein Netzwerk kompromittieren können.

Während das Aktivieren des Debug-Modus meist ein eigenständiges Problem darstellt, wirken die Schwachstellen mit falschen Berechtigungen und deaktivierten Sicherheitsfunktionen oft zusammen. In einem realen Szenario, das von OWASP zur Verfügung gestellt wurde, verwendete ein Angreifer beispielsweise eine Suchmaschine, um eine Datenbank zu finden, die versehentlich mit dem Internet verbunden war. Da das beliebte Datenbankmanagementsystem seine Standardkonfiguration verwendete, war die Authentifizierung deaktiviert. Durch die Kombination der falschen Berechtigungen und der deaktivierten Sicherheitsfunktionen erlangte der Angreifer somit Zugriff auf Millionen von Datensätzen mit PII, persönlichen Einstellungen und Authentifizierungsdaten.

Beseitigung der deaktivierten Sicherheitsfunktionen/aktivierten Debug-Funktionen/unzulässigen Berechtigungsschwachstellen

Wahrscheinlich müssen Sie bei der Beseitigung dieser Schwachstelle einen zweigleisigen Ansatz wählen. Um den aktivierten Debug-Teil des Problems zu beseitigen, fügen Sie einfach eine Prüfung in den Entwicklungsprozess ein, um sicherzustellen, dass das Debugging deaktiviert wird, bevor eine API oder Anwendung in die Produktionsumgebung verschoben wird. In unserem Beispiel würde der richtige Befehl dazu folgendermaßen lauten:

# SICHERHEITSWARNUNG: nicht mit eingeschaltetem Debug in der Produktion ausführen!
DEBUG = False

Jetzt werden die Debug-Funktionen in der Django-Anwendung deaktiviert, indem das DEBUG-Flag auf False konfiguriert wird. Als Reaktion auf Fehler werden keine Fehlerseiten generiert. Wenn ein Angreifer dennoch Zugriff auf Fehlerseiten erhält, enthalten diese keine nützlichen Metadaten und stellen kein Risiko für die Anwendung dar.

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

Selbst dann sollten Sie einen Prozess erstellen, bei dem Orchestrierungsdateien, API-Komponenten und Cloud-Dienste wie Amazon S3-Bucket-Berechtigungen ständig überprüft und aktualisiert werden. Bei dieser Überprüfung sollte auch die Gesamtwirksamkeit der Sicherheitseinstellungen in der gesamten Umgebung im Laufe der Zeit bewertet werden, um sicherzustellen, dass das Unternehmen seine API-Sicherheit stets verbessert.

Schauen Sie sich die Secure Code Warrior Blog-Seiten, um mehr über diese Schwachstelle zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Kenntnisse zu schärfen und auf dem neuesten Stand zu halten.