Seite 2: Querschau der Risiken

Inhaltsverzeichnis

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.