OWASP Top 10: Kritischer Blick auf die Charts
Seite 3: Kritische Töne
Dagegen, dass XXE es auf den vierten Platz geschafft hat, haben viele protestiert – vor allem Pentester. Einer von ihnen brachte es auf den Punkt: "Ich kann mich letztes Jahr nur an eine Instanz einer XXE-Schwachstelle erinnern, während CSRF beständig gefunden wurde". Das wirft die Frage auf, ob die überprüften Applikationen repräsentativ sind für die Gegebenheiten der realen Welt. Unklar blieb, inwieweit die Häufigkeit der getesteten Content Types, also XML versus HTML und JSON, was mit der Realität im Internet zu tun hat.
Verantwortlich sind laut den Release Notes statische Analysewerkzeuge (SAST). Damit die Daten repräsentativ für die Allgemeinheit sind, wäre eine passende Gewichtung notwendig gewesen.
Hinzu kommt eine weitere Unsicherheit bei der Datenerhebung: Gerade bei SAST-Daten ist zu befürchten, dass die Tools nur von den Firmen eingesetzt werden, deren Applikationen weniger repräsentativ sind, da die jährlichen Kosten durchaus mit dem Preis eines Oberklassewagens vergleichbar sind. Das begrenzt die Auswahl und schließt kleinere Unternehmen aus der Erhebung aus.
Auf der anderen Seite lässt sich nur mit vorhandenen Daten arbeiten. Statt, wie von einigen vorgeschlagen, nicht mit einem spitzen Bleistift den Data Call auszuwerten und ihn wissenschaftlich zu interpretieren, wäre es vielleicht passender gewesen, entweder das Verhältnis zwischen XML, JSON und HTML abzuschätzen oder etwas Bauchgefühl einfließen zu lassen.
In der aktuellen Situation lässt sich nur mutmaßen, ob eventuell überproportional viele XML-Backends in die Überprüfung eingeflossen sind. Bei Applikationen im Internet erscheint XML unterpräsentiert und ist eher auf dem Rückzug. JSON befindet sich dagegen auf dem Vormarsch. Abseits von Backends oder Dokumenten kommt XML vor allem bei Single-Sign-On-Diensten zum Einsatz.
Dem Team zufolge wäre für das Risiko die Auswirkung entscheidender gewesen als die Häufigkeit. Ob das in Multiplikation mit der tatsächlichen Häufigkeit, wie es in der Risikodefinition der Top 10 steht, den vierten Platz rechtfertigt, bleibt zu hinterfragen.
Ein weiterer Kritikpunkt an den Daten: XML-Parser schreiben Entwickler im Regelfall selten selber und verwenden stattdessen Libraries, die wiederum eher in die Kategorie A9 fallen – bekannt verwundbare Komponenten. Zwei Fälle bei libmxl2 sind unter anderem bekannt:
Der erste liegt gut vier Jahre zurück und hatte einige WAF-Hersteller nebst ModSecurity(!) getroffen. Der zweite Fall ist ein Jahr alt und betraf beispielsweise mit Nokogiri ein Ruby Gem, das unter anderem XML parst.
Rückblickend wäre bei den Daten somit eine genauere Betrachtung sinnvoll gewesen, ob vielleicht veraltete XML-Parser mit bekannten Schwachstellen für die Zahlen sorgten.
Reaktives Mittel Log-Dateien
Logging ist fraglos in professionellen Umgebungen wichtig zur Nachvollziehbarkeit von Ereignissen. Die OWASP Top 10 umfassen zwar zehn Risiken, aber keine Best Practices. Bei A10 erschien die Argumentation etwas schwach, dass nicht zu loggen und zu monitoren ein Risiko wäre. OWASP bewegt sich zudem auf dünnem Eis, da sie ähnlich wie beim alten A7 etwas propagiert, was Ursache und Wirkung vermischt. Anders formuliert: Ähnlich wie eine Sicherheitskamera, die einen Einbruch filmt, ist Logging mehr eine reaktive als eine proaktive Maßnahme. Aus fehlender Reaktion ein Risiko abzuleiten ist schwer. Beim Einbruch können Videoaufnahmen der Aufklärung dienen, verhindern jedoch nicht die Tat selbst. Ähnliches gilt für einen Datenbdiebstahl via SQL Injection: Die gestohlenen Daten holt das Logging nicht zurück.
Zudem haben Log-Daten nur teilweise einen aufklärenden Charakter. Meist lässt sich ablesen, wann und wie ein Angriff erfolgte. Wer ihn durchgeführt hat, ist dagegen in der Regel nicht ableitbar – die wenigsten Kriminellen sind dumm genug, von ihrer Einwahlverbindung aus zu agieren.
Im Application Security Verification Standard (ASVS) von OWASP ist zudem beschrieben, dass verünftiges Logging alles andere als trivial ist. Die Tatsache kommt in den Top 10 leider etwas zu kurz. Ein Lied davon singen können Administratoren, die ein zentrales Logging aufgebaut und unterschiedliche Logger als Zulieferer eingesetzt haben. Dabei müssen sie darauf achten, dass beispielsweise ModSecurity keine Passwörter oder Kreditkarteninformationen mitschneidet, die nicht im Klartext gespeichert werden dürfen. Deutsche Datenschutzgesetze begrenzen zudem auch die Sammelwut. Eine Logging-Infrastruktur hat einen hohen Schutzbedarf. Sie erfordert Sorgfalt im Umgang mit Zugriffsrechten und gegebenenfalls Transport- und Datenverschüsselung.
Damit die zentrale Log-Sammlung nicht zum Datengrab verkommt, das höchstens reaktiv hilft, sollte ein proaktiver Mechanismus existieren, der Anomalien aufdeckt und Log-Korrelationen vornimmt. Selbst ein SIEM (Security Information and Event Management) erledigt die Arbeit nicht automatisch, sondern erfordert hochbezahlte Arbeitskräfte, die passende Use Cases konfigurieren und weitere Fachkräfte, die die Ausgabe gewissenhaft inspizieren. Gut aufgestellt ist, wer das hinbekommt und zudem nicht wie in A10 angedeutet bei jedem von einem Scanner verursachten Internetrauschen einen Alarm auslöst, der die Mitarbeiter überflüssig irritiert.
Logging und Monitoring sind also wichtig, aber als sinnvolles Mittel nicht trivial. Zur Risikovermeidung ist der Punkt zweifelhaft. Es wäre besser gewesen, A10 ausnahmsweise als Best Practice zu kennzeichnen, statt das Fehlen als Risiken zu verargumentieren.
Eine vielleicht sinnvollere Option wäre gewesen, Logging und Monitoring eine eigene Seite in "What's next" zu spendieren.
