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

Inhaltsverzeichnis

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.

	2010	2007
1	Injection	Cross Site Scripting (XSS)
2	Cross Site Scripting (XSS)	Injection Flaws
3	Broken Authentication and Session Management	Malicious File Execution (2010 herausgefallen)
4	Insecure Direct Object References	Insecure Direct Object Reference
5	Cross Site Request Forgery (CSRF)	Cross Site Request Forgery (CSRF)
6	Security Misconfiguration (neu) ((nur 2004: Insecure Configuration Management)	Information Leakage and Improper Error Handling (2010 herausgefallen)
7	Insecure Cryptographic Storage	Broken Authentication and Session Management
8	Failure to Restrict URL Access	Insecure Cryptographic Storage
9	Insufficient Transport Layer Protection	Insecure Communications
10	Unvalidated Redirects and Forwards (neu)	Failure to Restrict URL Access

Querschau der Risiken

Die Charts der OWASP Top 10 im Einzelnen

Auf Platz 1 haben sich die Injection-Risiken vorgeschoben, damit haben sie den Platz getauscht mit "Cross Site Scripting". Beiden ist gemeinsam, dass Eingabewerte von der Webanwendung ungeprüft beziehungsweise ungefiltert weitergereicht werden. Bei Cross Site Scripting ist das immer der Browser, bei Injection-Angriffen ist es je nach verwendeter (Abfrage-)Sprache (SQL, LDAP, XML, HTML) ein anderes Backend. Die folgende Tabelle zeigt verschiedene Injection-Typen, Ziel des Angriffs und die Konsequenz.

Typ	Ziel der Injektion	Ausführen von ...
SQL	Datenbank	SQL-Befehlen
LDAP	LDAP-Verzeichnis	LDAP-Befehlen
OS Command	Code oder Datenbank	Betriebssystem-Kommandos
XPath	XML-Webservices	XML-Abfragen
Server Side Includes	HTML	Ausliefern von Seiten mit per SSI geladenen Dateien

Die Auswirkungen der meistens recht einfach gestrickten Injection-Attacken sind dramatisch, da sich mit einem Kommando fremde Daten oder Anmeldeinformationen durch den jeweiligen Interpreter auslesen lassen. Unter Umständen schafft der Angreifer es sogar, mit "OS Command Injection" Systemkommandos auszuführen und letztlich den Server zu übernehmen.

XSS-Risiken sind nach den neuen Top 10 weniger bedrohlich als Injection-Schwachstellen und schwieriger in der Praxis auszunutzen. Letzteres, weil dem Opfer zunächst einmal erfolgreich ein Link mit einem maliziösen JavaScript untergeschoben werden muss, wodurch typischerweise Account- oder Sitzungsinformationen abhanden kommen. Weniger bedrohlich ist XSS als Injection, da eben nicht in einem Rutsch Daten aus der Datenbank in fremder Hand sind.

Allerdings kann unter den Opfern auch der Account mit den administrativen Rechten der Applikation sein, und das Unterschieben des JavaScript-Codes in den Browser des Opfers ist mit etwas Fantasie und passenden Mitteln zu automatisieren. Ebenso kann XSS – mit anderen Lücken (SQL Injection, CSRF) kombiniert – noch größeren Schaden anrichten. Absolut gesehen stellt XSS ein jederzeit hohes Risiko dar, nicht zuletzt deswegen ist es in den diesjährigen Top 10 auf Platz 2 gelandet. Grundsätzlich unterscheidet man drei Typen: reflektiert (reflected), gespeichert (stored) und DOM-basiert, Näheres ist einem Grundlagenartikel auf heise Security zu entnehmen.

Um vier Plätze hervorgearbeitet auf Platz drei hat sich die "Broken Authentication and Session Management" ("Kaputte Authentifizierung und Session-Management"). Darunter hat das OWASP Risiken durch eine Reihe von Einzelproblemen zusammengefasst. Teilweise beruhen sie darauf, dass die Programmierer bei Session Management und Authentifizierung nicht die besser getesteten Funktionen ihrer Frameworks verwenden, sondern das Rad neu erfinden wollen. Ursache für die Nummer 3 sind unter anderem:

• Session Fixation (Session-ID in der URL und Weiterverwenden für Applikation)
• ungenügendes Session-Timeout
• vorhersagbare Session-IDs
• Unterstützung schwacher Passwörter
• Rückschlüsse aus Login-Fehlermeldungen
• Passwortänderungen ohne altes Passwort

Je nach Ursache und angewendetem Hack kann das erheblich technische Konsequenzen haben, wie Dave Wichers während seines Vortrag mit einem Seitenhieb auf den Mitte Juni 2010 passierten AT&T-Datenverlust betonte. Ähnlich wie bei XSS ist "Broken Authentication and Session Management" durchschnittlich einfach auszunutzen.

Abseits des Treppchens

Der auf den ersten Blick vielleicht nicht so recht griffige vierte Punkt "Insecure Direct Object References" lässt sich recht einfach mit der Schwachstelle Path Traversal oder dem Zugriff auf fremde Account-Daten (Autorisierungsproblem) erklären. Der Altvater T-Hack (siehe Datenschleuder 83, S. 16) ist hierfür eine gute Gedankenstütze.

Rang 5: "Cross Site Request Forgery", CSRF, häufig unterschätzt, ist durch die Statuslosigkeit von HTTP begründet. Der Browser muss daher jedes Mal wieder seine Session-IDs mitschicken. Bei CSRF bekommt ein authentifizierter Benutzer einen Link untergeschoben, der eine Transaktion bei der bestehenden Sitzung ausführt. Der Heise-Newsticker hatte mehrfach über solche Fälle berichtet, zum Beispiel von DSL-Routern in Mexiko (Drive-by-Pharming) und einem Hack beim Linksys WRT54GL. Auch Ciscos IOS hat es getroffen. Sofern das Zeitfenster – so denn überhaupt ein Session-Timeout existiert – für die Browsersitzung mit etwas Fantasie und/oder Automatisierung richtig ausgenutzt wird, zeigt die Praxis, dass viele Applikationen verwundbar sind. Technisch und geschäftlich ist der Schaden laut OWASP mittelprächtig. Was nach Ansicht des Autors vielleicht im Durchschnitt der CSRF-Lücken draußen im Netz stimmen mag, jedoch nicht bei den erwähnten Lücken im Webinterface der Router.

"Security Misconfiguration" an Position 6 betrifft eher nicht die Sicherheitslücken in der Software selber, sondern nachlässige Serverkonfiguration wie offene Ports, vergessene Standardeinstellungen und nicht geänderte Default-Passwörter. Auch fehlerhafte Applikationseinstellungen wie in web.config, php.ini oder offene Verzeichnisse gehören dazu. Viele der Schwachstellen sind recht einfach zu entdecken und auszunutzen. Einige der Punkte lassen sich mit den im Webkontext verpönten Scannern Nmap und Nessus aufspüren.

"Insecure Cryptographic Storage" (Punkt 7) zählt wieder zu den Softwarefehlern. Darunter fallen die in der Regel relativ schwierig direkt auszunutzenden Schwachstellen wie Speicherung unverschlüsselter beziehungsweise unverhashter Passwörter oder anderer sensitiver Daten (siehe auch PCI DSS 1.2, Anforderung 3 "Schutz gespeicherter Karteninhaberdaten"). Allerdings ist das resultierende Risiko hoch, da es für den Betreiber ein Fiasko darstellt, wenn alle Kundenpasswörter oder Kreditkarteninformationen abhanden gekommen sind und sie nicht oder nur unzureichend verschlüsselt waren.

Bei "Failure to Restrict URL Access" handelt es sich um einen Authentifizierungs- oder Autorisierungfehler, der auftritt, wenn Zugriff auf eine Funktion möglich ist, ohne sich authentifizieren zu müssen oder ohne genügend autorisiert zu sein – also der klassische Fall von "Authentication Bypass" oder "Privilege Escalation". Häufig ist bei Kenntnis der URLs – entweder durch einen passiven Scanner während einer Sitzung oder einen Crawler (aktiv) – die Schwachstelle relativ einfach zu erkennen und auszunutzen.

Der vorletzte Platz in den Charts gebührt der "Unsufficient Transport Layer Protection", der Übertragung von Account-Informationen oder Session-IDs über unverschlüsselte Seiten, ein Softwarefehler. Das OWASP zählt dazu irritierenderweise auch Konfigurationsrisiken (siehe "Security Misconfiguration"), wie falsch ausgestellte oder nicht anerkannte Zertifikate sowie die Verwendung der SSL-2-Version und schwacher SSL-Chiffren. Für Letzteres gibt es eine Reihe Testprogramme, neben ssldigger und sslscan das freie testssl.sh vom Autor.

Die Laterne der Top 10 hat das Risiko "Unvalidated Redirects and Forwards" inne. Weiterleitungen können gefährlich werden, sobald die Anwender und nicht die Anwendung kontrollieren kann, wohin weitergeleitet wird. Im einfachsten Fall ist das ein Bestandteil einer URL oder die erfolgreiche Veränderung eines HTTP-Header oder einer Umleitung via JavaScript . Das neu gelistete Risiko besteht für die Benutzer darin, Opfer von Phishern zu werden, da die URL vertrauenerweckend aussehen kann. Dazu zählen ebenso "URL-Shortener", wie David Lindsay und Eduardo Vela Nava während eines Vortrags über "Cross-Site Location Jacking" auf der diesjährigen OWASP AppSec EU unterstrichen. Das Apache-Projekt ist, wie Heise berichtete, zum Opfer gefallen.

Fazit

Kritik

2007 noch auf Platz 6, nun weggefallen, ist der Punkt "Information Leakage and Improper Error Handling". Typischerweise versteht man darunter jedwede Art von nicht abgefangenen Fehlermeldungen der Datenbank oder PHP-Fehlermeldungen. Auch HTTP 403 statt 404 gehört dazu, da dies als Informationen für eine weitere Vorgehensweise für Hacker dient. Vermeiden lassen sich derartige Gesprächigkeiten durch eine saubere Fehlerbehandungsroutine. Das Phänomen stellt laut den Verfassern der Top 10 keine unmittelbare Gefahr dar.

Ebenso nicht mehr vertreten ist "Malicious File Execution". Kritik an der diesjährigen Liste gab es deswegen von Ryan Barnett (bekannt durch das Apache-Modul mod_security): Der komplette Wegfall des PHP-intrinsischen Punkts sei nicht gerechtfertigt, da Statistiken immer noch zeigen, dass Remote File Inclusion (RFI) trotz sicherer Default-Installation ein erhebliches Problem im Netz darstellen. Letzteres untermauern die diesjährigen Q1-Statistiken von Zone-H.

Blick über den Tellerrand

Das Open Web Application Security Project ist nicht die einzige Institution, die sich um Websicherheit bemüht. Weniger der Allgemeinheit, wohl aber der Websicherheits-Szene bekannt ist das Web Application Security Consortium (WASC). Es ist wie das OWASP Initiator unterschiedlicher Projekte, darunter die im Januar 2010 erschienene "Threat Classification V2". Die Zuordnung "ihrer" Bedrohungen zu denen des OWASP zeigt Jeremiah Grossman (Gründer von WASC und CTO von WhiteHat Security) schön in einem Blog-Eintrag.

Sicherheitsberatern ist die Klassifizierung des WASC hinsichtlich der Benennung der Schwachstellen und Attacken mehr auf den Punkt gebracht. Während die Zusammenfassung aller Injection-Risiken verständlich ist, hätte man sich bei anderen der OWASP-Risiken etwas mehr Abgrenzung gewünscht: Zum Beispiel ist auf den ersten Blick nicht klar, warum das Umgehen einer Authentifizierung nun zu "Failure to Restrict URL Access" gehört und nicht zu "Insecure Direct Object References". Da sind die WASC-Termini eindeutiger. Aufgrund des feinen Unterschieds zwischen Ursache und Wirkung hält der Autor schwache SSL-Chiffren und die Verwendung der Version 2 für ein Konfigurationsproblem. Dave Wichers entgegnete dem auf der OWASP AppSec, dass es Überschneidungen dieser Art nicht auszuschließen sind.

SANS – "SysAdmin, Audit, Networking, and Security" – hat in Zusammenarbeit mit MITRE fast zeitgleich mit den Top 10 des OWASP eine ähnliche Liste herausgegeben, die "Top 25 Most Dangerous Programming Errors". Die Zielgruppe liegt, wie der Name nahelegt, eher bei den Programmierern. Auch von SANS gibt es ein "Mapping" zu den Top 10 des OWASPs. Die SANS Top 25 sind gut strukturiert. Das Schema hat MITRE mit CWE vorgegeben. Vom Umfang her haben SANS und MITRE einen guten Kompromiss zwischen Übersichtlichkeit und Menge an Informationen getroffen.

Fazit

Die neuen Top 10 stellen einen weiteren Schritt nach vorne dar. Es ist ein Werk, das trotz der erwähnten kleinen Wermutstropfen sicherlich seinem Anspruch gerecht wird, für ein gesteigertes Sicherheitsbewusstsein zu sorgen und die Softwaresicherheit im Netz ein weiteres Stückchen voranzubringen. Für die Sensibilisierung hierzulande wichtig: Eine deutsche Übersetzung ist in Arbeit und wird auf der Projektseite im Laufe des Sommers veröffentlicht.

Allerdings ersetzen die Top 10 weder ein Sicherheitskonzept noch -audits und schon gar nicht Sicherheitsprozesse in Firmen. Den drei Klientelen Entwicklern, Auditoren und Managern ist daher im Anhang der Top 10 noch jeweils eine Seite mit weiterführenden Hinweisen gewidmet, viele zu weiteren Projekten des OWASP.

Es bleibt nur zu hoffen, dass viele die Top 10 auch lesen und befolgen, getreu dem Motto: Reichlich Informationen sind da, nutze sie!

Dirk Wetter
ist Berater und Pentester im Websicherheitsumfeld. (ane)