Das Open Web Application Security Project (OWASP) verfolgt die Mission, die Sicherheit (webbasierter) Software zu verbessern. Es richtet Treffen und Veranstaltungen aus, veröffentlicht zahlreiche Dokumentationen und Checklisten zu diversen Aspekten der Websicherheit, und hat auch Softwareprodukte unter seiner Ägide, unter anderem den bekannten Sicherheitsscanner OWASP Zed Attack Proxy (ZED).
Das bekannteste Teilprojekt des OWASP ist eine seit 2003 mehr oder weniger regelmäßig veröffentlichte Liste der größten Sicherheitsrisiken für Webanwendungen: die OWASP Top Ten, die erstmals 2003 und in zweiter Auflage 2004 erschien. Danach schaltete OWASP auf einen dreijährigen Rhythmus um: 2007, 2010 und 2013.
Dieser ließ sich aber nicht durchhalten: Die für 2016 angedachte Liste stand unter einem schlechten Stern, verspätete sich, hatte großen internen Diskussionsbedarf und kumulierte schließlich in einem halbgaren Release Candidate im Jahre 2017. Die finale Liste brachte im Vergleich dazu an einigen Stellen signifikante Änderungen und erschien einige Monate später noch im selben Jahr. heise Developer hat die Hintergründe seinerzeit ausführlicher zusammengefasst.
OWASP Top Ten 2021
2020 sollte alles anders werden, aber nicht nur die Pandemie machte einen Strich durch die Rechnung. Wer weiß, wie lange es bis zur finalen Liste gedauert hätte, wenn nicht der zwanzigste Jahrestag von OWASP am 9.9.2021 angestanden hätte. Das Jubiläum erzeugte offenbar genug Leidensdruck, um am 8.9.2021 eine Vorabversion der neuen Top Ten zu veröffentlichen. Trotz einiger Diskussionen, auch im offiziellen GitHub-Repository des Projekts, stellte Projektleiter Andrew van der Stock pünktlich in der Jubiläumskonferenz des OWASP am 24.9.2021 die neue Liste vor:
| Nr. | Listeneintrag |
| 1 | Broken Access Control |
| 2 | Cryptographic Failures |
| 3 | Injection |
| 4 | Insecure Design |
| 5 | Security Misconfiguration |
| 6 | Vulnerable and Outdated Components |
| 7 | Identification and Authentication Failures |
| 8 | Software and Data Integrity Failures |
| 9 | Security Logging and Monitoring Failures |
| 10 | Server-Side Request Forgery |
Im Vergleich zu früheren Ausgaben der Top-Ten-Liste hat das Team – begleitet durch eine nur unauffällig auf der OWASP-Site verlinkte, projektspezifische Homepage – etwas mehr Einblicke in das Erstellen der Listenelemente und ihrer Reihenfolge gegeben, wenngleich die prinzipielle Herangehensweise ähnlich war wie bei den vorherigen Ausgaben. Zunächst hat die Organisation anonymisierte Daten aus Sicherheitsaudits von Webapplikationen eingesammelt. Basis war das CWE-Projekt (Common Weakness Enumeration), das Kategorien für Sicherheitslücken in Applikationen aufzählt (enumeriert). Die freiwilligen Datenspenden für die OWASP Top Ten bestanden im Wesentlichen aus CWEs und der Information darüber, wie häufig sie gefunden wurden. Abbildung 1 zeigt einen Ausschnitt aus den zusammengeführten Daten der Liste von 2017.
Im nächsten Schritt galt es, CWEs sinnvoll in Kategorien zu gruppieren und anschließend in eine Reihenfolge zu bringen. Damit ist die Top Ten zu 80 Prozent fertiggestellt, mit acht der zehn verfügbaren Positionen. Um frühzeitig Trends und Beobachtungen aus der Praxis aufgreifen zu können, die sich eventuell (noch) nicht in den nackten Zahlen widerspiegeln, fand gleichzeitig eine Community-Umfrage statt, welche CWEs zusätzlich einen Platz verdient hätten. Daraus ergeben sich die zwei fehlenden Listenelemente.
Obwohl dieser Ansatz gut dokumentiert ist, bietet er aufgrund der potenziell willkürlichen Gruppierung von CWEs sowie der Integration der Umfrageergebnisse Diskussionsbedarf. Allen voran: Gibt es Punkte, die auf der Liste eine völlig falsche Position haben oder gar komplett fehlen? In den folgenden Ausführungen zu den zehn Punkten der aktuellen Liste wagt der Autor dieses Artikels an der einen oder anderen Stelle ein subjektives Urteil.
#1: Broken Access Control
Das größte Risiko ist laut der OWASP Top Ten 2021 eine defekte Zugriffskontrolle. Der Oberpunkt war in der Vorgängerliste auf Platz 5 vertreten und hat diesmal den Sprung nach oben geschafft. Beigetragen haben insgesamt 34 zu dem Listeneintrag passende CWEs.
Grundsätzlich geht es bei dem Punkt um fehlenden Zugriffsschutz, der aber in unterschiedlichen Ausprägungen vorkommen kann: Umgehen eines bestehenden Zugriffsschutzes durch Veränderung von URL-Parametern, fehlende Autorisierung bei anderen HTTP-Verben als den vorgesehenen, ungesicherte Endpunkte oder Dateien sowie Replay-Angriffe mit JSON Web Tokens (JWT) – die Liste ist lang. Wie immer gilt es, Eingaben immer zu prüfen, und zu jedem Zeitpunkt die entsprechende Autorisierung des Clients sicherzustellen.
Etwas überraschen mag, dass neuerdings Cross-Site Request Forgery (CSRF) unter diesem Dach ein neues Zuhause gefunden hat. Vor 2017 hatte der Angriff einen eigenen Platz in der Top 10, und die 2017er-Ausgabe hat er knapp verpasst. Damals war der Autor auf der Basis seiner eigenen Funde im Rahmen von Audits und Codeanalysen der Meinung, er hätte in die Top Ten gehört. Inzwischen ist der Angriff voraussichtlich keine eigene Betrachtung mehr wert. Neben gut funktionierenden, teilweise auch standardmäßig aktiven Anti-CSRF-Maßnahmen in diversen Webframeworks schränken SameSite-Cookies die Angriffsoberfläche deutlich ein. Von einer großen Renaissance des Angriffs ist aktuell nicht auszugehen.
#2: Cryptographic Failures
Der etwas furchterregende Begriff des kryptographischen Versagens sammelt respektable 29 CWEs unter seiner Regie. Viele der aufgeführten Punkte wie das Verwenden unsicherer Algorithmen sind beim Einsatz eines halbwegs modernen Stacks kaum relevant. Kein zeitgemäßes Framework verwendet noch MD5 oder SHA1 zum Hashen eines Passworts – hoffentlich zumindest. Gerade das Passwort-Hashing können Entwicklerinnen und Entwickler frameworkseitig entweder automatisch nach Best Practices erledigen lassen (beispielsweise bei ASP.NET Core) oder auf eine einfach zu benutzende, aber sichere API zurückgreifen (z. B. bei PHP).
In der OWASP Top Ten von 2017 hieß der Punkt "Sensitive Data Exposure". Damals war vermutlich das Hauptproblem der Verzicht auf Verschlüsselung, insbesondere auf dem Transportweg. Da die meisten Webbrowser inzwischen Sites ohne HTTPS geradezu drangsalieren (s. Abb. 2), ist von einem weiteren Rückgang auszugehen. Der Einsatz von HTTPS schließt zudem einige, wenn auch nicht alle Flanken von Session Hijacking. Das Erzwingen von HTTPS lässt sich durch HTTP Strict Transport Security (HSTS) zusätzlich verschärfen; das ´secure´-Flag für Cookies verhindert, dass sie über ungesicherte Kommunikationskanäle transportiert werden.
#3: Injection
Ein häufig vorgebrachter Kritikpunkt an der 2017er-Ausgabe der OWASP Top Ten – auch durch den Autor dieses Artikels – ist der Spitzenplatz von Injection. Gemeint ist damit primär SQL Injection, ein Angriff, gegen den die Verteidigung einfach ist: Parametrisierte Abfragen beziehungsweise Prepared Statements arbeiten mit Platzhaltern in SQL-Queries, die deutlich festlegen, was ein Datum ist und was ein Befehl. Es gibt keinen Grund (und keine Ausrede) für das lockere Verketten von Strings. Beim Einsatz eines objektrelationalen Mappers wie Hibernate, Entity Framework oder Doctrine ist der Code noch einen Schritt weiter von potenziell anfälligem SQL entfernt, da die Arbeit fast ausschließlich über eine API erfolgt, die SQL Injection nahezu unmöglich macht.
Die OWASP hat die Spitzenplatzierung von (SQL) Injection immer verteidigt, gerade im Vergleich mit Cross-Site Scripting (XSS). Dieser Angriff, bei dem es um das Einschleusen von schadhaftem JavaScript-Code oder HTML-Markup geht, hat von den absoluten Zahlen her deutlich höhere Werte als der Datenbankangriff, befand sich aber in der OWASP Top Ten 2017 nur auf Platz 7. Begründung: Der Auftritt eines XSS führt in Folge zu zig weiteren XSS-Funden und verfälscht dadurch die Statistik.
Dieser Artikel stammt aus dem neuen iX-Developer-Sonderheft "Sichere Software entwickeln". Es behandelt auf 156 Seiten unter anderem die Themen Web-Application-Security, Codeanalyseverfahren und Cloud-Security. Der Schwerpunkt zu DevSecOps zeigt Methoden, Werkzeuge und Reifegradmodelle auf.
Für spezifische Programmiersprachen soll ein Artikel helfen, Speicherfehler in C++ aufzuspüren und zu vermeiden, und ein weiterer zeigt die Sicherheitskonzepte von Rust auf. Wer mit Java entwickelt, findet eine Übersicht der Änderungen an der Security von Java 11 bis Java 17.
Der Themenbereich Kryptografie geht von den Grundlagen über die Fallstricke beim Einbinden kryptografischer Verfahren in eigene Anwendungen bis zum Ausblick auf die Post-Quanten-Kryptografie.
Das Heft ist ab sofort im heise Shop als PDF für 12,99 Euro verfügbar. Die gedruckte Ausgabe lässt sich für 14,90 Euro vorbestellen. Ein Bundle aus gedruckter Ausgabe plus PDF ist ebenfalls verfügbar.
Vier Jahre später sieht es etwas anders aus. Injection ist auf Platz 3 abgefallen. Das offenbar weniger relevante XSS ist inzwischen allerdings Teil der Kategorie – das Einschleusen von JavaScript ist technisch ebenfalls eine Injektion. Das klingt subjektiv nach einem guten Kompromiss. OWASP wahrt das Gesicht (Injection immer noch in den Top 3), aber der Einfluss von XSS wird deutlich. Ohne die Hinzunahme von XSS wäre Injection laut der Live-Präsentation der 2021er-Liste an das Ende der Top 10 abgerutscht.
Dennoch ist dieser Zusammenschluss nicht ohne Kritik. Die Verteidigung gegen XSS hat deutlich mehr Facetten als der Schutz gegen SQL Injection. Neben einem ordentlichen Output-Escaping – und zwar kontextabhängig, da Sonderzeichenentwertung innerhalb von HTML anders funktioniert als innerhalb von JavaScript – helfen Defense-in-Depth-Mechanismen wie Content Security Policy (CSP), um bösartigem JavaScript und HTML-Markup den Garaus zu machen. Es bleibt zu hoffen, dass das Risiko "Injection" künftig noch weiter an Boden verliert.
#4: Insecure Design
Die Kategorie "unsicheres Design" ist ein Neuzugang. Die Intention ist klar: Wichtige Sicherheitskonzepte wie Threat Modeling und der Einsatz von Referenzarchitekturen sind in vielen Webapplikationen unterrepräsentiert. Sicherheit fängt nicht erst beim Schreiben von Code an. Die Entscheidung sorgt für Diskussionen – so wie viele Allgemeinplätze in der OWASP Top Ten, gerade wenn sie neu sind.
Im Vergleich zu anderen Punkten auf der Liste lassen sich nur beschränkt nachvollziehbare Aktionen ableiten. Die OWASP Top Ten ist eine Liste von Risiken, nicht von Angriffen, aber den meisten anderen Punkten lassen sich Angriffe besser zuordnen. Da ein sicheres Design wichtig ist, ist die Platzierung in der Liste durchaus berechtigt.
