Sicherheitsbedrohungen im Web: Die größten Risiken laut OWASP Top Ten 2021
Seite 2: #5: Security Misconfiguration
Ein verbreitetes Missverständnis lautet: Für die Konfiguration ist das Administrationsteam zuständig und die Programmierung hat damit nichts zu tun. Das mag in der Vergangenheit zeitweise gegolten haben, aber heutzutage sind viele Aspekte sicherer Einstellungen in den Händen derjenigen, die Code schreiben. Beispiele, die in diese Kategorie fallen, gibt es reichlich: fehlende Sicherheits-HTTP-Header oder Cookie-Flags, nicht abgeschaltete detaillierte Fehlerseiten mit komplettem Stacktrace – oder Speichern von Passwörtern in einer Konfigurationsdatei.
Etwas überraschend ist, dass XML External Entities (XXE) in der Liste von 2021 ein Zuhause unter der Oberkategorie der Fehlkonfigurationen gefunden haben. XXE waren ein Last-Minute-Neuzugang in der OWASP Top Ten 2017, der gleich auf Platz 4 eingestiegen ist. Begründet wurde das damit, dass XXE bei der Umfrage zu fehlenden Punkten äußerst häufig genannt wurden.
Nach Meinung des Autors ist die Gefahr von XXE allerdings stark abhängig von Stack und Technologie. Beispielsweise ist ASP.NET seit der 2014 veröffentlichten Version 4.5.2 standardmäßig vor dem Angriff abgesichert. In der Bibliothek libxml, die PHP nutzt, ist seit der 2012 erschienenen Version 2.9.0 standardmäßig das Feature deaktiviert, das den Angriff ermöglichte. Durch die Unterordnung von XXE in "Security Misconfiguration" hat OWASP einen der größten Kritikpunkte an der Vorgängerausgabe der Top Ten elegant umgangen.
#6: Vulnerable and Outdated Components
Punkt 6 auf der OWASP Top Ten besteht eigentlich nur aus einem CWE-Eintrag: "CWE-1104 Use of Unmaintained Third Party Components". Zwar sind noch zwei weitere CWEs aufgeführt, die sich aber auf die OWASP Top Tens von 2013 und 2017 beziehen und somit als selbsterfüllende Prophezeiung zu sehen sind. Zeitgemäße Webanwendungen haben häufig viele externe Abhängigkeiten – insbesondere einige SPA-Anwendungen. Das soll nicht abwertend klingen: Bei einem großen Funktionsumfang ist das Setzen auf bestehende Methoden in Open-Source-Bibliotheken ein gangbarer und ökonomischer Weg. Die Folge ist jedoch ein erhöhter Aufwand beim Nachverfolgen aller Dependencies.
Typisches (und wertfreies) Beispiel: Die Installation des Angular CLI richtet mehrere als deprecated (veraltet) markierte Bibliotheken ein (s. Abb. 3). Ein darauffolgender Aufruf von ng new erzeugt eine "leere" Angular-Anwendung. Das Zielverzeichnis ist anschließend über 300 MByte groß. Es aktuell zu halten ist trotz zur Verfügung stehender Unterstützungsmechanismen wie npm audit aufwändig. Daher ist der Aufstieg von Platz 9 auf der Vorgängerliste verständlich.
#7: Identification and Authentication Failures
In der OWASP Top Ten von 2017 war ein Punkt namens "Broken Authentication" noch an zweiter Stelle aufgeführt. Unter neuem Namen findet er sich 2021 fünf Plätze weiter unten wieder. Enthalten sind CWEs zu diversen Session-Angriffen wie Session-Fixation oder zu langen Session-Timeouts. Darüber hinaus sind weitere Probleme im Bereich Authentifizierung enthalten.
Dass dieses Risiko insgesamt zurückgegangen ist, mag darin begründet liegen, dass Frameworks beziehungsweise Systeme inzwischen Basisfunktionen rund um Authentifizierung in sicherheitstechnisch guter Qualität mitliefern. Vulgo: Es gibt bei einem Audit in dieser Hinsicht weniger zu finden als zu Zeiten, in denen ein größerer Anteil der Log-in-Masken selbstgestrickt waren. In dem Fall sorgt die Vereinheitlichung dafür, dass wichtige Security-Best-Practices auf Knopfdruck verfügbar sind.
#8: Software and Data Integrity Failures
Der Eintrag zum Thema Software- und Datenintegrität ist neu in der OWASP Top Ten 2021. Pate stand womöglich der Angriff auf SolarWinds, bei dem ein schadhaftes Update eingespielt worden ist. Ganz allgemein geht es bei diesem Listeneintrag um eine fehlende Integritätsprüfung. In der Liste von 2017 war bereits der Sonderfall unsichere Deserialisierung als eigenständiger Punkt aufgeführt. Beim Entgegennehmen von Daten in serialisierter Form wie im JSON- oder XML-Format ist es wichtig, auf dem erwarteten Datentyp zu bestehen, statt blind die Daten zu deserialisieren.
Beim Einsatz von Continuous Integration und Continuous Delivery (CI/CD) ist ebenfalls jeder Schritt des Prozesses vor fremdem Zugriff oder Manipulation abzusichern. Bei JavaScript-Code kann der Webbrowser helfen: Subresource Integrity gibt per Attribut des <script>-Tags einen Hash-Code vor, der zu der zu ladenden Skriptdatei passen muss. Das verhindert die Ausführung des schadhaften Codes etwa bei der Übernahme aus einem Content Delivery Network (CDN), weil der Inhalt nicht zum Prüfwert passt.
#9: Security Logging and Monitoring Failures
Loggen und Monitoring aus Sicherheitssicht ist seit 2017 Teil der OWASP Top Ten; im Jahr 2021 stieg das Risiko um einen Platz nach oben. Das konkrete Herausarbeiten von Handlungsanweisungen fällt etwas schwer: Teams müssen loggen und sowohl die Applikation als auch die Logs überprüfen. Dennoch ist das etwas schwammiger als beispielsweise die konkreten Maßnahmen, die vor spezifischen Angriffen warnen, wie bei SQL Injection.
Unter dem Oberpunkt versammeln sich dementsprechend nur vier CWEs, die sich alle auf Log-Dateien beziehen. Das Monitoring ist damit eine Art Bonusfunktion in Punkt 9 der OWASP Top Ten, aber nichtsdestotrotz eine wichtige ergänzende Maßnahme. Ein Log, das sich niemand anschaut, ist wie ein Backup, das nie für ein Restore dient.
#10: Server-Side Request Forgery
Am Ende der OWASP Top Ten 2021 findet sich noch ein Neuzugang, der in der Community-Umfrage Platz 1 belegt hat. Die Rede ist von Server-Side Request Forgery, kurz SSRF. Die Namensähnlichkeit zu CSRF ist durchaus beabsichtigt. Während es bei Cross-Site Request Forgery meist darum geht, dass der Clientbrowser eine ungewollte HTTP-Anfrage erzeugt, ist es bei SSRF der Server. Der Angriff bringt somit den Webserver dazu, einen HTTP-Request zu erzeugen, der an ein System gerichtet sein kann, das von außen nicht zugänglich wäre. Auf diese Weise lassen sich Firewalls und andere Schutzmaßnahmen umgehen.
Bei den bereits in Punkt 5 thematisierten XML External Entities (XXE) könnte ein erfolgreicher Angriff eine solche Anfrage auslösen. Das OWASP weist explizit darauf hin, dass die erhobenen Daten keinen Platz in der Liste rechtfertigen würden, aber die Community-Umfrage eine Meinungslage für die Aufnahme von SSRF gezeigt habe.
Die subjektive Meinung des Artikelautors ist, dass für einen erfolgreichen SSRF-Angriff die Sterne extrem günstig stehen müssen: Nicht nur bedarf es eines Angriffsvektors wie XXE, der in den meisten modernen Stacks stark erschwert ist, sondern darüber hinaus eines optimalerweise über HTTP GET zugänglichen Endpunktes, der zudem entweder wertvolle Informationen liefert oder eine gefährliche Aktion auslöst, was bei GET unwahrscheinlich ist. 2017 gab es bei der kurzfristigen Aufnahme von XXE ähnliche Diskussionen. Möglicherweise verschwindet der Punkt in der nächsten Liste, die turnusmäßig 2024 (oder wieder verzögert 2025) ansteht. Alternativ könnte er in einem anderen wie "Broken Access Control" aufgehen.
