 So, fangen wir an. Genau, OWASP Top 10, wer kennt OWASP? Wer weiß, was heißt? Aber es ist auch so, dass die das gar nicht mehr dekronisiert haben wollen. Das soll nur noch OWASP heißen, aber ursprünglich, hieß das mal, genau das ist die Webseite, hieß das mal Open Web Application Security Project. Da kommt der Name her, aber da es nicht mehr nur noch Web Applications sind, ich zeige das gleich mal kurz, was OWASP eigentlich alles macht. Tendiert man es dazu, das gar nicht mehr aufzulösen, sondern nur noch, da war es bisher so wie eine WESPE, das ist jetzt so das Logo und das ist der Begriff, aber man benutzt die Auflösung eigentlich gar nicht mehr so sehr. Genau, alles, was die OWASP macht, ist immer frei verfügbar. Alle Dokumente, alle Vorträge, die haben auch eine eigene Konferenz, es wird auch immer alles aufgezeichnet und die Vorträge davon, die sind auch immer frei verfügbar. Genau, also da kommt es ursprünglich her, ist es aber nicht mehr, es ist viel mehr geworden in den letzten Jahren. Das Ganze ist auch eine Non-profit-Organisation. Sie sagt, es gibt alles, es ist immer frei zugänglich und für alle benutzbar, auch wenn viele Industrie-Partner dahinter stehen. Das ist ein Grundsatz von der ganzen Organisation. Und die haben eine eigene Security-Konferenz, die nennt sich Application Security. Es gibt eine in den USA, eine in Europa, die regelmäßig stattfinden und noch eine in Asien, die unregelmäßig stattfindet, aber da kann man sich immer guten Input holen. Das Ganze ist irgendwie auch ein Local-Chapters-Organisation. Es gibt auch einen Stammtisch in Karlsruhe, es gibt noch vier, fünf mehr in Deutschland, in München, Frankfurt, Hamburg, weiß ich jetzt nicht genau, also in vier bis fünf. Da kann man hingehen, findet man die Ankündigung, kann man auf der Obers-Seite nachsuchen. Wie gesagt, hier in Karlsruhe gibt es auch ein, es ist immer Montagabend, einmal Monat, wenn es stattfindet. Genau, kann man spannende Leute treffen oder auch ein bisschen mithelfen, komme ich gleich noch drauf. Genau, es gibt unglaublich viele Tools, Dokumentation, das Top 10 Projekt fällt in die Dokumentationskategorie und Guidelines, wie man Dinge tun kann und wie kann man halt alle frei verwenden. Diese ganzen Projekte, die Tools, die Dokumente und auch die Guidelines werden so in Entwicklungszustände einsortiert, damit man das ein bisschen besser einschätzen kann und für den Zustand befindet sich das Projekt. Es gibt Flagship, das Top 10-Risk-Projekt ist zum Beispiel ein Flagship-Projekt, das gibt es schon sehr lange. Es ist sehr etabliert, es ist als Referenz etabliert. Also sozusagen die hochentwickelten Projekte danach sind so im Lab-Modus, das so medium. Da gibt es Leute, die arbeiten aktiv dran und die entwickeln sich weiter und dann gibt es Inkubator-Projekte, die sind noch ganz frisch. Da sind vielleicht auch nur ein, zwei Leute dran beteiligt. Weiß man nicht, ob die überleben. Hier sind so ein paar Beispiele, was es alles gibt. Also nicht alles, ein paar Beispiele. Ich glaube, es sind im Moment in Summe 140 Projekte bei der O-Wars organisiert, also das über alle drei Kategorien hinweg. Über eins davon rede ich heute, die Top 10-Risk, die sind das bekannteste. Da gibt es auch Related to Proactive Controls. Das ist dann eher wie verhindere ich die Risiken. Es steht also in direkter Korrelation dazu. Dann gibt es zum Beispiel als Tool, kennt vielleicht einige hier im Raum, Proxy, mit dem man halt Angriffe durchführen kann oder halt seine Anwendung testen kann und das auch automatisieren kann. Neues, ein relativ junges Projekt, O-Wars Top 10 Privacy-Risk, da rede ich morgen noch mal drüber. Dann gibt es auch Dinge, die stehen alle auch immer in Bezug zu diesen Risiken. Sehen wir später auch noch im Vortrag. Zum Beispiel Application Security Verification Standard. Da gibt es jetzt auch eine Mobile Edition von, weil, wie wir alle gemerkt haben, gibt es irgendwie ganz viele Mobile-Anwendungen inzwischen gar nicht mehr diese klassischen webbasierten Sachen, wobei es dann wieder drunter liegt. Da passiert ganz viel. Was auch sehr oft, sehr wichtig sind die Sheets, weil da ist für den Entwickler zumindest dann ganz konkret drin, was ist eigentlich das Problem? Wie kann ich das in meiner Programmiersprache beheben? Das gibt es dann also auch immer für unterschiedlichste Programmiersprachen, Frameworks und so weiter. Und da das Ganze aber nicht reicht, nur zu programmieren, gibt es auch, das ist auch ein Dokumentationsprojekt sozusagen. Wie organisiere ich eigentlich? Software, Entwicklung, was gehört da alles dazu, wenn ich das sicher machen will? Zeige ich auch gleich noch ein, zwei Sachen dazu. So, ja, ein Non-Profit-Organisation. Das ist, so wie sieht die Webseite aktuell aus? Sieht nicht wie 2017 aus. Deswegen ist es auch so ein bisschen auf Mithilfe angewiesen. Es ist auch mal schön, wenn dann Leute einfach mal mitmachen. Es gibt jetzt auch ein Projekt, was daran arbeitet, die Webseite schicker zu machen. Da kann man sich auch einfach daran beteiligen. Ist vielleicht auch nicht ganz verkehrt. Genau. Jetzt zum eigentlichen Thema. Von weg hat noch so ein bisschen um das einzusortieren. Also das Top-10-Projekt ist eigentlich beschreibt Risiken, die man haben kann in Anwendung, die natürlich auf Softwareproblemen meistens beruhen. Und mal so ein größeres Bild zu zeigen, das ist auch ein Oversprojekt, das Open-Send-Projekt-Software-Scholens-Majority-Modell. Was muss ich eigentlich alles tun, um Software zu bauen, wenn ich das ein bisschen robuster machen will? Das ist nur so ein Security-Fokus. Man muss auch Leute irgendwie trainieren. Man braucht Regeln, man braucht sichere Konfigurationen. Man muss sich vorher vielleicht Gedanken machen, was man an Security berücksichtigen möchte in seiner Software. Es ist also eine ganz relativ komplexe Sache. Und nur sagen, ja, ich denke jetzt an die Overs Top-10-Risiken und dann ist alles gut. So einfach ist es nicht. Am Ende des Tages liegt es irgendwie an der Line of Code, wenn ich so ein Risiko in meiner Web-Anwendung oder in meinem System habe. Und dann, was oft zertabliert ist, z.B. Test-Triff-Nevelopment oder so, dann habe ich irgendwie, ich will eine Anwendung bauen, die hat eine Funktionalität. Und dann teste ich das Zeug vielleicht sogar auch, aber oft ist Testing beschränkt auf, ich gucke auf die Funktion, ich schaue auf die Technik und vielleicht schaue ich noch darauf, ob es schnell ist. Man könnte auch sagen, ich gucke, ob das, was ich da gebaut habe, anders performt. Und dann schaue ich, was muss ich machen, damit es das tut, was es eigentlich tun soll. Macht halt nicht ganz das, was soll. Wenn man jetzt aus einer Security-Sicht drauf schaut, ist es ja oft so, wenn jemand dann die Anwendung anders benutzt, als sie gedacht war, könnte man das auch so sehen, das ist ja immer ein so negatives Testing. Sie macht irgendwas, was sie nicht soll. Man könnte es aber auch so bezeichnen, die Overperformt, die macht halt mehr, als sie soll. Das finde ich ein ganz schönes Modell, auch so für den Kopf. Damit zu arbeiten, weil es meine andere Sichtweise ist, ist es auch schon ein bisschen älter, ist auch nicht meine Idee, es steht unten rechts. Aber finde ich ein sehr schönes Bild, wenn man da rangeht, auch so als Grundverständnis, wie man mit diesen Dingen vielleicht umgehen sollte. Genau, ja. Die meisten testen halt nicht auf Security und das ist dann von irgendwelchen anderen Leuten maschen und merken dann, wenn sie Glück haben, kriegen sie Post, wenn sie Pech haben, kriegen sie schlechte Presse und verlieren Daten. Deswegen ist es wichtig, das wir uns beschäftigen. Und das ist halt so, dieses Flagship-Projekt, das RC ist tatsächlich jetzt noch nicht ganz fertig, ist noch ein Release-Candidate. Das heißt, so ein paar Dinge verändern sich vielleicht noch, wir hatten ein paar Formulierungen. Genau, die letzte Version ist von 2013, die davor war von 2010. Was ist das jetzt für eine komische Reihe? Warum jetzt erst 17? Eigentlich sollte 2016, also der Plan ist alle drei Jahre, so ist ein Update von diesen Risiken geben. Das hat man nicht ganz geschafft, vielleicht auch deswegen, weil nicht genug Leute mit geholfen haben. Deswegen gibt es jetzt die neue Version erst dieses Jahr und nicht letztes Jahr. Genau, worauf basiert diese Risikoliste, diese Top 10? Also das sind jetzt auch nicht alle Risiken, es sind halt irgendwie die zehn Wichtigsten. Es gibt irgendwie immer so ein Aufruf, dass sich das Leute Daten schicken. Das ist hier auch im Detail beschrieben, auf den zwei Links, da kann man sich das anschauen. Unten ist die Mailing-Liste, da kann man auch mitmachen und eine Tache abgeben, wenn einem irgendwas nicht gefällt, wie das jetzt beschrieben ist. Und die Daten, auf denen die aktuelle Risikoliste basiert, die sind aus den Jahren 2014 und 2015 und dieses Dataset, aus dem das kommt, ist auch frei verfügbar, das sieht ungefähr so aus. Daraus haben dann irgendwelche Leute diese Risiken abgeleitet. Da sieht man, das sind irgendwie Daten aus der Praxis, also irgendwelche Scanner sind oft in Firmen die Geld mitverdienen, aber das ist die Grundlage dieser Risikoliste. Da laufen Scanner drüber und die finden irgendwelche Vulnerabilities und dann macht man sich Gedanken, was ist denn jetzt irgendwie der Schlimmste davon und das ist dann diese Risikoliste. Genau, schauen wir kurz drauf, wie sieht die jetzt aus in der Akte, dann wäre es so, wie konstant, auf Platz 1 immer noch, ist eigentlich traurig, aber das ist die Realität, also das sind praktisch verifizierte Daten, das ist jetzt nicht geraten, das ist Code, der durch solche Scanner läuft und Injection ist immer noch das größte Risikonanwendung. Aber gleich danach kommt, es ist anscheinend doch sehr schwierig, Authentication und Session Management so hinzubekommen, dass das tut, was es soll. Das lässt sich auch nicht immer so leicht testen, aber das ist das 2. Christo-Risiko. Dann haben wir immer noch Cross-Hide-Scripting, wird wahrscheinlich auch nie weggehen. Das 4., ich gehe nachher dann auch noch ein bisschen auf die Details ein. Das 4. ist Broad and Access Control, das ist jetzt auch ein 1. Change. In der Version 2013 hatte man das in 2 Risiken aufgesplittet, um auf ein paar Teilaspekte besser eingehen zu können oder die sichtbarer zu machen. Jetzt hat man es wieder zusammen gemirrt, sozusagen in ein Punkt, ist aber immer noch das 4. Christo-Risiko. Security Misconfiguration, Default Settings, auch Dauerthema, irgendwer lässt ein Backup irgendwo liegen, hat jetzt nicht direkt was mit Co2 zu tun, ist aber halt ein Risiko. Was je nachdem, was man da macht, ein Problem ist. Was ganz neu ist, das ist auch noch ein Punkt, der ein bisschen in Diskussion ist, der hat auch schon ein bisschen Aufmerksamkeit bekommen, weil einigen der Firmen, die mit an dieser Liste gearbeitet haben, dann unterstellt wurde, sie wollen damit nur ihre Produkte bewerben. Dann schauen wir nachher noch kurz drauf, was da drunter steckt. Dann Cross-Hide-Request-Folgerie steht auch immer noch drauf, obwohl es da inzwischen viele Möglichkeiten gibt, sich gut gegenzuschützen. Das ist ganz spannend, weil es gibt wahrscheinlich heute keine Anwendung mehr, die nicht aus vielen anderen Komponenten zusammengeschraubt ist. Frameworks benutzt, Code von anderen Leuten benutzt, sich automatisch updated, wer weiß, was da drin ist. Und da hängt auch drunter underprotected APIs. Wir haben viele Mobile-Anwendungen, die sind vielleicht die Anwendung an sich sicher, aber die reden mit irgendeiner Schnittstelle und die sind nicht sinnvoll abgesichert. Hier ist noch mal so ein grafischer Vergleich, im Prinzip sieht das sehr ähnlich aus zu der Version von 4.4 Jahren. Hier sieht man diesen Merge. Das Function Level Access Control und das Insecure Direct Object References wurden jetzt wieder zusammengezogen zu Access Control allgemein, weil man gesagt hat, man braucht das jetzt nicht mehr so ein Detailierungsgrad als Risiko aufzuführen, das hat sich ein bisschen verbessert und das reicht jetzt, das wieder allgemein asprocenexcess-Control darzustellen. Dafür ist dann der neue Punkt dazu gekommen. Eins ist rausgefallen, das Unteste, unvalidated redirects and forwards. Man sagt, das ist nicht mehr so ein großes Problem, das kann man rauswerfen. Dafür hat man die APIs aufgenommen, die sind doch deutlich kritischer. Ist noch ganz unten auf der Liste, aber vielleicht ist es in drei Jahren weiter oben, wenn das noch stärker ist. Weil wie gesagt, die Daten sind jetzt von 2015, das ist schon vielleicht zwei Jahre her. Was heißt jetzt Risikomodell eigentlich? Es gibt mögliche Angriffsvektoren, es gibt irgendwelche Leute, die wollen die Anwendung vielleicht anders benutzen, als es gedacht war. Ich schaue mal, was geht denn noch, außerdem was gepläumt war. Es gibt meistens Dinge, die nicht das tun, was sie sollen. Das ist ein Ereignis, kann in der Library sein, kann der eigene Code sein, kann eine Konfiguration sein. Dann gibt es Gegenmaßnahmen, die man ergreifen kann und dann gibt es Auswirkungen auf Entweder Daten, auf die Funktion, ich kann Dinge tun, die ich nicht so oder ich kann Daten lesen oder verändern, manipulieren, die ich nicht verändern soll. Und dann am Ende, dass das Modell gar nicht abbilden kann, das muss jeder für sich dann immer entscheiden, ist das was freier im Internet zugänglich, ist das nur intern und so weiter. Das ist dann eine Bewertung, die derjenige treffen muss, der die Anwendung betreibt oder gebaut hat. Wie funktioniert das jetzt? Denn gibt es halt für diese ganzen Punkte noch eine Berechnungsgrundlage, die die ganz genauen Details, wie das jetzt im Fall von Obers gemacht wird, aber das ist auch mehr oder weniger gängiges Modell. Also einmal ganz vorn links, das ist natürlich immer anwendungsabhängig, was man sich da anschauen muss, die Threads sind, wenn die Anwendung nur irgendwie Nachrichten darstellt oder ein Block ist, dann gibt es wahrscheinlich nicht so viele Möglichkeiten der Dinge zu mann Pylen bis auf den Content, aber der ist ja vielleicht dann das Wichtige. Und da muss man sich halt anschauen, was macht man da. Und dann gibt es halt die verschiedenen Angriffsvektoren, die kann man einordnen in Schwierigkeitsklassen. Ist es ganz einfach, das auszunutzen, dann sollte man was dagegen tun, dann steigt aber das Risiko, deswegen ist das hier rot. Und wenn das schwierig ist, dann schafft das auch nicht jeder, dann gibt es vielleicht auch keine automatischen Tools dafür, dann ist das Risiko, das ist halt eine Risikobetrachtung, dann niedriger, umso funktioniert das im Prinzip. Dann auch, wie verbreitet ist das und kann ich das auch leicht rausfinden, kann ich das Skender drüberlaufen und sagen, ah ja, hier, das ist kaputt. Dann ist natürlich das Risiko, dass das jemand ausnutzen kann, höher, als wenn das nicht einfach erkennbar ist, sondern man erst drei Schritte nacheinander machen muss und sich ein Mensch was überlegen muss und ich das mit den verfügbaren Tools nicht automatisch finden kann. Ja, dann hat es irgendwie eine Auswirkung, ich kann zum Beispiel die Datenbank löschen, wäre dann eher die rote Kategorie. Ich kann die Datenbank auslesen, ist dann vielleicht orange oder gelb, aber je nachdem was da drin steht, kann das auch ein riesiges Problem sein. Aber ich kann es vielleicht nicht verändern. Und dann in einem konkreten Beispiel könnte das halt so aussehen, dass man da entsprechend packt man Zahlen rein, aber sieht ganz von links und ganz hinten rechts, die Sparte ist halt leer, weil es muss man selber machen. Das kann einem auch keiner abnehmen. Also auch so ein CVE-Rating, das ist ja erst mal die Wunderability an sich, oder das Risiko, wenn ich die Komponente nicht benutze, das Risiko bei mir 0, auch wenn die vielleicht eine 10 hat. Das ist so zur Einordnung. So, nochmal der Überblick hier. Genau. Auf der Webseite gibt es eine sehr ausführliche Liste, die habe ich jetzt nicht benutzt, weil sonst wird es, glaube ich, ein bisschen anschränkt. Aber das hier mal das Beispiel, das sieht man jetzt auch wieder, da ist jetzt für jede dieser 10 Punkte einmal dieses Thread-Modell drin und eine Bewertung. Ich exerziere das mal an der A1 durch Injection. Auch wenn es vielleicht langweilig klingt, ist das noch das größte Problem, was wir haben. Also es ist natürlich wieder anwendungspezifisch. Ausnutzbarkeit ist in der Regel sehr einfach. Das heißt, es ist tatsächlich ein hohes Risiko. Es ist sehr verbreitet. Man kann es mehr oder weniger gut rausfinden durch Tools oder auch selbst, aber es ist nicht ganz trivial. Und die Auswirkung ist in der Regel maximal, weil man kann dann mindestens Daten auslesen, wenn nicht sogar manipulieren oder Server übernehmen und so weiter. Ja, und hier hinten ist halt wieder das, was man selber machen muss. Dann ist in der Detailbeschreibung immer drin, ja, wie entscheide ich denn, ob ich jetzt davon betroffen bin oder nicht. Da sind so ein paar Hinweise. Wie sieht das aus? Woran kann man das festmachen? Wie kann man damit umgehen? Und dann rechts steht, wie kann ich es verhindern? Weil das ist ja vielleicht der spannende Retail. Er sagt, ja, okay, jetzt halte ich das Problem. Was mache ich jetzt damit? Dann sind hier in der Regel ganz viele Links auf Subprojekte von OWASP. In dem Fall ist hier zum Beispiel Encoding, Injection kann man auch mit Encoding reduzieren. Und dann gibt es zum Beispiel Java, auch ein OWAS-Projekt, was ein Encoding Library bereitstät, weil das vom Framework, das ist schon schwierig, wenn man das alles selber machen will. Und man soll weitliessen müssen. Also hier stehen dann Tipps drin und auf der dritten Teil, ist dann auch nochmal beschrieben, wie sieht so ein Beispiel aus, wie funktioniert der Angriff, wenn ich das selber ausmühle, oder um das besser verstehen zu können, was passiert da eigentlich? Und auf der rechten Seite sind dann nochmal Referenzen zu OWAS-Projekten oder Extang-Quellen, wo man zum Beispiel die entsprechenden CBE-Sachen nachlesen kann, die in der Regel damit zusammenhängen. Das sind jetzt hier alles relativ alte, wie man sieht. Aber Injection ist ja nicht nur ein Zieg-Quell, also Relationalen Datenbanken, das ist aber nicht nur dort ein Problem, sondern es ist ein generelles Problem, aber das ist so das Bekannteste. Auch die meisten Non-Zieg-Wir-Systeme sind angreifbar mit Injection-Attacken. Da gab es auch einen schönen Vortrag, auf den 33C3 zu, da kann man sich anschauen, also nur weil man jetzt kein Zieg-Wir-basiertes System benutzt, hat man nicht automatisch das Problem nicht mehr, vielleicht hat man es gerade deshalb, weil man mit den neuen Technologien noch gar nicht daran gedacht hat oder noch nicht so viele Leute fiese Sachen ausprobiert haben und man dann darüber angreifbar ist und weiß es gar nicht. Was hier ganz oft erwähnt wird, sind die Sheets, habe ich ja auch am Anfang schon gesagt, weil da steht dann drin, was kann ich ganz konkret tun, wie programmiere ich das, wie benutze ich zum Beispiel in meiner Programmiersprache, wie mache ich das in meinem Framework, um eben genau nicht in das Problem reinzulaufen. Genau. Wie gesagt, die 2017-Edition ist jetzt noch nicht ganz fertig, das Material gibt es aber alles schon, muss man vielleicht mal schauen, in zwei, drei Monaten, es ist dann wahrscheinlich viel nahe. Genau, jetzt gehe ich mal alle 10 einmal kurz durch, aber nur auf einem neue Modus. Das erste hatten wir jetzt schon, aber wir sind halt auch noch mal andere Sachen angesprochen, das OS auch LDAP, also das ist nicht auf Sequel beschränkt, deswegen nicht denken, ich habe kein Sequel, das stört mich nicht, eins kann ich abhaken, mit Sicherheit nicht. Dann der zweite Punkt, Authentication, das fängt halt an mit Cookie Flex, macht meistens das Framework manchmal aber vielleicht auch nicht, dass ich die nur über HTTPS übertrage, Session Cookies oder halt auch nicht fürs JavaScript zugreifbar mache, der gibt es Flex für, damit muss man sich beschäftigen, das ist aber halt ein Problem, wenn man es nicht richtig macht, kann halt vielleicht jemand darauf zugreifen. Oft sind es irgendwelche Implementierungsprobleme, dann weiter unten, und das kann halt dazu führen, dass ein ex, ein nicht autorisierte Entität die Anwendung oder hat für bestimmte User Aktivitäten durchführen kann, die nicht vorgesehen sind. XSS ist eigentlich auch so ein Dauerbrenner, die meisten hier kennen das wahrscheinlich, aber es ist halt immer noch ein Problem, trotz der ganzen Frameworks und Hilfsmittel, die man hat. Wir haben dann über Security-Header gesprochen, da kann man ein bisschen was mitmachen, man muss seine Anwendung trotzdem sicher machen, weil A, weiß man nicht, ob die Dinge ankommen, und B, ob man sie richtig benutzt, so benutzt, wie es sinnvoll ist. Da gibt es auch einen schönen Vortrag von CSP in sich, dieser Header Content. Security-Policy, die funktioniert mit Widelists und so weiter, alles quasi perfekt, aber der Vortrag heißt Z, Long Lift CSP, weil in der Version 1.2 von diesem Header kann man diese Widelisten zwar benutzen, aber wenn man Angular benutzt, ist man trotzdem angreifbar zum Beispiel. Das ist nicht einfach, man muss da schon viel Energie und Zeit reinstecken, um sich mit diesen einzelnen Dingen und den Frameworks, die man benutzt zu beschäftigen, wie machen die bestimmte Dinge, was machen die automatisch, was nicht, was man noch als extra Punkt. Genau. Dann Broken Access Control von Bar Authentication, also erst mal, wie kann ich mich überhaupt anmelden, wenn ich eine nutzungsbeschränkte Anwendung habe und dann, wenn ich einmal authentiziert bin, also ich habe mich irgendwie als irgendeine ID dort angemeldet, dann haben die ja manchmal unterschiedliche Rechte in der Anwendung das Access Control. Da geht es dann darum, wer darf eigentlich was und wird es auch richtig umgesetzt. Man kennt das ja früher, man konnte dann einfach irgendwie eine ID ändern und hat die Daten von jemand anderem gesehen. Es ist heutzutage vielleicht nicht mehr ganz so verbreitet, aber dass man irgendwelche IDs durchiteriert und dann halt auch beim Zugriff auf die Daten nochmal prüft, ist denn das jetzt eigentlich der richtige Nutzer, wenn der auf Datensatz X zugreift, darf der den Sinn oder ist das eigentlich die Information von jemand ganz anderem? Die Bestellung von jemand anderem, ja nur weil ich die Bestell-ID weiß, sollte ich die vielleicht nicht sehen können. So als einfaches Beispiel dazu wird aber oft falsch gemacht oder halt gar nicht erst nochmal geprüft, weil der ist ja angemeldet und das ändert doch einfach keine diese ID. Das benutzt halt heutzutage keine ID mehr, sondern zum Beispiel ein Hash. Den kann ich da nicht mehr so gut raten. Integers kann ich halt einfach hoch oder runter zählen und wenn dann da keine Prüfung mehr ist, dann verliere ich Daten oder Nutzer können Daten sehen, die sie nicht sehen sollen. Das ist A4 und das begleitet uns quasi auch schon ziemlich lange. A5 da geht es jetzt ein bisschen aus der Anwendungsebene raus, aber natürlich nicht nur Konfiguration. Aber in dem Sinne Defaults, ja oft kommt ein Framework ich benutze das, denke mir das ist toll, die Leute haben sich da Gedanken gemacht, aber dann haben sie irgendein blödes Default Setting, was vielleicht nicht so praktisch in meinem Kontext ist. Muss man also immer anschauen ob die passen oder nicht und im Zweifel verändern und man muss das auch prüfen wenn ich ein Update mache, kommt vielleicht ein Default Settings, also überschreibt wie das Settings, die ich gesetzt habe. Das sind alles Dinge, die quasi in diese Misconfiguration Ecke fallen, weil weil man das, also deswegen habe ich das Maintained hier auch nochmal rot gemacht weil das ist wichtig. Ich ziehe mir alle möglichen Updates von einem JavaScript Framework das hat dann wieder noch 20 andere Komponenten, ich klick einmal auf Update wenn man das jetzt im Atom oder so macht, dann zieht er ja irgendwie 200 verschiedene Sourcen an, was weiß ich was ich danach auf meinem Rechner habe. Wenn ich das mit einer Anwendung mache, die irgendwie sensible Daten verarbeitet dann kann man das machen ist aber vielleicht nicht so eine gute Idee, einfach darauf zu vertrauen dass die anderen ihren Job richtig gemacht haben oder es ist halt auch einfach so ein Non-Profit Projekt sehr programmiert da einmal im Jahr dran und da verlasse ich mich dann drauf wenn ich die Komponente benutze deswegen kommt das unten auch mit den Komponenten nochmal, aber das spielt halt zusammen und die Konfiguration die da mitkommt oder die ich selber mache spielt dabei halt auch eine wesentliche Rolle Genau, dann A6 Sensitive Data Exposure Hier ist auch schon, hier taucht auch schon mal das Wort API auf kommt aber nachher nochmal extra und natürlich ist in bestimmten Bereichen sind die Nutzer oder die Programmierende das schon ein bisschen mehr gewohnt im Finanzen in der im medizinischen oder wenn einfach sensible Nutzerdaten aufgehoben werden aber die haben natürlich ein Wert für andere zum Beispiel ist es ja heutzutage ausreichend erst mal eine Liste von E-Mails und vielleicht noch mit Passwettern dazu zu bekommen wenn die nicht gut gehasht sind weil die meisten Nutzer da draußen ich sage mal hier im Raum ist es vielleicht anders aber der Großteil der Menschheit hat genau einen E-Mail Account ist meistens vorname.nachname et provider und den benutzen die in allen möglichen Anwängen das heißt ich muss nicht mal den seine Adresse oder irgendwelche superpersönlichen Daten haben aber es reicht ja schon ich habe immer eine Anwendung kann ich mich anmelden habe ich die E-Mail Adresse und ein Passwort von dem und dann ist es oft auch immer noch so dass die meisten Menschen genau ein Passwort haben und vor allem habe ich mit der E-Mail Liste schon mal eine valide Liste von Daten mit denen ich zu anderen Diensten gehen kann und mal gucken kann ob der da auch angemeldet ist funktioniert erstaunlich oft und inzwischen die letzten 2-3 Jahre sind diese Listen ja auch ein bisschen größer geworden hat man ja gleich mal 500 Millionen Einträge und so was und das Schöne ist, das sind validierte Daten, das sind echte Nutzer die kann ich einfach weiter verwenden aber deswegen ist es halt auch wichtig dass man die eigene Anwendung irgendwie sicher macht weil man kann davon ausgehen dass irgendwelche anderen Leute haben valide E-Mail Adressen die müssen die nicht mehr raten wird der Buch Adresse vorname.nachname sondern die können einfach die echten nehmen das ist natürlich eine große Datensets heutzutage und wenn man pechert haben die auch noch das Passwort und dann ziehen die hier Daten ab So, Insufficient Attack Protection das ist ein Neuer der ist auch noch ein bisschen in Diskussion kann man sagen, ja da will jemand seine Web Application Firewall verkaufen oder so mal so ganz abstrakt formuliert weil aber worum geht es hier Prinzipial geht es darum irgendwie in der Anwendung an bestimmten Stellen, wenn ich ein Formular hab auch zu erkennen ist da jetzt ein Robot drauf oder läuft an Angriff gegen oder auch an anderen Stellen dass ich merke, da passiert was was ich nicht wollte eine Option war auch gestern in dem Vortakt drin ist zum Beispiel über bestimmten dieser HTT-P-Header dies jetzt gibt das ist eine Routing-Uri mit Schicken und dann schickt der User-Agent an diese UI eine Information, wenn was komisches auf der Klein-Seite passiert das merke ich ja sonst auf der Server-Seite nicht das fällt zum Beispiel auch an diese A7 rein dass man solche Möglichkeiten nutzen kann um mitzubekommen, da passieren komische Dinge zum Beispiel auf der Klein-Seite die ich üblicherweise nicht mitbekomme und dann vielleicht gegen Maßnahmen einzugreifen oder eine Info an meinen Nutzer zu schicken hey guck mal, da machen Leute komische Sachen oder meine Anwendung zu analysieren, ob ich das anders bauen kann da geht es halt darum das A festzustellen, das war jetzt so ein bisschen der Detection-Part verhindern ja, sicheren Code schreiben aber das ist irgendwie nicht trivial aber man kann es sich zumindest vornehmen und zum Beispiel in die Requirements auch Security-Anforderungen reinschreiben macht ja leider kaum jemand erst mal nur an die Funktionalität und ansonsten nächst, das fällt so ein bisschen in die Prevention-Part und respond ist natürlich hat aber auch mal zwei Seiten, ich kann natürlich sagen, wenn sich jemand dreimal falsch angemeldet hat dann sperre ich den aus dann hat man wieder ein DDoS-Problem oder ein DDoS-Problem an der Stelle weil dann geht einer her, nimmt diese 500 Millionen E-Mail-Adressen geht man z.B. auf wem schießt ich denn heute mal die User weg da geht natürlich bewusst falsche Passwerte an wenn da so ein Protection-Mechanismus hinten dran hängt, der nach 3FA versuchen z.B. den Account sperrt dann sind plötzlich alle User gesperrt ist nicht mehr so invalid das Szenario weil diese Listen von E-Mails, die liegen ja da draußen im Internet rum und dann sind mal alle User ausgesperrt und dann hat man irgendwie Arbeit, muss sie alle wieder einsperren natürlich kann man diese Mechanismen auch anders machen z.B. das länger dauert, bis man die nächste Passwort eingeben kann und so weiter und so fort oder der Nutzer kriegt eine E-Mail aber das fällt da so ein bisschen rein dass man sich da einfach mal mehr Gedanken zu macht, weil das Problem wird eher größer als kleiner Cross-Site-Request-Forgery ist da gibt es halt auch Möglichkeiten und Mitte relativ sicher wenn es nicht ein Use-Case ist die Seite nicht woanders frame zu lassen und und entsprechend als zweiten Schritt dann auch immer IDs mitzuschicken also sogenannte Nances die pro Request auf zwei unterschiedlichen Kanälen nochmal eine zusätzlichen Wert mit schicken und dann kann ich das wenn der Request zurück kommt auf der anderen Seite wieder überprüfen und kann damit z.B. ausschließen dass jemand, wenn er weiß, wie meine Anwendung funktioniert als Noten-Source-Anwendung ist ist das vielleicht nicht so schwer man kann halt jemand dazu verleiten auf einen Link zu klicken obwohl er gar nicht in der Anwendung ist aber wenn ich das bei den genügend vielen Leuten mache und er es vielleicht doch angemeldet dann triggert er plötzlich eine Aktion auf der anderen Webseite, die er auch im Browser gleichzeitig offen hat die er aber nicht vorgesehen hatte dabei geht es so ein bisschen um CSF vereinfacht dargestellt dann haben wir noch A9 und A10 genau, habe ich vorhin schon mal gesagt using components with non vulnerabilities macht ja keiner so per default aber wenn ihr mal an die Anwendung denkt die ihr baut, könnt ihr einmal kurz im Kopf durchzählen wie viele libraries externe Sachen da so drin hängen und dann mal überlegen wann das letzte mal geschaut habt ob ihr auf der aktuellen Version seid welches bekannten Security Issues diese Komponenten haben ob das Ding überhaupt noch gepflegt wird und dabei geht es um diesen Punkt natürlich steht da extra known vulnerabilities weil die unbekannten, ja die kennt man halt nicht das hilft halt nichts aber die haben vielleicht auch noch andere vulnerabilities aber die kennt man halt immer erst wenn sie irgendwie sichtbar werden oder andere Variante weil man sie selber findet bei jemand anders das findet und veröffentlicht aber wie wir jeden Tag in der Presse lesen können gibt es halt auch Spiele die finden die und veröffentlichen die nicht damit sind sie unbekannt, werden aber ausgenutzt kann man erstmal nichts gegen tun aber wenn sie bekannt sind dann also man muss irgendwie Prozesse haben auch wenn es nur so ein Hobbyprojekt ist und sich vielleicht überlegen einmal im Monat, einmal alle halbe Jahre gucken die ganzen Sachen die man da drin benutzt leben die noch, sind die noch sicher muss ich die ändern wie ich das Ding sterben lassen weil mir der Aufwand nicht wert ist je nachdem was man damit für Dinge tut oder verarbeitet aber das ist halt ja kritische Sache dann A10, neu neben den Komponenten die man selber benutzt benutzt man vielleicht auch jede Menge APIs, eigene oder fremde bei den fremden kann man jetzt nicht so viel tun außer Bescheid sagen hey tut mal was das ist nicht gut was ihr da macht bei den eigenen kann man halt schon ein bisschen drauf achten wird halt naja, oft ein bisschen vergessen was irgendwie so eine technische Schnittstelle redet das Java Script mit, da kann ja nichts passieren aber am Ende des Tages ist das ja nicht so sondern API und hier unten stehen halt auch ganz viele technische Abkürzungen das sind nur Beispiele das ist halt nicht eingeschränkt auf die Technologien die hier unten stehen sondern es kann alles mögliche sein und dass man sich da auch Gedanken drum macht dass man da drauf schaut versteht wie funktioniert der Schutz ist da überhaupt ein Schutz liefer ich da sensible Daten drüber aus oder nicht und da gab es sehr viel Bewegung und man muss sich noch vor Augen führen das ist basiert auf Datensets von 2014 und 15 jetzt sind wir bei 2017 da sind diese beiden Punkte die jetzt noch ganz unten stehen wahrscheinlich tendenziell eher noch ein Stück nach oben gerutscht weil weil sich das Ökosystem da ja durchaus ein bisschen verändert hat aber das sind jetzt mal im Überflug die 10 Top-Risiken die von der OWAS alle 3 Jahre oder 4 dann aktualisiert und herausgegeben werden und hier halt nochmal so die Erinnerung werdet ja auch in den Dokumenten zu der Top-Tendisse finden also es ist schön die zu kennen die Risiken, es ist auch gut sich Gedanken dazu zu machen wenn man das richtig ernst nimmt oder wenn man kritische Systeme baut oder kritische Infrastruktur baut oder mit sehr sensiblen Daten arbeitet gehört da halt mehr dazu man muss das einmal aufschreiben dass man es beim Bauen schon berücksichtigt ja Anforderungen man muss seine Architektur anschauen was habe ich da für APIs wo schicke ich meine Daten rum sind die zwischen wenn hinten der Server noch mit 5 Backends redet ist da auch irgendwie Security drin das ist ungeschützt und wenn jemand ins Netzwerk kommt kriegt das dann vor free was habe ich für Standard-Controls drin ich muss mir irgendwie über den Lebenszyklus von den Gedanken machen ist besonders wenn es so stärker vernetzt ist funktioniert das alles und ich muss mich selber und die Leute die in dem Projekt sind auch Schulen nicht alle sind geborene Security-Experten und können das können das und akzeptieren es und verstehen es das ist also nicht einfach das ist so ein bisschen das was ich auch am Anfang gezeigt habe, dieses drumrum das ist wichtig das kann man auch nicht mehr klassen als funktioniert das ist wahrscheinlich nicht wirklich gut genau und dann ist halt auch viele werden ihre Funktionen super testen und bei Security wird die Luft wahrscheinlich schon dünner aber es ist trotzdem wichtiger Aspekt, es gibt da auch Hilfsmittel von der OWASP, das ASVS hatte ich auch ganz vorhin schon mit drauf stehen das ist jetzt genau man muss verstehen wie baut man seine Software ja den eigenen Software Development Lifecycle Prozess verstehen um dann auch zu schauen an welchen Stellen kann man sinnvolle Dinge tun in dem Kontext in dem sich das Projekt bewegt man braucht Strategien und wie wenn ich nur den linken Teil der Anwendung testen und den Rechner nicht hat zum Beispiel das Frontend aber die API halt nicht das reicht halt nicht dann ist halt die API angreifbar und dann ist man das Frontend egal als Angreifer dann gehe ich halt da lang direkt und genau hier unten ist so ein schöner Punkt Make Findings Reviews haben also das geht halt nicht darum sollte man versuchen das positiv zu sehen weil dann macht man die Daten ja am Ende oder für die Leute, für die die Anwendung ist und die Daten die da drin sind halt ein Stück sicherer so dass sie das auch ruhig in Gewissens benutzen können das ist halt wichtig dass man so versucht eine Kultur im Projekt zu entwickeln das ernst zu nehmen und halt auch nicht da ist ein Fehler gemacht oder das ist blöd das kann man halt auch anders formulieren aber das ist halt extrem wichtig sich auch um diese nicht technischen Dinge drum herum Gedanken zu machen und vor allem da auch mal drauf zu schauen sonst funktioniert das sowieso nicht mit der Security genau das war's gibt's noch Fragen ja hier vorne ich kann die Frage auch wiederholen was ist denn deine Involvierung in OWASP meine Involvierung in OWASP einmal ich stehe hier und erzähl was zum Beispiel auch eine Form von Involvierung der zweite Punkt ist ich bin auch immer mal auf diesem Stammtisch und tausche mich mit anderen Menschen aus also ach ja die Frage war was meine Involvierung mit OWASP tausche mich mit denen aus und helfe vielleicht auch bei dem ein oder anderen Projekt mal mit oder was da ist noch ein Fehler im Slide oder so oder korrigier das aber primär ist es jetzt so ich bin auch mehr Nutzer als Contributor aber in dem Sinne ich halt halt 2 Vorträge zu so 2 Projekten das ist im Prinzip auch ein Teil wo ich aktiv mitmachen sonst nutze ich ganz viel davon gibt's noch eine Frage ja da hinten eine Überlegung dazu ob man künftig auch noch verschiedene Angreifertüben unterscheiden möchte also sozusagen ein Angriff von Innen ein Angriff von Außen ein Angriff von einem Nerd und ein Angriff von einem State-Level-Actor der irgendwie mit ein paar Millionen Euro drauf losjagt ja das ist so ein bisschen ja diese Risiko-Geschichte da sind ja auch also hier ist ja einmal die Methodologie da ist es quasi ein Mindestprojekt das ist da ja schon so ein bisschen mit abgebildet ja also einmal Detectable Easy Average Difficult ist dann vielleicht der State oder den Nationwide Angreifer der also der Thread Agent war da halt mehr mit der Dinge zu finden da findet halt auch die schwierigen Sachen aber dann muss ich mir halt Gedanken machen ja will ich mich jetzt gegen Geheimdienste schützen oder nicht kann ich überhaupt den Aufwand ins Projekt stecken oder nicht und dann muss man das entsprechend halt bewerten insofern so ein bisschen ist das schon drin und das für Thread Modeling gibt es auch weiß ich gar nicht ob es ein Oversprojekt für gibt ich glaube schon da gibt es ja auch Prinzipien das ist halt total Projektanwendungsabhängig auch wo man die Grenzen zieht man was nicht das nennt man Thread Modeling da gibt es auch ganz viel Literatur zu da könntest du reinschauen wenn du nicht das interessiert wie macht man das wie geht man da systematisch ran an das Thema da gibt es auch hier wie dieses Risikomodell gibt es auch Thread Modelle wo man genau diese Bewertung macht und dann sagt ja ok ich hab hier den Nutzer der mätschende Anwendung an hat auch ein Account in dem Data Backend oder ich hab da nur irgendwo ein Key mit dem ich mich dann auf irgendeine API zugreife je nachdem ja also das fällt dann in die Kategorie Thread Modeling da gibt es aber Dinge zu die sind jetzt aber nicht Teil dieses Risikmodells also nicht über das hinausgehend was ich jetzt hier gezeigt habe aber da ist das quasi so ein bisschen mit abgebildet die letzte Box da kann man seine eigene Bewertung reinpacken was hat das für mich schon Impact was bedeutet das für mich wie bewertig das selber weil das kann ein generisches Modell nicht abbilden gibt es noch eine Frage gut dann vielen Dank