OWASP Top 10

Lisa: Hallo und herzlich willkommen zu einer neuen Episode vom INNOQ Security Podcast. Heute ist Christoph mein Gast und wir wollen über die OWASP Top 10 sprechen. Hallo Christoph.

Christoph: Hallo Lisa.

Lisa: Erst mal zur Einleitung. Warum wollen wir überhaupt über die Top 10 sprechen?

Christoph: Ja, eine ganze Reihe von Zuhörinnen werden die OWASP Top vielleicht schon mal kennen oder wenigstens mal davon gehört haben. Und Ende letzten Jahres wurde eine neue Fassung, eine aktualisierte Fassung herausgebracht. Nach knapp vier Jahren, also 2017 war es davor das letzte Mal. Und da sollten wir vielleicht mal darüber sprechen, was sich da getan hat und was neu ist und wie man damit jetzt umgeht.

Lisa: Magst du vielleicht einmal für die Zuhörerinnen, die die OWASP noch nicht kennen, zusammenfassen oder erklären, was die OWASP überhaupt ist?

Christoph: OWASP steht für Open Web Application Security Project. Und das ist eine Community, die sich das Ziel gesetzt hat Software sicherer zu machen und vor allem natürlich Web Software sicherer zu machen. Und die Top 10, über die wir heute speziell reden, das ist eines der vielen Projekte, die die machen. Eins der bekanntesten. Aber die haben noch eine ganze Menge mehr an Projekten. Die haben dann auch noch mal so eine Unterteilung zwischen den Projekten, bei denen sogenannte Flagship Projekte sind, die ganz besonders gefördert werden und dann auch anderen Projekten. Und die haben, was auch relativ bekannt ist, sie haben eine Cheat Sheet Serie über alle möglichen Themen, Security, Testing für Mobile Security, Testing für Web Coding Guidelines und so weiter. Die sind auch sehr bekannt. Die stellen auch Software her. Es gibt einen Dependency Checker für Maven und wahrscheinlich auch noch für andere Programmiersprachen. Das weiß ich gar nicht. Der nachschauen kann, ob die Dependency, die man benutzt, veraltet sind oder nicht oder bzw. ob die Sicherheitslücken haben. Das ist auch ein Punkt auf der Top 10, kommen wir später drauf. So, was machen die? Die veranstalten Konferenzen, machen so ein bisschen Weiterbildung, also machen Webinare und so weiter und so fort. Wie gesagt, heute sprechen wir über die OWASP Top 10, über das Projekt OWASP Top 10. Eins sollte man da vielleicht wissen. Das ist kein kommerzielles Projekt, sondern das ist ein Non-Profit in den USA, gegründet 2001 glaube ich. Da bin ich mir nicht ganz sicher. Also so Anfang dieses Jahrtausends gegründet und es gibt jetzt seit ungefähr 10 Jahren auch einen Ableger in Europa. Das ist in Belgien beheimatet. Das ist so ähnlich wie so ein Verein in Deutschland, die Rechtsform. Ich kenne mich mit den belgischen Rechtsformen nicht so ganz aus, aber es ist jedenfalls auch so ein Non-Profit. Und die sind weltweit organisiert in sogenannte Chapters. In Deutschland gibt es das German Chapter und da organisieren die sich so ein bisschen selbst dabei. Es gab, jedenfalls vor Corona, es auch eine Reihe von Stammtischen, die sich getroffen haben, auch in Deutschland, wo man dann einfach so hingehen konnte. Und das ist ein bisschen so eine Community User Group treffen, wo man über aktuelle Security Themen gesprochen hat. Wie es jetzt so aktuell aussieht, weiß ich jetzt leider nicht. Solche User Meetings, Community Meetings haben bei der Corona Zeit ein bisschen gelitten. Aber gut, jeder kann Mitglied werden in der OWASP, gibt es einen kleinen Jahresbeitrag für Individuen. Es gibt auch Firmen Mitgliedschaften, die kosten ein bisschen mehr. Davon holen die sich ihr Geld für ihre Technik rein und für ihre sonstigen Sachen und Ausgaben, die die so haben. Genau, das war mal die Kurzfassung von: Was ist die OWASP überhaupt?

Lisa: Was vielleicht auch noch ganz interessant wäre, gibt es die OWASP genauso lange wie die OWASP Top 10? Oder sind die erst später entstanden? Wie oft kommen neue Versionen davon raus? Hast du da vielleicht noch ein paar Infos zu OWASP?

Christoph: OWASP gibt es etwas früher als die Top 10. ich meine 2001, ganz sicher bin ich nicht und die ersten OWASP Top 10 kamen 2003 raus. Da ist ein bisschen Verzug, die wurde auch ein bisschen von außen daran getragen bzw. aufgegriffen und man versucht die regelmäßig zu aktualisieren. Das ist aber ein bisschen problematisch, weil: das ist halt auch eine Arbeit von Freiwilligen. Da müssen Leute Energie reinstecken. Die jetzige 2021 Ausgabe war eigentlich schon für 2020 geplant. Ich meine, da kam Corona dazwischen. Das hat dann natürlich auch einiges durcheinandergewirbelt und da gilt halt, wenn’s fertig ist, ist es fertig. Es gibt da keinen Rhythmus, der sagt jetzt: wir brauchen alle drei Jahre was. Das sieht man auch, wenn man zurückblickt. Erste 2003, dann direkt 2004 eine aktualisierte Version, aber dann hält sich so ein bisschen im Drei-Jahresrhythmus. Dann gibt es 2007, 2010, 2013 und 2017 wurden es vier Jahren und jetzt 2021 sind auch vier Jahre, aber da kam es halt verspätet raus. Im Moment könnte man vielleicht einen Schnitt von drei Jahren sagen, aber ich meine, es dauert halt ein bisschen, bis die Daten gesammelt sind. Es basiert zum größten Teil auf empirischen Daten, da können wir gleich noch mal drauf eingehen und die dann ausgewertet sind. Man kann es halt wahrscheinlich nicht im Drei-Wochenrhythmus machen und da müssen wir sehen, wann die nächsten kommen.

Lisa: Du hast gerade schon gesagt, da sind freiwillige Menschen beteiligt, die die OWASP Top 10 aufstellen. Es basiert irgendwie auf empirischen Daten. Wie entstehen die denn genau? Weißt du da genaueres zu?

Christoph: Die erste Fassung davon, die ist gekommen, da haben zwei Leute von einer Firma, ich glaube, der Aspect Security eine Top 10 der Coding Errors aufgestellt und das hat die OWASP aufgegriffen und daraus die OWASP Top 10 gemacht. Wie weit die ersten Versionen auch empirisch gestützt waren, weiß ich jetzt gar nicht, aber die letzten auf jeden Fall. Und zwar ist es so, dass es da eine Befragung gibt, die aufgesetzt wird für einen bestimmten Zeitraum. Da werden halt Daten gesammelt, quantitativ und qualitativ, und zwar von Leuten, die in der Security unterwegs sind, Pen-Tester:innen zum Beispiel oder auch von Firmen, weil die haben auch erst mal Daten verfügbar. Wie oft die irgendwelchen Problemen, die in der OWASP Top 10 behandelt werden, wie oft die denen über den Weg laufen. Und die sind halt getrennt in quantitative und qualitative Daten. Warum macht man das? Wenn solche Firmen zum Beispiel automatisierte Tools einsetzen, dann gibt es ganz viele Alarme. Man kennt das vielleicht, wenn man zum ersten Mal so eine Static Code Analysis Tool in seinen Bildschirm einbaut, dann gibt es ganz viele Warnungen. Weil wenn man tausend Regeln verletzt hat. Und so ist das auch bei solchen automatischen Security Scannern. Die müssen dann halt im Kontext bewertet werden. Die sind nicht in jedem Kontext anwendbar. Das können diese Scanner dann vielleicht nicht erkennen oder sind Fehlalarme und so weiter. Deshalb ist das nicht so eine Top 10 nach dem Motto: Wie oft wurden die meisten entdeckt? Sondern es gibt auch eine qualitative Bewertung dadurch. Kann man sich sozusagen als Freitextfragen vorstellen. Und dann gibt es einen großen Datensatz und der wird dann nach gewissen Kriterien, die vorher diskutiert wurden, aufbereitet und dann kommt dann am Ende die Top 10 heraus. Wen das näher interessiert. Diese ganzen Daten und auch die Auswertung, mit welchen Schemata das gemacht wird, diese Auswertung, die sind auf GitHub verfügbar, die kann man sich runterladen. Man kann den Datensatz herunterladen und dann auch sozusagen das Excel, das die ganze Berechnung darauf anstellt, um zu sagen: So und so sieht jetzt die erste Liste aus. Wobei natürlich das Quantitative dann noch mal durch die Leute, die sich darum gekümmert haben, dann noch mal bewertet werden muss an der Stelle. Die qualitativen Daten müssen dann natürlich noch mal durch menschliche Qualitätskontrolle laufen und dann noch mal extra ausgewertet werden, um dann auf die endgültigen Top 10 zu kommen.

Lisa: Ein Link zu diesem GitHub Repo werden wir auf jeden Fall in die Shownotes packen. Damit die Zuhörerinnen noch einfach Zugriff darauf haben. Eine letzte Frage als Vorgeplänkel hätte ich noch: Sind die OWASP Top 10 nach irgendeiner Wichtigkeit sortiert? Ist das eine sortierte Liste, die wir da haben? Oder sind die einfach irgendwie zufällig angeordnet?

Christoph: Nee, die sind schon angeordnet nach der Einschätzung, welche das höchste Risiko tragen. Darauf hat man sich dann am Ende geeinigt. Aber die spiegeln nicht unbedingt die Häufigkeit wider. Man kann sagen, manche Dinge kommen viel häufiger vor, wären aber nicht so ein hohes Risiko. Und wenn man dieser Meinung ist, dann wertet man vielleicht ein anderes Risiko höher ein. Vor allem dazu dienen die qualitativen Daten, die Befragungen der Security Professionals um da die Risikobewertungen richtig hinzukriegen. Aber wie das immer so ist mit Listen. Man muss auch 10 haben. Unsere Bundesregierung mischt bei Problemen auch immer 10 Punkte Pläne auf. Das ist natürlich auch manchmal ziemlich willkürlich. Es gibt auch, wenn man auf die Webseite geht, noch so ein paar unter dem Bereich „What Next“ oder „Next Steps“, da sind noch ein paar, die so vorbeigeschrammt sind. Da kann man jetzt auch nicht unbedingt sagen, die sind jetzt weniger wichtig. Und manchmal ist es auch so, dass manche Punkte für einen im aktuellen Kontext, in dem man sich bewegt, im Projekt, in dem man sich bewegt, vielleicht gar nicht so richtig sind, während andere wichtiger sind. Die Einordnung muss man dann schon selber vornehmen. Es bietet eine gute Orientierungshilfe und was vor allem auch geschafft werden soll. Sie nennen es selbst Awareness Document. Es soll erst mal die Leute dazu bringen und gerade die nicht professionell im Bereich Security unterwegs sind, sich mit den Themen zu beschäftigen und dann eine Richtschnur zu geben. Womit würde ich mich denn zuerst beschäftigen? Was sind denn die wichtigen Themen? Und da kann man die 10 dann schon nehmen und zwar gleichwertig. Und bei der Reihenfolge, dann schauen: Was passiert denn sozusagen in freier Wildbahn am meisten? Dann habe ich halt noch mehr Orientierungshilfe, wenn ich sage, ich kann jetzt nicht mich um zehn Punkte gleichzeitig kümmern, sondern ich muss jetzt irgendwo anfangen, dann fange ich vielleicht einfach bei dem ersten Punkt an und arbeite die sozusagen der Reihenfolge nach ab.

Lisa: Okay, ich glaube, das war genug Vorgeplänkel, Christoph. Wollen wir einfach mal die zehn Punkte aus der 2021er Fassung durchgehen? Und zwar von dem hinteren zu dem vorderen, um die Spannung bis zum Schluss aufrechtzuerhalten.

Christoph: Gerne, wie bei der Hitparade. Von Platz 10 auf Platz 1.

Lisa: Sehr gut. Christoph, was ist auf Platz 10 der OWASP Top 10 2021 gelandet?

Christoph: Auf Platz 10 ist der Punkt Server-Side Request Forgery (SSRF). Da ist schon mal ein ganz interessanter Punkt dabei, weil der ist gar nicht in den quantitativen Daten aufgetaucht. In den Daten, die man gesammelt hat, war kein einziger Fall von dieser Sicherheitslücke zu finden. Trotzdem haben alle gesagt, das ist total wichtig, weil das tritt jetzt immer mehr vermehrt auf. Weil es vor allem da auftaucht, wo man so in einer Cloud Umgebung ist und alles verschiebt sich so. Das müssen wir mit aufnehmen. Von daher schon mal zum Thema qualitative, quantitative Bewertung ist das mit drin. Jetzt auf dem letzten Platz der Top 10, aber trotzdem wichtig. Was heißt das jetzt? Es ist eigentlich relativ einfach. Als Angreifer versuche ich eine Web Applikation dazu zu bringen, ein Request zu machen für eine Ressource, die nicht an ihrem Ziel landet, sondern vielleicht irgendwo ganz anders und um das mal als Beispiel zu nennen. Wir haben vorne einen Webserver, der ist wirklich im Web exposed, also verfügbar. Und dahinter sind andere Systeme. Die haben wir aber gar nicht direkt ans Netz geklemmt. Die kann man nicht direkt aufrufen. Und wenn ich jetzt den Server dazu bringe, vielleicht diese Services im Hintergrund aufzurufen und dort Informationen nach draußen zu geben, dann habe ich einen Server-Side Request Forgery. Also nehmen wir mal an, wir sind jetzt in der Cloud. Ich habe gesagt, da trifft das besonders auf und haben so einen Kubernetes Cluster. Da habe ich manche Services Eexposed und aber ganz viele Sachen, ganz viele Ports laufen nur intern. Die Datenbank oder irgendwelche anderen internen Services, die vielleicht Anbindung an SAP, was auch nicht direkt am Netz hängt. Und jetzt kann ich dem Server irgendwie was unter schmuggeln, dass der dahin einen Request macht und mir die Antwort liefert. Und das hat schon, das verlinken wir vielleicht mal in den Shownotes, schon einige schlimme Sicherheitslücken aufgerissen. Zum Beispiel bei der Google Cloud und ich glaube auch bei Amazon hatten wir schon einiges, wo man intern Services bei machen kann. Wir können zwar aber ganz einfach ein Beispiel nehmen, damit es ein bisschen greifbarer wird. Es gibt so Services, downforeveryoneorjustme, wo man einfach eine URL eingibt und dann versucht er die aufzurufen und sagt: Ich kann die erreichen. Das heißt, in deinem Netz kannst du da vielleicht nicht drauf zugreifen. Und dann kriegt der Server als Parameter eine URL. Da könnte ich jetzt aber zum Beispiel auch eingeben: 127.0.0.1 und irgendeinen Port, der dann lokal ist. Da könnte ich zum Beispiel versuchen auf lokale Ports zuzugreifen, oder es gibt so IP Ranges, wie private Netze sind. Dann könnte ich davon IP machen. Das wird er versuchen, wenn er dagegen nicht abgesichert ist, dagegen einen Request zu machen und mir da vielleicht Informationen liefern. Und jetzt auf die Cloud zurück. Das ist schon mehrfach so aufgetreten. Wenn ich so eine virtuelle Maschine habe, die haben noch eine IP, da kann man die Metainformation der virtuellen Maschine abrufen und welche Rollen die haben und so weiter und so fort. Und die waren dann vielleicht auch von außen erreichbar, obwohl die eigentlich nur von dieser Maschine erreichbar sein sollen. Und von daher, ich glaube, die Einschätzung, teile ich, dass uns das in Zukunft noch deutlich mehr begegnen wird.

Lisa: Spannend. Ja dann, was gibt es auf Platz 9 zu entdecken?

Christoph: Was gibt es auf Platz 9? Das ist auch ein sehr spannendes, das ist Security Logging and Monitoring Failures. Das ist eigentlich gar keine konkrete Lücke, die da ist. Das hat sich mit der Zeit ein bisschen geändert, das war so das Erste. 2017 ist das zum ersten Mal aufgetaucht. Und da gab es ein bisschen Diskussion darüber: Warum wird das denn aufgenommen? Das ist so gar keine konkrete Lücke. Wenn Logging fehlt, kann ich davon nicht gehackt werden. Ganz einfach gesprochen. Das Problem dabei ist aber, es gibt so ein paar Studien, die als Aussage haben: Von dem Zeitpunkt, wo ein System kompromittiert wurde und dem Zeitpunkt, wo das entdeckt wird, vergehen ca. 6 Monate. Dann muss man ein bisschen vorsichtig sein bei solchen Studien. Die Datenlage ist natürlich alles andere als gut. Oft erfährt man das auch nicht und das geht nicht irgendwie in öffentliche Datensätze ein, die man einfach mal analysieren kann. Aber nehmen wir mal an, das ist so. Dann liegt es oft daran, dass man nicht die richtigen Maßnahmen beim Logging und beim Monitoring hat. Was würde man dann haben? Was sind so konkrete Beispiele, wenn ich sage, es gibt bestimmte Security relevante Events und die logge ich einfach nicht. Zum Beispiel, dass ich nicht logge, wenn ein Login fehlschlägt, dann könnte man sagen: Ja, es ist jetzt erst mal nicht so schlimm. Das kann mal passieren, kann sich mal jemand beim Passwort vertippen oder ähnliches. Aber wenn ich zum Beispiel einen Brute Force Angriff erkennen will, wär es schon gut, wenn ich wüsste, wie oft die Logins nicht funktioniert haben. Oder dann schauen kann, dass irgendwie so ein Credential stuffing ist. Das andere ist, Logging hilft natürlich später, also wenn ich kompromittiert wurde, vielleicht den Weg rauszufinden, über die Events genau zu sehen, wo ist denn was passiert? Und dann vielleicht herauskriege in so einem post mortem, wie die Angreifer überhaupt in das System eindringen können. Was anderes ist hier das Monitoring. Monitoring heißt jetzt nicht auf Basis der einzelnen Log-Nachricht irgendwas nachvollziehen, sondern da macht man so was wie: Wie viele Request pro Sekunde sind da? Oder wie ist gerade die CPU Auslastung? Wieviel I/O mache ich? Und da kann man zum Beispiel sagen: Ich habe jetzt ganz viel CPU Last und das ist aber jetzt irgendwie gar nicht normal, weil ich habe vielleicht bekannte Traffic Spike Muster. Ich weiß, einmal im Online-Shop kaufen die Leute typischerweise zwischen 12 und 14 Uhr in ihrer Mittagspause ein. Da habe ich immer so einen Spike und dann wieder ab 17 Uhr und sonst ist es ruhig. Und auf einmal sehe ich, dass die CPU ziemlich belastet ist, auch dazwischen. Könnte es vielleicht ein Anzeichen sein, dass ich so ein Crypto Miner eingefangen habe und der auf so einer Maschine läuft. Das ist jetzt nur ein Beispiel dafür, warum ich dann ein vernünftiges Monitoring brauche. Und das dritte ist, was eigentlich neu ist für dieses Jahr oder bzw. noch dazugekommen ist gegenüber dem letzten, das hat jetzt mit den beiden vorigen, mit der Erkennung von Problemen erstmal nichts zu tun, sondern ich kann auch Probleme haben, wenn ich was logge. Wenn ich zum Beispiel Kreditkartendaten logge oder Secrets. Mein Server fährt hoch und sagt: Ich starte jetzt mit folgenden API Key, dann ist das auch nicht gut. Das sind Daten, die typischerweise nicht in Log Dateien landen sollten, wo dann ganz viele Leute vielleicht drauf Zugriff haben. Das ist sozusagen neu dazugekommen. Das Loggen von sensiblen Daten. Da kann man einiges gegen machen. Da gibt es eine ganze Reihe von Tools für so ein Monitoring, die auch eine Art von Anomalieentdeckung haben. Wichtig ist, wenn man dagegen vorgehen will, um das zu ändern, heißt jetzt nicht, dass die Admins oder die Entwickler, die dafür zuständig sind, ständig auf die Logs starren und da mal schauen: Was ist denn da los? Ich brauche schon irgendeine Art von automatischer Anomalie Entdeckung, die mir dann einen Alert geben, wo ich dann nachprüfen kann. Ist das jetzt vielleicht wirklich im Crypto Miner oder ist meine Werbeaktion einfach nur gut gelaufen und ich habe jetzt mal so einen Traffic Spike, weil das Marketing so toll gearbeitet hat. Das muss dann schon noch ein Mensch unterscheiden, meistens. Aber trotzdem muss man das natürlich komplett automatisieren. Und dafür gibt es auch eine ganze Reihe Tools, im Bereich Open Source. Das ist sowas, was man relativ leicht machen kann.

Lisa: Okay, dann kommen wir jetzt zu Platz 8. Was finden wir da?

Christoph: Die Nummer 8 sind Software and Data Integrity Failures. Da sind wieder mehrere Punkte. Das ist nicht so wie bei Server-Side Request Forgery, dass es genau eine Lücke ist, sondern da sind mehrere Lücken oder Arten von Lücken zusammengefasst. Bei der Integrity geht es darum, dass ich bestimmte Integritätsprüfungen mache. Da kann das der Fall sein. Zum Beispiel, wenn ich mir Komponenten von woanders herhole. Zum Beispiel meine Dependencies während des Builds. Da könnte es durchaus sein, ich habe zwar eine Dependency, da weiß ich, das will ich haben. Das hat eigentlich kein Bug. Aber vielleicht klemmt sich jemand dazwischen und liefert was anderes aus. Und deshalb gibt es meistens solche Features bei den Package Managern, dass sie auch so eine Check Summe haben oder dass Sachen digital signiert sind. Wenn ich so ein Auto Update habe, dass mir da niemand was unterjubelt und wenn ich so eine Check Summe habe oder eine Signatur, dann überprüfe ich auch damit die Integrität des Pakets, was ausgeliefert wird. Ein bekanntes Beispiel dafür, wo so was unterlaufen wurde, sind wenn bei diesem SolarWinds Hack, wo das automatische Update Malware ausgeliefert hat. Sowas könnte man vielleicht entdecken, wenn es signiert ist. Das Problem bei dem SolarWinds Hack war natürlich, dass man auch das Schlüsselmaterial zum Signieren gestohlen hatte und damit auch die manipulierten Pakete, die dann aufgespielt wurden auch richtig signieren kann. Dann kann man damit mit so einer Verifikation der Integrität auch nicht mehr viel tun. Aber das fällt dann mal auf, wenn Pakete verändert werden und dieses Schlüsselmaterial ist nicht in den Händen der Angreifer. Ein weiterer Punkt und der war früher ein einzelner, noch in der 2017er, ist Insecure Deserialization. Das heißt, viele Programmiersprachen können Daten serialisieren. Ihre Objekte oder Strukturen und die dann wieder deserialisieren. Sie schreiben das auf Platte, den Zustand des Objekts. Und dann, wenn sie es deserialisieren, lesen sie das ein und dann haben sie wieder den Objektzustand hergestellt oder das Objekt wiederhergestellt. Das kennt jeder, wenn wir das als JSON speichern und das dann wieder in so eine Struct oder eine Klasse parsen, dann haben wir auch eine Art von Serialisierung, Deserialisierung. Da kann man mit XML machen. Es gibt noch eine Menge Binärformate, um das kompakt zu halten. Java hat das als Standard Feature. Da gibt es das Interface Serializable, dann weiß ich, das Objekt kann ich irgendwie serialisieren und deserialisieren. Und da ist das Problem, wenn ich die serialisierte Variante aus einer Quelle bekomme, der ich nicht vertrauen kann, dann könnte die manipuliert sein. Und wenn ich dann deserialisiere, dann könnten diese Manipulationen Dinge auslösen, die ich nicht will. Warum ist das so? Weil diese Deserialisierung auch in vielen Frameworks und Sprachen heißt es, da könnte ich eine Code Ausführung mit triggern und das deserialisierte Objekt, wenn es deserialisiert wird, führt automatisch irgendeine Art von Code aus und dann ist das schlecht, wenn es manipuliert werden kann. Das heißt, ich führe eigentlich den Code des Angreifers der Angreiferin aus. Deshalb sollte ich da auch versuchen irgendwie Integritätsprüfung zu machen. Ich könnte dieses Objekte auch versuchen zu signieren oder wenigstens mit so einem MAC, Message Authentication Code zu versehen. Oder ich mache überhaupt keine Deserialisierung aus irgendwelchen Quellen, denen ich nicht vertrauen kann. Einer der größten Hacks, jedenfalls finanziell, Equifax in den USA, der beruhte auf genau diese Art von Bug. Equifax, kurzer Einschub, das ist eine Firma, die hat ganz viele Daten, vor allem über die US-Bürger, Sozialversicherungsnummer, Kreditstatus, was weiß ich, was alles. Und die wurden gehackt dadurch, dass sie ein Web UI Framework benutzt haben, Struts, ist schon sehr alt und der speichert einen gewissen Status auch in so serialisierten Objekten auf den Clients. Und da hat man dann Fehler gefunden, dass die Deserialisierung da nicht alles korrekt überprüft und das heißt, man konnte beliebigen Code ausführen. Das Schlimme dabei war, da kommen wir vielleicht noch gleich auf einen anderen Punkt. Das war lange bekannt, bevor die das gepatcht haben. Die haben das erst Monate später gepatcht und da war es dann schon gehackt. Der war sehr teuer. Das hat die angeblich um die 700 Millionen Dollar gekostet. Dmuss man sehr aufpassen. Wenn es geht, am besten immer gar nicht serialisieren oder deserialisieren oder ein reinen Datenformaten, die jetzt keinen Code mit deserialisieren können. Das Problem dabei ist, wenn ich ganze Objekte mache, dann habe ich sozusagen die Daten und auch die Methoden. Wenn ich aber nur die Daten serialisiere, dann wird der Code nicht wieder deserialisiert. Das heißt, JSON ist ein Format, womit das zum Beispiel ganz gut geht. Aber generell sollte man da ein bisschen aufpassen.

Lisa: Ich hätte nur mal kurz eine Nachfrage. Und zwar hattest du gerade gesagt, dass die Insecure Deserialization früher ein eigener Punkt war und jetzt mit unter diesem Software and Data Integrity Failures gefasst wurden. Passiert es häufiger, dass Punkte zusammengefasst werden oder eventuell auch entzerrt werden in der Geschichte der OWASP Top 10?

Christoph: Eher werden sie zusammengefasst. Früher war es eher so, dass wir relativ konkrete Sachen hatten, wie jetzt auf Platz 10, Server-Side Request Forgery. Das ist genauso ein Problem. Aber man ist ein bisschen dazu übergegangen, Sachen, also mehrere Probleme, unter einem Punkt zu fassen. Man kann jetzt in den aktuellen auch nachschauen, die merken das auf CWEs heißen die, das ist das Common Weakness Enumeration Project. Da gibt es also für einzelne Programmierfehler, Lücken, gibt es genau eine CWE. Und dann gibt es da irgendwie ein paar Hundert von. Und unter vielen Punkten, die wir jetzt hier in den OWASP haben, sind so zwischen 4 bis 20 CWEs darunter gefasst, weil die die gleiche Art sind und vor allem, weil die Gegenmaßnahmen relativ gleich sind. Jetzt bei dem Punkt, wo wir gerade sind, ist die durchgängige Nutzung von digitalen Signaturen oder Message Authentication Codes die Gegenmaßnahmen. Das ist sowohl wenn ich auf Komponenten von dritten Parteien mich verlasse, genauso wie wenn ich selbst etwas deserialisiere, dann kann ich das mit den selben Abwehrmaßnahmen absichern. Und deshalb sind die ein bisschen zusammengefasst.

Lisa: Okay. Ich glaube, dann bin ich bereit für den Platz 7 in der OWASP Top 10.

Christoph: Genau der Platz 7 ist Identification and Authentification Failures. Und da haben wir auch wieder eine ganze Reihe an Punkten, die einen eigenen CWE haben. Was kann da drunter fallen? Zum Beispiel gibt es, wenn es keine Gegenmaßnahmen gegen automatisierte Angriffe gibt. Das habe ich vorhin schon gesagt, zum Beispiel auch Passwörter. Brut Force Angriffe oder Credential Stuffing oder Spraying. Das heißt also das Ausprobieren von geleakten Passwörtern oder von Standard Passwörtern. Und wenn ich das nicht erkenne, dann sind wir eigentlich wieder bei dem Punkt 9. Dann kann ich das nicht automatisch abschalten. Es gibt eine Möglichkeit, zum Beispiel zu sagen: Auf so einem Account limitiere ich erst mal die Anzahl der fehlgeschlagenen Logins und sperre ihn dann erst mal für eine Zeit. Dann ist ein Brute Force Angriff eher nicht gut möglich. Problem dabei ist natürlich, weil wir die so simpel machen, wenn er gesperrt wird, dann kann ich natürlich auch versuchen, einfach beliebige Accounts von anderen Leuten zu sperren. Da muss man ein bisschen aufpassen. Eine andere Möglichkeit wäre IP-Adressen von wo eine Brute Force Attacke ausgeht zu sperren oder ähnliches. Was dann noch darunter fällt ist, dass man zum Beispiel Standard Passwörter nimmt oder auch zulässt, dass es schwache Passwörter sind. Verweis auf die Passwort Folge, was ist ein gutes Passwort? Ist nicht so einfach. Diese Regeln sind meistens nicht gut, aber dass man sagt, das hat so eine gewisse Mindestkomplexität. Das muss zum Beispiel mindestens 10 Zeichen lang sein oder so. Das ist vielleicht nicht schlecht oder genauso dass schon geleakte Passwörter erlaubt werden. Es gibt die haveibeen0wned Datenbank, da kann man das schon überprüfen und dann wäre es gut, wenn man das ablehnt. Wenn sich jemand registriert und man weiß: Dieses Passwort ist schon geleaked, dann sollte man das nicht zulassen. Es gibt aber auch andere Arten, die jetzt nicht so auf die Passwörter treffen. Zum Beispiel, dass man eine vernünftige Session Management macht. Dass man zum Beispiel eine neue Session anlegt nach dem Login oder dass man die Session IDs dies nicht unbedingt in URLs klemmt, weil die dann verloren gehen können. Oder in Cookies, die nicht gegen den Zugriff über JavaScript geschützt sind, oder über die das Secure Flag nicht gesetzt haben. Das heißt, dass die über HTTP, also über unverschlüsselte Verbindungen laufen können. Die Sessions muss man irgendwie schützen. Und da ist ein ganz großer Punkt in Sachen vernünftiges Session Management. Oder dass man solche Tokens, die jetzt auch bei OpenID Connect OAuth benutzt werden, nicht richtig invalidiert dabei, also einen Logout nicht vernünftig macht. Dass man, wenn man so ein Token hat, sich an anderen Systemen noch anmelden kann, weil die nicht wissen, dass der User sich schon längst abgemeldet hat. Alles, wo die Authentifizierung eine Rolle spielt, kann man viel falsch machen und das ist da drunter gepackt. Das sind sehr viele Punkte, sehr viele einzelne Schwächen darunter gefasst. Aber das Gute ist, es gibt auch immer so ein bisschen. Was kann man denn tun? Und hier sind so Empfehlungen, Multi-Factor-Authentifizierung oder solche Policies für Passworts, die die Komplexität machen oder die Anzahl der fehlgeschlagenen Logins begrenzen, bevor man den Account zeitweise sperrt und so weiter und so fort.

Lisa: Da können vermutlich auch Frameworks unterstützen, um die Fehler zu vermeiden.

Christoph: Auf jeden Fall, vor allem beim Session Handling. Da gibt es in jeder Sprache eigentlich Möglichkeiten, die einem das abnehmen und die die ganzen Sachen implementiert haben, wie man solche Sessions gut schützt und auch vernünftig validiert. Genauso auch mit den Tokens, mit der Validierung und Invalidierung. Da gibt es Libraries und Frameworks für, die einem das abnehmen können.

Lisa: Okay, Christoph, Platz 6, der OWASP Top 10. Ich bin gespannt.

Christoph: Platz 6 sind Vulnerable and Outdated Components. Ganz bekannt natürlich. Heutzutage nehmen wir x tausend Dependencies bei uns mit auf in die Projekte, weil wir nicht alles selbst machen wollen. Haben wir gerade auch empfohlen, nehmt doch Libraries, nehmt doch Frameworks, aber das heißt, die können auch manchmal Schwachstellen haben. Und wenn die bekannt sind, dann ist das schlecht, wenn man die weiter benutzt. Und ich hatte vorhin auf diesen Equifax Hack hingewiesen und die haben es lange danach benutzt, nachdem das bekannt war. Da würden die eigentlich da auch unter die Nummer 6 fallen und nicht nur unter die Nummer 8. Je nachdem, von welcher Seite man das begreift. Der Bug, der ausgenutzt wird, fällt unter die 8. Aber warum konnte man den ausnutzen? Wegen der Nummer 6, weil die so lange eine Komponente benutzt haben, die schon längst bekannt war, dass sie nicht in Ordnung ist. Das ist wieder relativ eindeutig. Bekannte Sicherheitslücken und was so ein bisschen noch dazukommt ist, dass man Sachen benutzt, wo der Maintanence Status nicht klar ist oder der klar ist, dass man sagt: Das wird nicht mehr maintained. Das heißt, vielleicht ist da noch keine Sicherheitslücke bekannt, aber es kümmert sich auch gar keiner drum. Das heißt nicht, dass die öffentlich bekannt ist, sondern das können auch die entsprechenden Angreifer so was horten für Angriffe. Und dann wird auch nicht mehr darauf reagiert, wenn sowas rauskommt. Das sollte man machen. Und natürlich, wir vertrauen unglaublich vielen Quellen. Wenn wir 100 Dependencies haben, kennen wir wahrscheinlich keinen einzigen Maintainer von diesen Dependencies, sondern wir vertrauen da jeder Menge Quellen, die irgendwelche Leute im Internet bereitstellen. Ist vielleicht auch nicht immer das Beste. Da muss man sehen, wie man damit umgeht. Am besten ist natürlich, Dependencies zu minimieren, aber das ist heutzutage nicht so ganz einfach. Das große Stichwort ist hier Supply Chain Security. Außer der Minimierung der Dependencies müsste ich natürlich auch schauen, dass ich das automatisiert scanne. Man sagt immer, wenn ich zum Beispiel baue, dann schaue ich, ob die Dependencies denn noch aktuell sind und ob es bekannte Sicherheitslücken gibt. Und wie gesagt, dafür gibt es zum Beispiel von der OWASP einen Dependency Check als Tool. Gibt es aber wahrscheinlich in vielen Sprachen. Das ist eine Lücke, die immer in Folge von vielen anderen kommt. Wenn ich woanders was erfahre und das nicht fixe, weil die anderen jetzt ein anderes Problem hatten, das auch auf der Liste ist, dann lande ich irgendwann wahrscheinlich bei der Nummer 6. Und was noch ganz wichtig ist, das hatte der Stefan in der letzten Folge erzählt. Dieses Dependency Skinning darf ich nicht nur machen beim Bauen, sondern das muss ich ganz regelmäßig machen. Weil gerade bei Projekten, die jetzt im Maintainance Modus sind, die keine Updates mehr erfahren und vielleicht nur noch Bugfixes mal, erfahre ich das vielleicht erst gar nicht. Wenn ich sage, ich baue das alle sechs Monate, dann waren sechs Monate Zeit, dass irgendwelche Komponenten Lücken hatten, die dann aufgetaucht sind, die dann nicht gefixt wurden. Eigentlich muss ich das immer mal einmal am Tag durch den Bildprozess jagen um zu sehen: Da ist was oder da ist nichts.

Lisa: Dann haben wir die erste Hälfte der Sicherheitslücken OWASP Top 10 geschafft und können mit den spannenderen durchstarten. Und zwar die Top Five quasi. Was befindet sich auf Platz 5?

Christoph: Auf Platz 5 ist die Security Misconfiguration. Ich würde dir noch mal direkt widersprechen. Die spannendsten. Also gerade die Nummer 6, die wir gerade besprochen haben, finde ich super spannend. Weil das ist, was uns im Moment so im Atem hält und so ganz viele Probleme verursacht und wo wir echt wenig tun können zurzeit. Ich hätte die vielleicht höher bewertet, jedenfalls in der qualitativen Bewertung, wenn ich dabei gewesen wäre. Ich habe mir jetzt die genaue Auswertung nicht angeschaut. Aber gut, kommen wir zu Nummer 5. Security Misconfiguration. Worum geht es da? Das prominenteste Beispiel ist das S3 Bucket, was man einfach vergessen hat, irgendwelche Zugangsbeschränkung darauf zu setzen und da sind irgendwelche Produktivdaten drauf sind, die eigentlich nicht in dritte Hände gehören, die aber jeder abrufen kann. Genauso geht es darum, wenn ich ein neues System aufsetze, ein Betriebssystem zum Beispiel. Das kann eine ganze Reihe an Services anbieten, auf irgendwelchen Ports horchen. Wenn ich Linux installiere habe ich bei der Server Variante vielleicht Mailserver, LDAP Server, was weiß ich für einen Server noch offen und das will ich eigentlich nicht haben. Und eigentlich heißt es immer, man muss nachdem man so was aussitzt und Security Hardening machen. Das heißt alles abschalten, was man nicht braucht. Default Accounts und Passwörter entfernen und so weiter. Und das muss man auch beachten. Das ist jetzt aus Entwicklersicht ein bisschen weniger der Fall. Heutzutage arbeiten wir meistens so mit irgendwelchen Docker Images oder ähnliches. Da haben wir das vielleicht nicht mehr so drin, aber irgendwer setzt auch das Betriebssystem auf, auf dem der Kubernetes Cluster läuft. Und wenn wir irgendwie in einem DevOps Umfeld sind, machen wir das vielleicht als Entwicklerinnen auch selbst. Von daher muss man immer aufpassen. Und da hilft es, dass man so einen automatisierten Prozess hat, um so was aufzusetzen, der auch so was abschaltet. Da gibt es Tools, Puppet, Ansible, Chef und Co., die so automatische Systeme einrichten können. Oder wenn wir im Cloud Bereich sind, hier TerraForm vielleicht zu nennen. Und die müssen auch so automatisiert sein oder müssen die Automatisierung so weit treiben, dass sie dieses Hardening machen. Alles abschalten, was man nicht braucht. Auf Entwicklerinnenseite trifft uns das auch manchmal. Wir haben gerade gesagt, wir benutzen Frameworks oder andere Anwendungen und die können auch Settings haben, die dann vielleicht nicht sicher sind im Grundzustand. Sagen wir mal, es gibt eine ganze Reihe von Web Frameworks, die haben eine Debug Konsole, die man an sich im Browser ansehen kann. Django zum Beispiel oder sowas. Und Play hat sowas glaube ich auch. Auf jeden Fall gibt es eine ganze Reihe. Und wenn ich standardmäßig alles ist, ist das natürlich schlecht, weil da Informationen drin sind, die eigentlich zum Debugging gedacht sind und nicht für den allgemeinen Gebrauch, wenn wir das in Produktion bringen. Wenn die standardmäßig eingeschaltet sind, dann muss ich die ausschalten. Deshalb ist auch immer gut, wenn man das selbst macht so ein Framework. So ein Secure by Default Pattern wäre dann zu benutzen. Das heißt, all solche Dinge muss ich erst mal explizit einschalten. Was auch helfen kann ist, dass man so ein Secure Development Lifecycle nimmt, wo es solche Checkpoints und Checklisten gibt für sowas, wo man dann sagen kann: An dem Punkt haben wir das dann alles mit drin, wenn wir es nicht ganz so groß nehmen wollen. Wenn man im Agilen unterwegs ist und vielleicht seine Definition of Done hat, dann könnte man auch sagen, dass man ein Review der Konfiguration immer vornimmt als Teil der Definition of Done. Das könnte man machen. Es gibt auch automatisierte Scanner dafür. Gerade, wenn man so Standard Produkte einsetzt, die dann sowas erkennen können. Zum Beispiel für so S3 Buckets gibt es das schon von Amazon selbst, die einen dann warnen, das ist jetzt zum Beispiel hier öffentlich zugänglich. Willst du das denn auch? Von daher muss man immer aufpassen. Und da ist das Problem, dass je mehr Komponenten und Softwareprodukte man einsetzt, desto mehr Konfigurationsmöglichkeiten hat, desto mehr Möglichkeiten da sind, dass man das falsch konfiguriert oder dass die Standard Konfigurationen nicht sicher sind und man davon vielleicht auch gar nicht viel mitkriegt.

Lisa: Okay, dann es weiter mit Platz 4.

Christoph: Platz 4 ist ganz interessant: Insecure Design. Da fallen sehr viele Sachen drunter und das ist sehr heterogen. Ich hatte vorhin mal erwähnt, gleichartige Sachen werden unter einem Punkt gemacht. Das ist neu. Insecure Design in der 2021er und das ist sehr breit. Sie schreiben aber auch extra, das ist jetzt keine Resterampe hier. Alles, was man nicht zuordnen kann, einfach in Insecure Design. Das aber schwierig fassbar. Man geht aber davon aus, dass man einfach so ein paar Standard Sachen macht, bei denen wir sagen können: Okay, die fallen auf jeden Fall da drunter. Zum Beispiel, dass man überhaupt keine Security Controls berücksichtigt, wenn man seine Software designt oder die Architektur dafür macht. Security Controls sind alles Maßnahmen, um Software sicherer zu machen bzw. gegen Bedrohungen zu schützen. Was kann das sein? Security Control kann sein, dass ich sage, dass ich überhaupt ein Access Control einbaue. Irgendeine Schranke, wo man unterscheidet, ob Operationen erlaubt sind oder auch nicht. Ich kann nur sagen, es gibt einfach alles frei, jeder kann alles machen. Das wäre dann ein Insecure Design. Weil das ist relativ bekannt, dass man ein Authentication und Autorization System braucht. Es kann aber auch sein, dass man bekannte Sachen nimmt, wo man sich im Allgemeinen darüber einig ist, dass das kein gutes Design ist. Ein Beispiel dafür ist, wenn ich mein Passwort vergessen habe, dass es diese Sicherheitsfragen gibt. Wie ist der Mädchenname? Wie hieß das erste Haustier? Was war der erste Kinofilm, was ist ihr Lieblingskinofilm und so weiter. Und da rannten alle Werke, die sich damit beschäftigen, Standardwerke, sonstigen Publikationen davon ab, sowas zu nehmen. Weil in Zeiten von Social Media kriegt man diese Fragen relativ leicht raus. Und wenn man ein System baut und dann sagt man: Für meinen Recovery Prozess das Passwort setze ich solche Fragen ein, dann hat man was falsch gemacht. Dann hat man ein Insecure Design gewählt. Genauso kann es sein, wenn ich jetzt in der Fachlichkeit unterwegs bin und die Fachlichkeit schlecht moderiere, dann könnte ich auch ein unsicheres Design haben. Ein Beispiel: Ich bin im Onlineshop und ich habe irgendein Objekt, das Bestellungen repräsentiert. Und dann erlaube ich da auch einen negativen Wert bei der Anzahl. Ich bestelle mir jetzt MacBooks oder den neuen Super Desktop Mac für 8000 Euro und mache als Anzahl -10 und jetzt werden mir 80000 Euro gutgeschrieben. Dann ist die Domäne nicht sicher designed worden. Das kann auch darunter sein. Deshalb ist es sehr breit gefasst. Worum geht es da? Eigentlich geht es um die Gegenmaßnahmen. Und das ist ganz wichtig. Das soll ein bisschen dazu inspirieren. Was kann man dagegen tun? Dass ich zum Beispiel Threat Modeling einsetze. Threat Modeling. Dazu müssen wir vielleicht auch mal eine Folge machen, ist, dass ich erst mal die einzelnen Gefahren erkenne, beschreibe, Risiko abschätze: Wie hoch ist die Wahrscheinlichkeit, dass es eintritt? Wie groß ist der Schaden? Das geht auch dann ins Risk Management über. Das machen viele auch gar nicht. Oder beziehungsweise wird es ein bisschen extern gemacht. Einmal am Anfang, aber es passt nicht in den eigenen Kontext, wo sich so ein System ständig wandelt. Dass ich erst mal der Gefahren bewusst bin und auch eine Priorisierung vornehmen kann und sagen kann: Folgende Gegenmaßnahmen setze ich im Allgemeinen ein. Das kann man machen. Um es wieder eine Nummer kleiner zu machen. Wir sind hier im agilen Bereich. Man könnte auch solche Abuse-Szenarien einbauen. Wenn man seine Use Cases macht. Was heißt das? Sagen wir mal, wir arbeiten und agieren mit User Stories für den Login. Und dann sage ich: Login Recovery. Da kann ich da eine Abuse Story machen und sagen: Wie kann man das denn jetzt vielleicht gar nicht im guten Sinne nutzen, sondern das irgendwie missbrauchen? Und wenn ich das mit aufschreibe, komme ich erst mal auf Gefahren an und kann versuchen, die durch das Design schon abzuwenden. Was man natürlich noch machen kann, jetzt wieder mehr auf der technischen Ebene, dass ich ein Security Development Lifecycle mache, dass Security von der vordersten Planung bis zur Implementierung bis zum Rollout irgendwie eine Rolle spielt. Und es gibt sogenannte Secure Design Patterns. Das lehnt sich ein bisschen an diese Design Patterns, die man als Entwicklerin typischerweise kennt. Da gibt es Secure Design Patterns, die dann sagen, wie ich bestimmte Security Probleme löse. Dafür gibt es Pattern. Es gibt zum Beispiel den Secure Logger oder den Input Validator Pattern. Die kann ich dann anwenden, auf der einfachen Code Ebene. Aber das ist schwierig zu fassen. Das ist auch nicht ganz die Abstraktionsebene, dieses Risiko Insecure Design, das die anderen unbedingt haben.

Lisa: Dann kommen wir jetzt zu Top 3 der OWASP Top 10. Was ist auf Platz 3 zu finden?

Christoph: Auf Platz 3 ist Injection. Es war jahrelang die Nummer 1. In der reinen Injection, vorher als SQL Injection, das hat sich ein bisschen gewandelt, was darunter gefasst ist, das ist aber der Klassiker. SQL Injection, kennt man vielleicht oder kennt fast jeder. Man hat es jetzt verallgemeinert über alle Möglichkeiten, wie man eine Injektion machen kann. Es kann SQL sein. Es kann auf der Shell sein, es kann LDAP sein, es kann eine Expression Language sein, die verschiedene Frameworks benutzen. Grundproblem ist, es sind irgendwelche Daten, denen man eigentlich nicht vertrauen kann. Zum Beispiel von einem User, werden nicht richtig validiert, bevor sie weiterverarbeitet werden. Das heißt, da müsste ich eigentlich die Daten schon vorher ablehnen, um zu sagen: Nee, das passt jetzt nicht so. Und der zweite Punkt ist, wenn ich sie dann weiterverarbeite, werden sie nicht richtig encoded für den Kontext an die ich das sende. Einfaches Beispiel ist Cross-Site scripting, was einfach nur heißt. Ich schicke an eine Web Applikation Daten, die dem User wieder zurückgespiegelt werden. Und wenn ich da JavaScript drin packe, dann könnte es sein, dass die Daten, die mir wieder in den Browser zurückgeschrieben werden, dann einfach als JavaScript ausgeführt werden. Wenn ich in der Google-Suche eingeben würde: <script>alert("Hello World")</script>. Sozusagen literal als Script, und dann mit dem JavaScript Quellcode drin. Dann schickt mir bei der Suche, wie mir das zurückgeschickt und da wird es aber nicht ausgeführt, weil es richtig encoded ist, die Sonderzeichen, die spitzen Klammern, die wir für so einen Tag brauchen, die werden dann umgewandelt, dass die dann zwar erscheinen, aber nicht ausgeführt werden. Und diese beiden Sachen muss man da beachten. Da ist recht es einfach, was dann auch zu tun ist. Alle Daten, die reinkommen, müssen richtig validiert werden. Zum Beispiel mit dem Input Validator Pattern, weil bei Import Validation muss man auch einige Sachen beachten. Was validiere ich wann? Erstmal kann ich validieren: Woher kommt der Request? Kann ich dem vertrauen oder nicht? Kann man nicht in jedem Kontext machen, aber wäre zum Beispiel für Server-Site Request Forgery auch schon ganz okay. Wenn ich sage die Systeme, die damit erreicht werden, die internen, die könnten validieren: Woher kommt der denn? Und würde ich diesem System überhaupt antworten? Darf ich das ansprechen? Geht nicht immer, muss man auf dem Kontext sehen. Manchmal kann man das nicht machen. Wenn man ein System hat, das am Web hängt, kann potenziell jeder eine Anfrage stellen an dieses System. Dann kann man das nicht machen. Aber da gibt es dann noch mehr Validierung. Auf der technischen Ebene, da kann man erst mal die Größe validieren. Ich könnte versuchen Denial of Service zu machen, weil ich dann irgendwo immer Gigabyte-weise Requests hin schicke und wenn er die erst in den Speicher nimmt und dann erst eine Validierung macht. Das wäre schlecht. Also muss ich schon vorher sagen: Ich nehme nur Request bis 8, 16, 64 Kilobyte an. Und wenn das da drüber geht und ich lese das noch ein vom Netzwerk, dann muss ich da schon abbrechen. Und dann gibt es da noch Validierung auf der syntaktischen Ebene, JSON, XML, wir kriegen Form Encoded Sachen und prüfen erst mal: Kann ich das richtig decodieren oder ist da vielleicht schon ein Fehler in der Syntax drin? Und ganz am Schluss kommt die semantische Validierung. Sind da auch Daten drin, die so stimmig sind, mit meiner Programm Semantik? Also zum Beispiel zurückgreifens auf das Beispiel von vorhin, mit der negativen Bestellmenge. Jetzt kommt ein Request rein, der eine Bestellung auslösen soll. Und da steht ein negativer Wert drin. Dann kann das syntaktisch alles richtig sein. Die Größe kann richtig sein und die Anfrage ist auch okay, aber semantisch ist das natürlich Unsinn, dann würde ich das auch ablehnen. Und alles was dann durchkommt, muss ich trotzdem noch mal dann entsprechend des Kontexts richtig encoden. Was man noch besser macht, ist natürlich, dass ich solche Anfragen nicht ganz frei gestalte, sondern mehr auf LPIs gehe, die irgendwie parametrisiert sind und sicher. Was heißt das? So ein SQL Prepared Statement ist eine API, wo ich sicher Daten reinstecken kann. Das ist eine Save API oder wenn ich ein OAM benutze, ist das auch typischerweise eine sichere API. Das Problem ist, bei SQL ist es ganz gut gelöst, bei vielen anderen Sachen ist es schwieriger. Da gibt es diese Save APIs eher weniger. Die muss ich mir dann auch selbst schaffen. Wenn ich vorne einen Request annehme, muss ich das so gestalten, dass so eine Injection von Anfang an unmöglich wird. Und wie gesagt, es war jahrelang die Nummer 1. Und jetzt ein größerer Punkt, SQL Injection ist schon 2013 dazugekommen oder erst in 2017. Aber was jetzt neu dazugekommen ist, ist Cross-Site scripting. Das war früher auch ein einzelner Punkt und das ist aber auch nur eine Code Injection. Ich kann irgendwie versuchen dem Server Codes unterzujubeln, den er dann wieder an andere Browser ausliefert, die den ausführen. Deshalb ist Cross-Site scripting verschwunden und es in Injection mit aufgegangen. Und trotzdem der Abstieg auf den dritten Platz.

Lisa: Spannend. Wir sollten auf jeden Fall in den Shownotes noch mal die Folge verlinken, wo wir schon mal über Input und Output gesprochen haben. Und ich finde, wir sollten auf jeden Fall noch das xkcd Comic mit dem Little Bobby Tables verlinken, weil das sollte man tun, wenn man SQL Injection irgendwo erwähnt. Wir nähern uns dem Ende der Liste. Was ist auf Platz 2 zu finden, Christoph?

Christoph: Ja, auf 2 sind die Cryptographic Failures. Alles, was mit Kryptografie zu tun hat, was da schiefgehen kann. Das kann sein, dass sich alte oder gebrochene kryptographische Protokolle, Algorithmen oder Systeme benutze. Wo ist der Unterschied? Protokolle, Algorithmen, Systeme. Algorithmus ist ein Verschlüsslungs-Algorithmus wie AS, zum Beispiel, das ist ein Algorithmus. Protokoll ist sowas wie TLS. Da kommen mehrere Algorithmen zum Einsatz, die ich verwenden kann, aber das gesamte ist ein sogenanntes Protokoll und Systeme sind noch mal da drüber. Zu dem TLS gehört dann vielleicht auch noch eine PKI dazu. Da, wo die Zertifikate alle herkommen und ich vielleicht auch überprüfen kann, ob die sicher sind. Vielleicht verlinken wir auch noch die alten Folgen. Das mit TLS plus den unterliegenden Algorithmen ein ganzes Krypto System. Und da gibt es eine ganze Reihe Sachen, die kaputt sind. Alles was unter TLS 1.2 ist, ist eigentlich gebrochen. Wenn ich das noch benutzen will, nutze ich Sicherheitsprotokolle, die nicht mehr in Ordnung sind. Es gibt Hash Funktionen, die gebrochen sind, MD5 zum Beispiel, die ich nicht mehr benutzen sollte. Und wenn ich das noch benutze, dann ist natürlich die Chance, dass es irgendwie ausgenutzt wird. Genauso geht es darum. Ich kann natürlich auch Sachen, die prinzipiell sicher sind, nicht korrekt anwenden. Was heißt das? Zum Beispiel hängen die Sicherheit der Verschlüsselungsfunktion davon ab, dass man einen guten Zufallsgenerator hat, also gute Zufallszahlen. Und deshalb gibt es immer den sogenannten kryptografisch-sicheren Zufallszahlen-Generator in vielen Systemen. Aber ich könnte jetzt auch einen nehmen, der aus der Mass Library meiner Programmiersprache kommt. Und die sind da nicht so sicher, weil die gehen zum Beispiel, wenn man den gleichen Seed nimmt, immer die gleichen Zahlen raus. Das hat seinen Sinn. Wenn ich zum Beispiel Simulationen mache, will ich, die vielleicht auch wenn Zufallswerte drin sind, wiederholen können. Aber für Kryptographie sind die nicht sicher. Und wenn es dann heißt: Ich nehme jetzt hier einen sicheren Verschlüsselungsalgorithmus, wie zum Beispiel das AES-GCM, der braucht sogenannte Initialisierungsvektor und wenn da der Zufall da nicht richtig ist und erwartbar ist, dann wäre das schlecht. Oder um bei diesem Beispiel zu bleiben, AES-GCM. Ich darf niemals mit dem gleichen Schlüssel und im gleichen Initialisierungsvektor zwei Dinge verschlüsseln, weil wenn jemand ihn in die Hände bekommt, kann man daraus das Schlüsselmaterial ableiten. Das heißt, ich brauche immer wieder neue Initialisierungsvektoren, weil der Schlüssel typischerweise gleich bleibt. Oder ich nehme den AES ECB Modus, der nur 128 Bit verschlüsseln kann und dann verschwitze ich aber damit ein paar Kilobyte und das ist auch nicht gut. Was anderes ist, jetzt mal von diesen Systemen weg, wenn ich zum Beispiel die Verschlüsselung gar nicht erzwinge. Wenn ich zum Beispiel das möglich mache, ich hatte vorhin Cookies erwähnt, die auch über unsichere Kanäle kommen, unverschlüsselt, weil das Secure Flag nicht gesetzt ist. Das wäre auch eine Cryptographic Failure. Und wenn man dagegen was machen will, dann muss man ganz früh anfangen. Und zwar gar nicht bei der Kryptographie, sondern man muss erst mal anfangen, den Bedarf festzustellen. Erstmal muss ich die Daten herausfinden, die ich entweder beim Transport oder bei dem sogenannten Arrest, also wenn sie irgendwo gespeichert wären, verschlüsseln muss. Das muss ich erst mal heausfinden, bevor ich dann die aktuelle Kryptografie richtig ansetzen kann, muss ich das erst mal herauskriegen, weil das ist nicht alles, nicht alles muss verschlüsselt sein. Wenn ich jetzt sage, meine Schriftarten, meine Bilder, mein CSS, das muss ich jetzt nicht verschlüsselt gespeichert haben auf meinem Webserver. Ich will da zwar verschlüsselt übertragen, weil ich grundsätzlich die TLS sprechen will, aber das muss ich jetzt nicht, während es gespeichert ist, noch mal verschlüsselt haben. Wenn ich vielleicht sensible Daten über eine Krankheit beim Arzt, die will ich auch auf der Festplatte verschlüsselt gespeichert haben. Weil wenn die dann wegkommt, sollte die nicht zugreifbar sein, wenn die Festplatte, wo das CSS drauf ist, wegkommt. Aber das wäre mir das auch egal. Das ist der erste Punkt. Und dann fange ich an zu sagen: Okay, ich nehme das, was aktuell sicher ist und dann auch noch richtig angewendet, was nicht immer so einfach ist. Und worum man sich natürlich immer mehr drum kümmern muss, ist auch, wenn man in die Cloud geht, dass ich mit dem ganzen Schlüsselmaterial und den ganzen Geheimnissen die da herumschwirren auch vernünftig umgehe. Wenn ich meine TLS Zertifikate habe, auf der Server Seite gehört auch immer noch der private Schlüssel, der geheime Schlüssel dazu. Den muss ich auch vernünftig aufbewahren und nicht so, dass ich da von tausend Systemen darauf zugreifen könnte. Das heißt dann Key und Secrets Management. Das muss man natürlich auch richtig machen.

Lisa: Okay, Christoph, ein kleiner imaginärer Trommelwirbel für den Platz 1 der OWASP Top 10. Wer hat es geschafft, die Injection von Platz 1 zu stoßen?

Christoph: Ja, das ist der Broken Access Control. Und das ist auch ein Dauerbrenner in der OWASP Top 10, weil das war schon auf der 2003er, der ersten Version auf Platz 2. Und ist eigentlich schon relativ lange in verschiedenen Formen dabei und 2017, davor war er auf Platz 5. Das ist obwohl, es so ein Dauerbrenner war, in manchen, wie 2010 rausgefallen bzw. war es zum Teil in anderen Punkten da. Aber jetzt ist es Platz 1. Worum geht es da? Da sind auch Punkte drunter, die vorher einzeln waren. Vielleicht ist es deshalb rausgefallen. Da geht es darum zum Beispiel, dass ich keinen Access Control überhaupt erst mal anwende an meinen Methoden. Was heißt Access Control? Es ist einfach eine Entscheidung: ist die Operation, ist der Zugriff erlaubt oder nicht? Und ein beliebtes Muster ist, dass ich das zum Beispiel an URLs hänge. Also wenn meine Webanwendung eine URL hat und irgendwo /admin, ist sozusagen der Admin Bereich, dann hänge ich an der URL und sage: Da darf nur jemand zugreifen, der die Rolle Admin hat. Aber in den URLs ist vielleicht nicht so cool, weil wenn ich die URL ändere oder irgendwie anders an diese Funktion komme, wird das einfach ausgeführt. Deshalb sollte man eigentlich versuchen diese Access Controls an die Methoden, also an die Logik oder an die Geschäftslogik zu hängen. Irgendwo in meinem Code habe ich jetzt, was mein Admin nur ausführen darf, ist zum Beispiel neue User anlegen. Dann könnte ich das an der URL machen. Wo oben stehen: admin/new-user. Das ist ganz schlechter API Design, wenn man es so macht. Aber nehmen wir das mal so an. Da könnte ich neue User anlegen oder ich kann das anlegen, an der eigentlichen Methode, die dann irgendwo im Java Code sagt: New User und dann als Parameter die ganzen Daten aufnimmt: Name, Passwort, blablabla. Dann müsste ich das eigentlich eher an der Methode machen. Weil dann ist egal von wo ich das aufrufe und wie auch der Code ist, bis der dahin kommt, spielt keine Rolle, sondern es wird immer an der Stelle, wo es auch wirklich benutzt wird, abgeprüft. Und das ist zum Beispiel ein beliebter Fehler. Oder dass man so eine Policy hat, dass man erst mal aus Prinzip alles erlaubt, also alles: Allow all. Das kennt man man vielleicht aus dem Webserver. Da gibt es Zugriffsmöglichkeiten, Beschränkungen auf virtuelle Webserver, auf Verzeichnisse und da kann man entweder auf: Allow All oder Deny All. Eigentlich sollte man immer erst mal alles verbieten und erst dann öffnen. Das ist ein bisschen unkomfortabel in der Entwicklung, weil man muss dann erst mal alle Fälle finden: Wo erlaube ich das denn? Und am Anfang geht nichts. Deshalb ist es oft eher umgekehrt. Aber man macht sich dann hinterher bemerkbar, dass irgendeiner einen Weg an den Policies vorbei findet oder irgendeinen Weg findet, die nicht abgedeckt ist und schon kommt man da drauf. Was auch darunter fällt. Und das war früher ein einzelner Punkt, sind die Insecure Direct Object References. Das heißt, wenn ich direkt eine ID von so einem Objekt expose und darauf dann zugreifen kann. Zum Beispiel durch URL Manipulation. Nehmen wir mal an, ich kann meine Rechnungen abrufen bei irgendeinem Dienstleister und da steht dann oben in der URL eine numerische ID: 100. Wenn ich dann 101 mache, dann bekomme ich den nächsten Kunden und 102 den danach. Wenn es einfach durchnummeriert ist. Deshalb sollte man so eine ID da nicht exposen bzw. erratbar machen. Das heißt, das war früher ein typischer Fehler, der besonders daher kam, weil viele Web Frameworks das einfach so gemacht haben, das einfach so durchnummeriert haben. Heutzutage nimmt man oft UUIDs oder irgendwelche Hashes. Da kann man das nicht mehr erraten. Aber das fällt auch darunter. Was auch darunter fällt, wenn ich Metadaten manipuliere, die mit meiner Identität zu tun haben. Sagen wir mal, ich habe einen Cookie, da steht drin, wer ich bin, meine Session, da stehen auch meine Rollen drin. Da steht drin: Ich bin jetzt in der Rolle „Gast“ und dann manipuliere ich einfach den Cookie und schreibe darin: Ich habe jetzt die Rolle „Admin“. Wenn das nicht überprüft wird und da sind wir dann bei dem Punkt Integritätsüberprüfungen, bei Punkt 8. Wenn sowas jetzt nicht überprüft wird, dann haben wir das Problem, dass ich mir einfach zusätzliche Rechte verschaffen kann. Was auch selten gemacht wird und das ein Problem ist, dass Ownership nicht mit berücksichtigt wird, sondern nur die Operation. Was heißt das? Nehmen wir mal an, unser Programm hat so die typischen CRUD Operationen, also Create, Read, Update, Delete. Dann heißt das, es wird gesagt, ich kann jetzt zum Beispiel neue Sachen erschaffen mit - Create und ich sie lesen - Read und ich kann Updates machen, aber ich kann nicht löschen. Wäre jetzt eine Möglichkeit. Aber wichtig ist auch: Wem gehören denn die Daten? Sagen wir mal wieder um beim Online-Shopping Beispiel zu bleiben, ein Warenkorb. Ich habe jetzt die Rechte im Warenkorb, da kann ich Sachen reinlegen und die kann ich auch wieder löschen oder ein Update machen, indem ich sage ich will jetzt: 20 Max, natürlich negativ, damit mir 160000 Euro gutgeschrieben werden, dann sind das an den Operationen. Aber man muss auch gucken, auf welchen Warenkorb. Ich könnte jetzt nicht deinen Warenkorb manipulieren. Jedenfalls sollte es so sein. Das heißt, die Daten haben auch einen Ownership und den muss ich mit berücksichtigen. Und das wird eher selten getan, weil das auch viele Frameworks nicht so leicht unterstützen, weil das sehr von der Fachlichkeit abhängt. Und das heißt, da muss man viel Aufwand selbst betreiben und deshalb fällt es manchmal ein bisschen hinten drüber. Und ein wichtiger Punkt ist noch: Solche Sachen sollte ich natürlich irgendwie auch vielleicht vom Framework machen lassen oder irgendwie diesen Mechanismus einmal implementieren und überall machen. Man kennt das vielleicht so, wenn man in einem Spring Feld unterwegs ist oder auf Java I. Da macht man eine Annotation an die Methode und gibt die Bedingungen, unter welchen Bedingungen die jetzt aufgerufen werden können. Da schreibt man dann zum Beispiel im einfachsten Fall einfach die Rollen dran. Role Admin bei Create User und der ganze Mechanismus, wie entschieden wird. Welche Rolle hat er denn gerade? Und wie wird das entschieden? Wird dann über AOP, abgeändert bei Java. Und es gibt für viele Sprachen solche Frameworks und das sollte man machen, weil da kann man, allein auch in der Implementierung, verdammt viele Fehler machen. Deshalb muss man ein bisschen aufpassen. Und ich bin mir nicht ganz sicher, aber ich meine, das ist jetzt so weit oben, weil es extrem vermehrt aufgetreten ist in den quantitativen Daten und qualitativ würde ich das auch stark bewerten, weil das hat natürlich extreme Auswirkungen. Manches hat vielleicht nicht so ganz so schlimme Auswirkungen wie wenn ich jetzt mehr Zugriffe habe. So ein Server-Site Request Forgerx ist vielleicht nicht so schlimm wie dass ich als Admin zugreifen kann, wenn ich eigentlich eine Gastrolle habe.

Lisa: Damit haben wir es alle geschafft. Alle Lücken sind einmal abgedeckt. Wie ist das denn, wenn ich eine Sicherheitslücke habe, wie zum Beispiel Log4Shell. Lässt sie sich eindeutig einer dieser zehn Punkte zuordnen oder ist das nicht so einfach mit der Zuordnung?

Christoph: Das ist gar nicht so einfach. Man sollte das nicht alles so als schwarz oder weiß, 0 oder 1 sehen. Wir haben das vorhin bemerkt bei den Sachen. Alles was man hat, in Third Party Libraries von den Sachen und man ist nicht geupdated, dann hat man automatisch auch einen Vulnerable and Outdated Components Ding an der Backe. Aber wenn wir jetzt Log4Shell sehen, das ist ein schönes Beispiel, weil das kann man eigentlich in drei Sachen einordnen. Erstmal ist das eine Injection. Das muss gelogged werden und wir müssen in diese Log Nachricht irgendwie was reinmachen. Das ist dieser JNDI Aufruf, der dann losgeht. Das ist eine Injection. Aber was passiert dann? Über diese JNDI wird irgendein Server aufgerufen, der eigentlich gar nicht aufgerufen werden sollte. Also haben wir Server-Site Request Forgery. Wir zwingen den Server dazu, einen Aufruf auf ein anderes System zu machen, wo eigentlich gar kein Aufruf hingehen sollte. Also haben wir schon zwei. Aber die eigentliche Lücke, dass jetzt Code ausgeführt wird, die kommt noch. Das ist nämlich dann der Punkt Software and Data Integrity Failure. Und zwar Insecure Deserialisation. Was passiert von dieser JNDI URL, auf einen Server, auf den gar nicht zugegriffen werden soll, kommt jetzt ein Objekt rüber und das wird deserialisiert. Da das Objekt unter der Kontrolle der Angreiferin war, wird halt Code von den Angreiferin ausgeführt. Also haben wir schon mindestens mal drei Punkte auf die Log4Shell zutrifft, die man da einordnen kann und wo man jetzt eigentlich auch keinen von wegstreichen kann. Die treffen alle zu und wenn ich einen davon mich hätte, würde sie diese Lücke nicht funktionieren. Und wenn wir jetzt noch einen drauf toppen, natürlich, die Leute, die es immer noch nicht gepatcht haben, die sind jetzt bei den Outdated Components und hätten sozusagen Nummer 4 dabei. Wobei das natürlich immer irgendwie dann zutrifft, wer nicht updated, landet immer in der Vulnerable and Outdated Components.

Lisa: Jetzt haben wir so viel über diese ganzen Lücken und die Top 10 gesprochen. Aber was kann ich jetzt konkret als Entwicklerin daraus mitnehmen? Wie hilft mir diese OWASP Top 10? Und was sollte ich mir jetzt auf jeden Fall merken für mein Projekt und meinen Alltag?

Christoph: Die OWASP macht selbst so eine Einschätzung wofür das ist. Das sagen das ist ein Awareness Dokument und das ist vielleicht auch für Training geeignet. Das kann man sich dann mal anschauen, das verlinken wir auch, wozu man das eigentlich alles nehmen könnte. Aber was ich wichtig finde, sind gar nicht die Lücken selbst, sondern die ganzen Gegenmaßnahmen, weil das sind Patterns und Designs und auch eine Architektur, die man mitnehmen kann und von Anfang an berücksichtigen kann. Wenn ich mir so ein System gestalte, dann kann ich direkt auf vernünftiges Logging und Monitoring achten. Ich kann direkt schauen, dass ich Access Controls irgendwo unterbringe und zwar von Anfang an. Ich kann schauen, dass ich in meinem Entwicklungsprozess solche Abuse Stories zum Beispiel einbaue. Dann haben wir das Insecure Design abgedeckt. Die ganzen Gegenmaßnahmen sind eigentlich Sachen, wo ich sage, die muss man nicht speziell einbauen, wenn man sich mit Security auskennt, sondern die müssen wir immer in unsere Systeme einbauen. Und von daher würde ich sagen, diese Gegenmaßnahmen führen automatisch zum besseren System Design und mit denen sollte man sich vor allem beschäftigen, weil man weiß vorher nicht, was ein treffen wird. Aber wenn ich die Gegenmaßnahmen schon mal von vornherein berücksichtige, dann wird das Ausmaß viel geringer sein, beziehungsweise ich werde dem vielleicht entgehen. Log4Shell konnte man dann nicht unbedingt angehen, weil das ist typischerweise so ein Third Party Ding. Aber was ist eine Gegenmaßnahme. Ich muss zum Beispiel immer Patch-fähig sein. Ich muss immer ein Deployment machen können, damit ich einen schnellen Patch ausrolle. Wenn mein Deployment Prozess heißt, wir machen alle sechs Monate ein Deployment und brauchen zwei Wochen für einen Hotfix, dann ist das schlecht. Was kann ich daraus lernen? Gegenmaßnahme ist eigentlich Deployment Fähigkeit. Eine der Gegenmaßnahmen. Und das ist auch ein gutes System Design, wenn ich immer Deployment fähig bin. Das wollen wir auch aus ganz anderen Gründen. Deshalb für mich steht da im Vordergrund aus der Entwicklung jetzt nicht als Security Expertin. Guckt euch die Gegenmaßnahmen an, die führen euch relativ leicht zum guten System Design.

Lisa: Ich glaube, was wir auch auf jeden Fall verlinken sollten, die OWASP hat auch noch das Projekt Juice Shop und sie bewerben das selbst, mit der kann man die OWASP Top 10 auch mal quasi von der anderen Seite kennenlernen. Das ist so ein lustiges kleines Ding, womit man sich mal beschäftigen kann, finde ich.

Christoph: Da kann man diese ganzen Lücken mal selbst aus der Seite der Hackerin ausprobieren und gucken, dass man das knackt. Von der Design Seite würde ich mir das nicht zum Vorbild nehmen.

Lisa: Auf keinen Fall.

Christoph: Aber das ist gut. Ich finde es auch gut, dass es auch mal aus einer anderen Perspektive zu sehen, ist nicht schlecht. Und wenn man sich dann vielleicht auch noch ein bisschen intensiver damit beschäftigt und sieht, wie schnell man sowas vielleicht auch automatisieren kann, dann weiß man, warum man vielleicht Gegenmaßnahmen von Anfang an mit bedenken muss. Da verliert man ein bisschen die Denke: Ja, mich trifft das nicht. Wer hat schon Interesse daran? Das spielt keine Rolle, sondern das sind automatisierte Angriffe, wo ich dann vielleicht das ganze Netz danach scanne, ob ich da eine bestimmte Lücke finde. Und dann habe ich erst mal den Rechner übernommen oder das System kompromittiert und kann dann weitersehen, was ich damit mache. Ich kann das nutzen als Startpunkt für weitere Angriffe auf andere, vielleicht attraktivere Ziele. Aber ich kann auch versuchen Ransomware zu einem Angriff zu machen und Geld zu erpressen und so weiter. Und wenn man sieht, wie leicht das manchmal ist oder was man automatisieren kann, das hilft auf jeden Fall dabei zu verstehen, warum man das von Anfang an machen muss. Gegenmaßnahmen im Design verankern und nicht erst hinten dran.

Lisa: Ja, sehr schön. Schönes Schlusswort, Christoph. Vielen, vielen, vielen Dank für diese spannende Folge zu den OWASP Top 10. Mir hat es sehr gut gefallen. Ich hoffe, dass es euch da draußen auch gut gefallen hat. Falls ihr irgendwas sagen möchtet zu dieser Folge, könnt ihr uns gerne eine Mail schreiben an [email protected]. Wenn es euch sehr gut gefallen hat, freuen wir uns natürlich auch über eine gute Bewertung auf der Podcast Plattform eurer Wahl, wo ihr gerade unterwegs seid. Und ich würde mal sagen vielen Dank, dass ihr dabei wart und dann bis zum nächsten Mal. Tschüss!