Die 10 größten Risiken für Webanwendungen des Open Web Application Security Project

Mit den "OWASP Top 10 2010" hatte das Open Web Application Security Project im April 2010 die derzeit zehn größten Risiken für Webanwendungen vorgestellt. Dave Wichers, einer der beiden Hauptautoren, berichtete auf der in Stockholm tagenden OWASP AppSec Research über Motivation der Top 10 und technische Hintergründe.

Ohne Software, die aus Browsersicht hinter dem Webserver werkelt, geht im Internet nichts mehr. Für viele nicht bewusst hat sie das Bild vom weltweiten Netz für Benutzer und für Betreiber geprägt. Leider kommt der Sicherheit der meistens ungeschützt im Netz stehenden Software nicht immer der Wert zu, wie es dem Datenrisiko oder dem sich ergebenden geschäftlichen Risiko für den Betreiber angemessen wäre.

Dem will die Top 10 des OWASP abhelfen. Das Ziel ist zu sensibilisieren, aufzuklären und die Webapplikationssicherheit durch Erklärung der zehn wichtigsten Stolperfallen der Zielgruppe Programmierer, Softwarearchitekten und Organisationen ins Bewusstsein zu rufen. Denn größtenteils – so das Vorwort – seien die Top 10 relativ simple Sicherheitsfehler.

Der vierte in Folge

Softwaresicherheit, besonders im Webumfeld, ist einem steten Wandel unterworfen: neue Bedrohungen für Webanwendungen ergeben sich oder Risiken müssen anders eingeschätzt werden. Daher sollte es nicht verwundern, dass die Top 10 aus dem April mittlerweile die vierte Version des OWASP darstellen. Frühere Auflagen gab es 2003, 2004 und 2007.

Zwischen den Top 10 aus dem Jahr 2007 und den von 2010 gibt es zwei große Unterschiede: Die erstgenannten bezogen sich auf potenzielle Schwachstellen. Dieses Jahr sind in den Top 10 stattdessen Risiken gelistet. Das ist insofern ein wichtiger Unterschied, als das eine große Schwachstelle nicht zwangläufig ein erhebliches technisches Risiko darstellt. Ein solches entsteht erst durch eine Kette von Auswirkungen:

• Wie wahrscheinlich ist die Entdeckung der Schwachstelle?
• Wie einfach ist es, sie auszunutzen?
• Wie weit verbreitet ist das Wissen zur Ausnutzung?
• Wie einfach lässt sich die Schwachstelle vom Betreiber entdecken?
• Was sind die technischen Auswirkungen (Verlust von Vertraulichkeit, Integrität, Verfügbarkeit)?
• Inwieweit ist das Ausnutzen der Schwachstelle selbst nach Entdeckung rückverfolgbar?

Und letztlich: Welches betriebswirtschaftliche Risiko ergibt sich aus dem potenziellen technischen Risiko? Ist die Bedrohung so groß, dass der Betreiber befürchten muss, dadurch seine wirtschaftliche Basis zu verlieren? Die Risikotaxonomie entstammt dem 2008 erschienenen OWASP Testing Guide, ist also neueren Datums als die Top 10 von 2007. Berücksichtigt man, dass die 2004er-Ausgabe noch eine Mischung von Angriffen, Schwachstellen und Gegenmaßnahmen war, stellt nach der Konzentration auf Schwachstellen 2007 nun der Schritt hin zu Risiken eine weitere zielorientierte und strukturell wichtige Änderung dar.

Der zweite wichtige Unterschied besteht darin, dass sich 2007 die Top 10 fast ausschließlich auf Softwareprobleme bezogen. Die Metriken dazu kamen aus den auf Webapplikationen gefilterten MITRE-Statistiken des Vorjahres. 2010 ist mit "Security Misconfiguration" ein Punkt aufgetaucht, der eher was mit der falschen Konfiguration der darunterliegenden Server zu tun hat. In ähnlicher Form ("Insecure Configuration Management") ist er bereits in der 2004er-Liste erschienen. Die Autoren der Top 10 haben sich dazu entschlossen, den Punkt wieder aufzunehmen, da er ein echtes Risiko für die Websicherheit darstellt und der Fehler eine hohe Verbreitung hat.

Hitparade der Sünden

2010 ist die Liste kompakter geworden, ohne dass der Inhalt wesentlich darunter leidet. Der Aufbau hat sich dadurch verbessert, dass alle zehn Punkte identisch strukturiert sind: jedem ist eine DIN-A4-Seite gewidmet, die zuerst Teilrisiken wie Leichtigkeit der Ausnutzung, Verbreitungsgrad, Detektierbarbeit und die technische Auswirkung der Lücke analysiert. Darunter befindet sich immer eine Erklärung, wie man die Schwachstelle in seiner Umgebung feststellt und wie man sie verhindert. Weiterhin dienen Code-Beispiele als weitere Veranschaulichung. Hilfreich sind schließlich weiterführende Links. Leider gegenüber 2007 "hinten runter" gefallen sind die Länge der Hinweise bei den Schutzmaßnahmen und dort die sprachspezifischen Sicherheitsmaßnahmen.

Die folgende Tabelle stellt die neuen den vorigen Top 10 gegenüber.