Seite 2: Blick auf die Charts

Inhaltsverzeichnis

Fachlich haben die Top 10 einen recht großen Schritt getan, auch wenn einiges nicht unumstritten war.

Wie (leider) nicht anders zu erwarten, hat SQL Injection erneut den ersten Platz eingenommen – in Top-10-Terminilogie A1. Noch immer können Angreifer viel zu häufig mit SQL-Befehlen in Webformularen Daten stehlen. Auf der zugehörigen Seite dazu warnen die Macher der Top 10 zusätzlich vor Injections in NoSQL-Datenbanken sowie in LDAP oder durch EL (Expression Language), wenngleich Letzteres nach Meinung des Autors seltener geworden ist.

Der zweite Platz (A2) ist mit "Broken Authentication" recht ähnlich zu 2013. Dem Titel nach ist das Session-Management weggefallen, was aber nicht dem Inhalt entspricht. Wenn man die Diskussionen auf GitHub verfolgt, an denen der Autor mitgewirkt hat, sollte das defekte Session-Management tatsächlich aus Platzgründen zunächst entfallen, da viele neue Erkenntnisse vorlagen, die mit Gefahren für die Authentifizierung zusammen hingen – eine davon sind die neuen Passwortempfehlungen des NIST (National Institute of Standards and Technology), die dem Unsinn der unbedingten Passwortrotation und der Passwortkomplexität Einhalt gebieten:

• Das Verifizieren gegen eine Mischung aus unterschiedlichen Zeichenklassen soll nicht mehr Zwang sein,
• die Passwortlänge ist der primäre Faktor zur Charakterisierung der Passwortstärke,
• eine Länge von mindestens 64 Zeichen soll erlaubt sein,
• Passwörter können ein Verfallsdatum haben und
• die Applikation soll gegen Wörterbücher, Passwörter aus "Breaches" und gegen bekannt schlechte Passwörter testen.

Neben dem Aspekt der Bedienbarkeit bei schlecht zu merkenden Passwörtern ist der Hintergrund, dass seit 2013 viele Accounts durch sogenanntes "Credential Stuffing" abhanden gekommen sind, die zweite große Gefahr für die Authentifizierungsmechanismen. Daher ist es wichtig, dass man zumindest beim Passwortcheck unbedingt gegen Wörterbücher aus Breaches prüft.

Der Punkt A3 "Sensitive Data Exposure" war 2013 als A6 zu finden. Eine passende deutsche Übersetzung wäre "ungenügende Kryptografie gespeicherter und transportierter, wichtiger Daten" – wie Kreditkarten, Passwörter und beispielsweise Session Identifier.

A4 "XML External Entities (XXE)" gehört zu den neu aufgenommen Risiken. Eine XXE-Schwachstelle kann bei XML-/SOAP-Applikationen ein defekter XML-Parser verursachen, der die Definition und den Aufruf externer Entitäten zulässt. Vereinfacht gesprochen ist dadurch eine lokale (Handler: file://) oder remote (Handler: http://) Dateieinbindung möglich, unter Umständen in einem Rutsch mit Codeausführung (phar://, jar:// oder express://). Die Auswirkung ist in den meisten Fällen fatal.

"Broken Access Control" (A5) ist konsequenter Weise ein zusammengelegter Punkt aus A4 ("Insecure Direkt Object References") und A7 ("Missing Function Level Access Control") aus 2013. A7 war das, was man unter Forced Browsing/Access bezeichnet, also das Abrufen von Objekten ohne die entsprechenden Rechte. A4 war artverwandt und bezeichnete, dass ein Zugriff auf fremde Objekte über Parametermanipulation möglich war.

Die "Security Misconfiguration" (A6) ist den neuen OWASP Top 10 zufolge immer noch ein Problem. Dabei geht es um Default-/Fehlkonfiguration von Serverkomponenten, Default Credentials und beispielsweise Stack-Traces im Browser. Das Dokument empfiehlt zeitgemäß das Setzen von Security-Headern und weiteren Härtungen in Frameworks wie Spring, Struts und ASP.NET.

Cross-Site Scripting (XSS) ist nur schwer in den Griff zu bekommen und für Pentester meistens ein gefundenes Fressen. Die Häufigkeit ist dem Data Call zufolge immer noch hoch, doch die Auswirkung im Durchschnitt eher weniger gravierend, daher ist der Punkt von A4 auf A7 gefallen.

Insecure Deserializations (A8) ist einer der beiden Punkte, die sich aus der Firmenumfrage ergeben haben. Einigen wird bei den Deserialisierungsangriffen zunächst die 2015 entdeckte Apache-Commons-Verwundbarkeit einfallen. Die Bug-Klasse ist jedoch deutlich älter und flog lange unter dem Radar. Zudem ist nicht nur Java betroffen, sondern alle Sprachen, die Objekte serialisieren – zum Speichern oder zur Kommunikation mit anderen Programmteilen – und diese schließlich wieder in ein Objekt zurückführen. Beim Deserialisieren lässt sich durch zuvor konstruierte Payloads schlimmstenfalls Code einschleusen. Die Bug-Klasse hatte zusätzliche Aufmerksamkeit gewonnen, als auf der BlackHat USA 2017 der Vortrag "Friday the 13th JSON Attacks" zeigte, dass viele .NET-Bibliotheken Probleme bei der Deserialisierung von JSON haben.

Der Punkt A9 – Komponenten mit bekannten Verwundbarkeiten – ist durch die Brille des Sicherheitsforschers betrachtet weniger spannend, aber für den Betrieb nach wie vor wichtig. Das rechtfertigt den Verbleib auf der derselben Position wie 2013. Der Punkt betrifft sowohl Serversoftware als auch Clientanwendungen. Entweder mangelt es an Patches oder es kommt beispielsweise bei Java-Applikation zum Einbinden von Bibliotheken, die bekannte Schwachstellen aufweisen. Ein weiterer Klassiker sind clientseitige Bibliotheken wie jQuery, die Firmen nach dem Installieren nie wieder aktualisieren oder überprüfen. Das gilt ebenso für serverseitige Bibliotheken.

A10 "Insufficient Logging & Monitoring" stammt nicht aus dem Data Call, sondern gehört zu den auf die Zukunft ausgerichteten Punkten. Das Risiko entsteht demnach dadurch, dass erfolgreiche und fehlgeschlagene Log-ins, wichtige Transaktionen und Fehler nicht entsprechend auf einem Log-Server protokolliert werden. Darüber hinaus sollten Systeme Scans und Fehler überwachen und beim Überschreiten von Schwellwerten einen Alarm erzeugen. Der neue Punkt geht über das hinaus, was Entwickler umsetzen können.

Aus den Charts geflogen

Die drei Neuzugänge XXE (A4), Unsichere Deserialisierung (A8) sowie Logging und Monitoring (A10) führten dazu, dass Risiken aus der OWASP Top 10 von 2013 nun ihren Chartplatz verloren haben. Durch das Zusammenlegen der beiden Punkte A4 und A7 aus 2013 zu "Broken Access Control" (A5) 2017 bleiben nur zwei Punkte (s. Abb. 2): "Cross-Site Request Forgery" (vormals A8) sowie "Unvalidated Redirects and Forwards" (vormals A10).

Beim Wegfall der "Unvalidated Redirects and Forwards" aus den ersten zehn Risiken gab es Kritik. Einige Diskussionsteilnehmer waren der Meinung, dass es nach wie vor zu häufig vorkommt, dass eine Applikation URL-Parameter vor dem Weiterverarbeiten nicht überprüft. Zwei prominente Fälle dazu:

• Im Oktober 2016 gab es eine Spear-Phishing-Kampagne, die Google benutzte, um an Gmail-Accounts zu gelangen. Das Ziel waren russlandkritische Personen. Den Angriff führte einer Analyse zufolge APT28/Fancy Bear durch – in Deutschland keine Unbekannten, da sie für den Bundestags-Hack verantwortlich sein sollen.
• Der zweite Fall betraf zwei Lücken im UK Tax Office (HMRC), die es ermöglichten, Steuer- und andere Daten von Briten anzusehen oder zu ändern.

Zudem wären nach Ansicht einiger Diskussionsteilnehmer Applikationen gerade an den heiklen Stellen verwundbar, an denen Shops zum Payment-Server-Provider weiterleiten.

Besonders viele bedauerten, dass CSRF (Cross-Site-Request-Forgery) seinen Top-10-Platz verloren hat. Das offizielle Argument ist, dass viele moderne Frameworks von Haus aus dagegen abgesichert seien. Der Autor dieses Artikels kann das nicht nachvollziehen, da selbst bei Verwendung moderner Frameworks der Schutz häufig nicht aktiviert ist. Zudem ist das Problem bei vielen Entwicklern immer noch nicht im Bewusstsein vollständig angekommen. Zur Erinnerung ein Szenario: Ein Benutzer ist bei einer Applikation in einem Reiter seines Browsers angemeldet. In einem anderen Reiter schaut er sich derweil lustige Katzenvideos an. Auf der betreffenden Seite ist allerdings ein Payload hinterlegt, der eine Transaktion Cross-Site durchführt – als GET oder POST. Also im einfachen ersten Fall über

<img src="http://kaputtebank.de/transfer.do?zielkonto=DIEB123&betrag=10000"
 width="0" height="0" border="0">

oder

<body onload="document.formular.submit()">

<form action="http://kaputtebank.de/transfer.do" name="formular"
 method="POST">

<input type="hidden" name="zielkonto" value="DIEB123">

<input type="hidden" name="betrag" value="10000"> </form>

Obwohl CSRF und die Unvalidated Redirects es nicht unter die ersten Zehn geschafft haben, sollten Entwickler und Administratoren nicht vergessen, dass diese Schwachstellen immer noch ein beträchtliches Risiko darstellen, wie die Release Notes mit dem Vermerk "retired but not forgotten" klarstellen wollen.