Transcript

OWASP Top 10

Die gr├Â├čten Security-Risiken f├╝r Webanwendungen

Das Open Web Application Security Project ver├Âffentlicht regelm├Ą├čig eine Top 10 mit den gr├Â├čten Security-Risiken. Wer steckt eigentlich hinter dem Non-Profit OWASP? Lisa und Christoph schauen sich au├čerdem an, was in der letzten Ver├Âffentlichung so drin steht. Zu guter Letzt gibt Christoph Tipps, wie sich die Top 10 verhindern lassen und welche Konsequenzen sich f├╝r Entwickler:innen ergeben.

Back to episode

Transcript

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!