 Gut, dann fangen wir an. Heute gibt's Overs Top 10 Pro-Active Controls, der das noch nicht kennt, den stell ich jetzt vor. Die Overs Top 10 kennen wahrscheinlich viele, die hier sitzen. Wer kennt die, die hier im Raum sind. Wer kennt die Pro-Active Controls? Dann wird's hoffentlich ganz langmällig. Wer ist Pentester? Okay, die langmellen sich vielleicht ein bisschen. Vielleicht kommen ein, zwei neue Sachen. Mal gucken. Genau, das Slide Deck ist vom Jim Manico, hat das, glaube ich, gebaut. Ich benutze das heute. Also ich habe nicht zu allen Bildern coole Sprüche. Der Match hat mir mal seinen Vorteil angeguckt. Aber die meisten Sachen kann ich auch selber erzählen. Und dann fangen wir einfach mal an. Am Anfang ist immer kurz, was ist eigentlich Overs? Das ist die kurze Person von gestern. Also es ist auch eine gemeinnützige Organisation und die versuchen, IT-Sicherheit im Web-Umfeld oder im Internet präsent zu machen, muss man immer noch so sagen und zu halten und auch entsprechende Hilfsmittel dafür bereitzustellen und alles ist halt freizugänglich. Genau, das ist die Overs. Das ist ein Projekt, das gibt's schon ein bisschen länger. Das gibt's auch schon in der Version V2. Genau, und das bezieht sich auf diese Top 10 Liste. Aber verfolgt den Ansatz, weil das ist ja so ein bisschen, was hat man so für Risiken, worauf sollte man achten? Und am Ende des Tages hat man ja immer irgendwo die Zeile Code, die für das Problem, was in dieser Top 10 Liste abgebildet ist, dann verantwortlich ist. Und bei diesen Proactive Controls geht's darum, die Entwickler zu sensibilisieren und auch Beispiele zu geben und auch Hinweise. Ich habe gestern auch über diese Sheets-Sheets gesprochen. Hier kommen ganz viele Referenzen auf diese Sheets-Sheets, wo man sich das dann im Detail angucken kann für die jeweilige Programmiersprach. Und das ist quasi so die Zusammenfassung davon. Und das ist jetzt gewachsen. Es gab auch viel Input von außen dazu. Der ist jetzt hier mit eingeflossen. Am Anfang war das mal ein bisschen komprimiert. Anzwischen sind das 90 Slides. Also gibt es eine ganze Menge Sachen. Und natürlich Mobile, habe ich gestern auch schon mal kurz erwähnt, ist sowas, wo wir wieder von vorne anfangen, obwohl wir eigentlich alles schon besser wissen. Wir machen die gleichen Fehler wieder. Genau, das ist die Top 10 Liste. Und zu den einzelnen, oder ich werde jetzt dann im Laufe des Vortrags diese Controls vorstellen. Also was kann man eigentlich im Code machen, um genau diese Top 10 Geschichten gar nicht erst aufdrehen zu lassen oder zu mitigieren. Und das ist so aufgebaut, dass ich jetzt immer erst das Kontrollvorstelle und hinterher sieht man kurz, auf welche dieser 10 Punkte bezieht sich das dann eigentlich. Das erste Kontroll heißt auch, wie der erste Punkt, Verify Security Early and Often. Also es muss einen Teil sicheren Quotes schreiben oder Plant-Tests durchführen. Es ist ganz schön, aber das ist nur ein Bruchteil von dem, was man eigentlich tun muss. Also man sollte das in seine Prozesse integrieren. Man sollte, naja, also ja, Code ist die eine Sache, testen ist die andere Sache, aber man braucht auch organisatorische Maßnahmen und muss das in die Prozesse integrieren und an den richtigen Stellen und frühzeitig und nicht nur einmal. Das übliche mit der Qualitätskontrolle, die kann ich am Ende machen, ist aber vielleicht nicht so sinnvoll. Genau. Also man muss das wirklich integrieren. Es muss ein Teil des Prozesses werden oder sein. Und man braucht auch die Tools und die, sichere Requirements, die sich darauf beziehen. Ja, Entwickler bauen Requirements. Wenn ich keine Security Requirements aufgeschrieben habe, denken die da auch nicht dran. Natürlich muss ja auch noch Schulen, aber das sind halt also auch wirklich es als Requirements definieren, weil das ist das, was die Leute coden. Und wenn es da nicht drinsteht, dann kann man viel erzählen und dann gibt es da Sheets, Sheets und sowas. Aber wenn der Requirement steht, dass es soll blinken und der Rest ist egal, dann blinkt es wahrscheinlich, aber macht vielleicht auch noch andere Sachen. Was auch ein wichtiger Aspekt ist in diesem ganzen Prozess, Deaf Ops haben wahrscheinlich die meisten ja auch schon mal gehört. Hier sind so ein paar Beispiele. Also einmal am Tag deployen ist schön, manche machen das noch ein bisschen öfter und dann brauche ich da vollautomatisierte Prozesse und die müssen natürlich auch irgendwelche Security Checks beinhalten und so ein Security Check kann halt auch dazu führen, dass so ein Deployment abgebrochen wird. Ist hier ganz unten auf der Folie. Also Automatisierung ist key, aber man muss es halt, wenn man solche Deaf Ops Geschichten hochfährt oder sehr oft Code ändert in großen Umgebungen oder auch in kleinen, groß ist eigentlich egal, das sind solche Beispiele von relativ großen Systemen, aber bezieht sich natürlich auch auf andere. Also es ist wichtig, hier steht es jetzt nochmal, Automated Security Testing muss ein integraler Bestandteil werden, sonst kann ich mir das auch sparen oder habe halt dann die üblichen Probleme, wenn ich das erst später mache. Es gibt auch gewisse Frameworks inzwischen dafür. Das ist jetzt aus der Java Ecke, hier sind auch noch ein paar andere Tools auch von Overs mit aufgeführt, weil der Jimanico, der ist halt so ein Java Minch, der hat auch eine API mitgeschrieben, das kommt auch später nochmal und dass man auch weggeht von, jeder Entwickler muss das immer überall auf der Code-Ebene komplett alles verstehen, wissen, kennen und tun, sondern dass man Frameworks benutzt zum Testen oder auch zum Definieren von Requirements und das ist ein Beispiel dafür. Genau und dann gibt es halt noch weitere Tools, die einige sicherlich kennen hier im Raum. Hier ist jetzt mal so ein Beispiel, wie so eine Definition von einem Test aussehen kann. Es ist jetzt auch so eine deklarative Beschreibung, wie man damit hinterher einen automatisierten Test laufen kann, der dann bestimmte Sachen checkt, aber es ist halt nicht nur als Code hinterlegt, sondern man kann es nachvollziehen, wenn man es liest. Genau und hier ist jetzt auch noch mal ein Beispiel, wie man das mit Annotations in diesem Framework machen kann. Was ist jetzt hier adressiert, ja im Prinzip alles, weil es geht ja um den Prozess und wenn ich den vernünftig aufsetze und entsprechend die Tools, die Leutenschule und so weiter, dann deck ich im Prinzip alle diese Top 10 Findings oder Risiken, die man üblicherweise hat. Es gibt natürlich noch mehr, weil das sind halt die Klassiker und die die kritischen sozusagen oder die mit dem höchsten Risiko deck ich damit ab. So jetzt kommen wir zu einem Klassiker, Sequel Injection. Ja, wir haben 2016 und müssen immer noch darüber reden. Eigentlich tragisch. Hier gibt es dann immer so lustige Comics. Hier gibt es auch eine anderen Variante. Did you really name your son, baby, boobie, table, das hilft eine andere Variante davon. Genau, das ist so die klassische Variante oder jemand hat halt es auf die Idee gekommen sein Passwort so zu nennen. Geht, ja deckt alle alle Anforderungen ab. Großbuchstaben, Kleinbuchstaben, es ist eine Zahl drin, ein Special Character drin und es sind mehr als 16 Zeichen. Ich weiß es mit 10. Also wenn man das dann jetzt in eine Query packt, kann das dann lustige Seiteneffekte haben. Ist auch beim Testen hat ein Problem, was ist ein sicherer String, um eine Sequel Injection zu testen? Den gibt es quasi nicht. Da kommt glaube ich später noch ein schönes Beispiel. Genau, weil das ist ja auch eine Update Query und wenn man dann da die Werbedingungen quasi durch die Sequel Injection wegoptimiert, dann updated es halt alle Datensätze oder löscht nachdem was die Query gerade macht. Genau und was ist eigentlich die Lösung dafür? Die ist so alt wie Sequel eigentlich, parametrisierte Queries. Das heißt der PASA passt erst die Query, baut schon den Abfragebau, macht die alle Optimierung und hinterher fügt man erst die Datensätze ein, die tatsächlich abgefragt werden. Es geht in allen Programmiersprachen, aber es benutzen nicht alle. Aber das kann man halt dann vielleicht auch über Requirements, Coding Guidelines und so weiter abdecken, dass das halt ein Forst ist und das kann man hinterher auch checken, ob es eingehalten wird, auch automatisiert. Und das ist total trivial, macht parametrisierte Queries und alles ist gut, dann kann nichts mehr passieren. An der Stelle kann man das dann sogar so sagen. Ansonsten ist sowieso das Datenbank-Management-System im Eimer. Da muss man sich darum keine Sonne machen, wenn der PASA also das nicht sauber getrennt kriegt. Genau. So ja Injection Risiko ist auch immer noch das ist immer noch die Top 1 Risiko ist, dass irgendwer muss immer nur die Zeitung aufschauen, man hat ja fast jeden Tag wieder irgendwo, wurde wieder irgendeine Datenbank, hat Informationen verloren, üblicherweise passiert es über Sequel Injection. Geht auch mit NoSQL Datenbanken, also ich sage Ha, ich mache ja kein Sequel mehr, ich mache nur noch NoSQL, da hat man das gleiche Problem, aber auch da gibt es eine äh äh äh äh äh äh äh ähnliche Optionen, um um genau dieses Problem zu umgehen, also das muss nicht sein. Genau ähm ähm ja Pasing, äh ähm äh äh ähm äh äh äh äh äh äh äh Äh äh äh äh äh Sanitisen, auch hier sieht, bevor, also bevor man es passt, soll man es entkroden, um nicht erstpasen und dann entkroden, weil was macht der Browser, wenn er sowas sieht? Danach ist das für ihn kein Text mehr, sondern Mark ab, wenn er dieses Zeichen findet. Deswegen schreibt man das. Also man entkrodet das, bevor man es den Pasa gibt. Der Browser ist ja letztendlich auch ein Pasa. Alles, was der nicht als Code interpretieren soll, sollte man ihm auch so schicken, dass es nicht tut. Genau. Das betrifft dann üblicherweise XSS-Angriffe, auch gerne die, genau, hier ist ja ein Skript. Ich weiß gar nicht, was das Beispiel jetzt genau machte. Genau, der schreibt einfach den Cookie direkt in den Quellcode. Das ist auch was gern übersehen ist. Ja, ich hatte das jetzt auch bei unseren Entwicklern. Die Seite hat doch gar kein User-Input. Kann man so sehen, muss man aber nicht. Es gibt halt auch unsichtbare Eingabefelder wie Cookies, die vom Kleint wieder zurückgeschickt werden. Und was das Ding hier macht, der destiert quasi dann im Zweifel halt die Session vom Atmen und schickt sie als B zurück. An den Angreifer. Und wenn man das sauberen Code und passiert es nicht, sagen wir hier, Webpage. Ja, das ist das Standardproblem. Da gibt es dann, da habe ich morgen auch noch einen Vortrag zu. Es kommt auch später noch mal. Es gibt inzwischen auch ein paar Hedder, die man mitschicken kann, die diese Probleme ein bisschen reduzieren, wenn man viel Code hat, den man nicht zeitnah aufgeräubt bekommt, was ja oft der Fall ist. In existierenden Anwendungen kann man nicht einfach alles neuschreiben. Genau. Und hier gibt es verschiedene, auch wieder, je nachdem, welche Programmiersprache ihr benutzt. Das sind jetzt auch nur Beispiele. Das heißt jetzt nicht, dass es das für Palten nicht gibt. Das ist jetzt hier nur nicht aufgelistet. Es gibt inzwischen fast für die Hauptprogrammiersprachen, die in Nutzung sind. Von Irgendwas mal so gibt es entsprechende Tools oder Bibliotheken, die man benutzen kann. Das ist auch generell eine Empfehlung, versucht es nicht selber zu machen, weil Encoding ist und auch Decoding ist nicht trivial. Es ist besser, sich auf was zu verlassen, auch wenn das natürlich wieder ein Risiko hat, wenn die dann Fehler machen, muss man das irgendwie wieder updaten und so weiter. Die übliche Abhängigkeitskette, die hinten dran hängt, aber trotzdem ist es sinnvoll, existierende Tools, Frameworks zu benutzen, die genau das machen und das wirklich schon lange machen, wo viel Know-how reingeflossen ist. Genau. Hier ist jetzt noch die Microsoft-Library, die ist halt Anti-XSS. Es gibt es auch auf GitHub. Es ist inzwischen alles Open Source bei Microsoft oder hier, was die ganzen Dot-Netz-Base angeht. Und hier gibt es verschiedene Namespaces, die dann auch verschiedene Encodings, weil Encodings sind ja auch immer kontextabhängig. Bin ich jetzt im XML-Kontext, bin ich im HTML, bin ich im JavaScript, im JSON, in meinem Code. Man muss also auf extrem viele, man muss den Kontext kennen und so weiter. Das macht Go zum Beispiel, das kommt später erst, auch ganz clever. Die haben eine Template-Engine, die den Kontext automatisch berücksichtigt und das richtige Encoding macht. Genau. Aber das ist jetzt eine Library, die funktioniert natürlich nur mit Dot-Netz. Aber wenn man in diesem Umfeld unterwegs ist, ist das Tool der Wahl. Dann gibt es für die Java-Welt ein eigenes Obersprojekt, in dem Fall, dass ich auch um diese Sachen kümmere. Das hat keine weiteren Abhängigkeiten, aber man hat dann diese Abhängigkeit und man kann das einfach benutzen. Es ist einfach benutzbar und das ist was, was man Entwicklern an die Hand geben kann. Und dann sieht die Welt schon ein bisschen besser aus. Das heißt nicht, dass dann keine Fehler mehr passieren. Aber es ist nicht mehr ganz schlimm. Genau. Hier sind auch noch mal diese unterschiedlichen Kontexte dargestellt. Also allein da schon man sagen muss, oh okay, URL muss ich wieder anders encroden als XML und so weiter. Also das hat alles eine beliebig hohe oder tiefe Komplexität. Aber da gehe ich heute gar nicht im Detail drauf ein. Aber ihr seht und weiß nicht, ob es jeder im Raum sich dieser Kontext überhaupt bewusst ist oder war, bis jetzt einmal so oft geschrieben an der Wand stehen und dass ich da ein anderes Encoding benutzen muss im Zweifel und nicht einfach, ich habe eine Encoding Funktion. So trivial ist die Welt leider nicht da draußen. Man kann da also mehr falsch als richtig machen. Wie gerade schon gesagt, hier gibt es eine ganze Menge Ressource, wo man da eine Tiefe gibt. Für Ruby gibt es das auch, für PIP, Java, Scala, .NET, Go, Reform. Also es gibt eine ganze Menge an Material, wo man sich dann da weiter in die Tiefe vorarbeiten kann, je nachdem in welcher in welcher Ecke man da unterwegs ist. So, LAP gibt es auch noch. Das viele kann man auch Encoding benutzen. In dem Fall ist sie, habe ich schon erwähnt, die ES API, also Enterprise Security API ist auch ein Oversprojekt und halt wieder die Anti-XSS Library hat auch Encoding Funktionen für LAP Zugriffe. Und man muss dann halt auch wieder aufpassen, auch so ein Encoder und so weiter. Also wie ihr seht, diese Komplexität kann man wirklich weitreiben. Und hier unten in den Folien, die sind auch öffentlich zugänglich, die sind auf der Obersseite vom App Security Forward, da findet ihr dann auch die ganzen Links. Was deckt man damit jetzt ab, wenn man encoded oder sinnvoll an der richtigen Stelle encoded, kann man Injection Probleme vermeiden und halt auch Crosshiteskripting Angriffe reduzieren. Validate all inputs, auch so ein Klassiker. Ich habe das doch schon im JavaScript validiert. Gute Idee, aber du musst es auf der Serverseite nochmal machen, weil die nicht so netten Leute, die schicken halt einfach was anderes zurück, was vielleicht nicht validiert wurde. Und außerdem kann man JavaScript auch ausschalten, wie ihr seht. Generell, also alles, was auf der Kleinstseite vielleicht gemacht wird, also deswegen Validate all input und es gibt kein Exception. Auch wenn es aus der Datenbank kommt, will ich es vielleicht nochmal validieren oder encoden, bevor ich es auf die Seite schreibe. Da kommt ja aus meiner Datenbank, aber wer hat es da reingeschrieben? Weiß man nicht so genau. Außer man weiß es wirklich. Also das ist natürlich eine Option, wenn ich für einen Entwicklungsprozessor, wo ich weiß, dass die Daten, dass ich die da selber über meine Konfig reingeschrieben habe, ist das natürlich, kann ich sagen, ja okay, an der Stelle kann ich es aber nur selber da reinschreiben, aber das muss ich auch erst mal wissen und tracken und dokumentieren. Genau. Manchmal ist es aber auch so, dass man HTML Fragmente vom User haben will oder muss. Das ist natürlich blöd, aber auch dafür gibt es inzwischen Libraries, die mit Positivwissen kommen auch gleich ein paar Beispiele. Hier sehen wir wieder, es ist ein Java Overs Projekt, was so eine Funktionalität zur Verfügung stellt, wo man sagen kann, ja, aber die und die hat dem L-Text mit den Attributen und in dem Attribut darf dann eine Zahl stehen, sind erlaubt. Also hier kann ich das auch wieder so deklarativ beschreiben, was darf mir der User denn schicken und dieser Code versucht dann sicherzustellen, dass da auch nur das drinsteht. Wie gesagt, das ist nicht trivial, das hat vielleicht auch bugs, aber es ist besser, als wenn man es selber macht. Wenn man in der Situation ist, dass man halt das tun muss und diese Situation existieren, man kann sagen, ja, ich nehme kein HTML-Input vom User, aber die Realität sagt, du musst das jetzt aber machen und das ist ein Teil der Lösung davon. Genau. Und das gibt es auch noch in anderen Sprachen, die .NET selbst kann das, aber auch die XSS-Library hat das wieder Ruby, PHP, Python, JavaScript gibt es auch Frameworks für, also lieber benutzen, was da ist, sich dort unterstützen und die entsprechende Bibliothek mit weiterentwickeln, Ressourcen zur Verfügung stellen und nicht selber machen und vor allem überhaupt machen, wenn man es muss. File upload, auch ein beliebtes Thema, wie fahre ich oder wie stelle ich es sicher, dass das Fall, dass sich der Krieg halt nicht mehr als ein JPEG ist, gibt es so eine klassische Liste, aber viele Entwickler kennen die auch nicht zwingt. Was man alles machen kann, das fängt halt mit den Basics an, Feinnahme, Größe, man lässt man Scanner drüber laufen, den Scanner lässt man dann vielleicht auch, wenn man die Dinger dann irgendwo in den Storage hat, auch jede Woche mal drüber laufen, auch wenn die nicht alles finden, aber der fittert schon mal eine ganze Menge Müll weg, man kann das einschränken, man muss aber dran denken, okay, ich will kein XM11, aber an einigen Stellen haben die eine Funktion, damit das ganze Ökosystem funktioniert, da muss man drauf achten, wie kann man jetzt zum Beispiel mit Bildern umgehen, da ist auch eine sehr beliebte Variante, einfach das Bild neu encoden, also auch wieder encoding als Security-Maßnahme, genau, weil dann speichert es halt nochmal als JPEG, aber dann ist nur noch das JPEG drin und der Rest ist raus, ist aber natürlich auch dieser Recoder, die Rewriting-Librerie, die kann natürlich auch wieder angreifbar sein oder Backs enthalten, da gibt es keine, man kommt da nicht raus ohne Schmerzen, weil das macht ja, kostet ja auch alles Ressourcen und Zeit, aber so ist die Realität im Moment, außer man ist happy und hat keine Fireblocksfunktion, aber dann kommt wieder die Realität und sagt der User welche, aber sein bisschen hochladen, genau, sind wir wieder bei den zwei gleichen Risiken, die damit abgedeckt werden, kommen wir zu was anderen, Authentication und Identity Controls, Lock-in, Userrechte kann doch jeder, ist leider auch nicht so trivial, kann man auch viel falsch machen. Letzte Woche ist ja dann auch die LinkedIn-Datenbank von 2012 veröffentlicht worden und die hat SHA-1-Passwörter ohne Salz, kommen wir gleich noch drauf und ich glaube, die sind inzwischen alle in Schüssel, es waren 156 Millionen, wer seinen LinkedIn-Passwort immer noch nicht geändert hat, der sollte langsam darüber nachdenken, ist zu tun, inzwischen haben die alle, genau das sind ja auch noch mal Beispiele, wie zum einen gibt es Hardware, zum anderen Rainbow Tables und so weiter, also rein irgendein Hash, um ein Passwort zu schützen, in Anführungszeichen ist eine blöde Idee heutzutage und selbst SHA-1 ist, also das bietet nicht mehr unbedingt das, sollte man nicht machen, deswegen gibt es ein paar Best Practices, wie man mit Passwörtern umgehen sollte und einmal man sollte die nicht einschränken, soweit es geht, natürlich sollte man sie auch nicht umbegrenzt groß machen, dann hat man vielleicht wieder selber ein Problem, wenn da jemand unendlich lange Passwörter in das System schicken kann, ist vielleicht auch nicht so besonders lustig, aber auch hier muss man vorher wieder, dass auch Passwörter encoden, bevor man sie pass und so weiter und so fort, damit man auch bestimmte Risiken an der Ecke vermeidet, weil darüber kann man auch Systeme angreifen. Genau, wie macht man das jetzt mit der Kryptografie richtig, am besten nimmt man auch wieder irgendwelche Bibliotheken, denen man vertraut. Ansonsten ist das, das Salzen ist Pflicht, warum macht man das? Es ist quasi eine De-Dapplication, das heißt, wenn zwei Leute das gleiche Passwort verwenden, kriegen sie auf jeden Fall einen anderen Hash in der Datenbank und wenn ich das nicht mache, dann bin ich halt viel schneller, also es ist halt, um es dem Angreifer schwerer zu machen. Da macht man auch nicht nur so ein paar Bit, sondern so richtig ordentlich, weil wenn der User so ein Trivial und so weiter hat, genau, und dieser Sort, der kann auch öffentlich sein, weil der ist wirklich nur dafür da, dass ich nicht für das gleiche Passwort dann dasselbe den selben String quasi in der Datenbank stehen habe. Genau, wir haben ja schon gelernt, wir nehmen keine Hash, sondern es gibt bestimmte Funktionen, die benutzen intern manchmal auch solche Dinge, aber die sind rundenbasiert, warum macht man das? Weil dann muss ich mehr rechnen und wenn ich ein Passwort verschlüssele von dem User, der sich gerade anmeldet oder beziehungsweise durch diesen Algorithmus laufen lasse und dann mein Ergebnis bekommen und das mit dem Wert in der Datenbeigleiche, dann ist das okay, wenn jetzt ein Angreifer versucht, falls er an die Datenbank angekommen ist, die alle zu entschütteln braucht er halt extrem lange, weil er das jedes Mal machen muss. Wir sind auch so ein paar, der Jimanicus auch so aus der OS Ecke, deswegen ist jetzt hier der FIPS-Standard erwähnt, da ist jetzt in Europa natürlich nicht so relevant, aber wenn man diese Anforderungen hat, bestimmten Regierungsanforderungen zu entsprechen, dann benutzt man das, ansonsten gibt es auch noch weiter Algorithmen wie S-Crypt und B-Crypt, die sind ein bisschen schneller. Genau, wenn man jetzt in der Situation ist, dass man sehr viele User-Zugriffe hat, sowas wie Facebook oder andere große Netzwerke, die die pro Sekunde viele tausend Passwörter abgleichen müssen, dann gibt es auch noch andere Möglichkeiten, um einfach schneller zu werden, aber ohne diese rundenbasierte Sicherheit. Der Vorteil von dem rundenbasierten Variante hier ist auch noch, ich kann das hoch setzen, wenn die Angriffe besser werden, dann mache ich halt ein paar Runden mehr, ihr seht, da ist auch eine ziemlich große Teilhundertvierzichttausend und inzwischen, das ist jetzt hier nur so ein Beispiel, aber für jemanden schon 500.000 Runden oder so, aber man kann das halt beliebig verlängern sozusagen und macht es dann dem Angreifer schwerer und hier ist halt auch noch mal, da kann man noch ein Private Key reinlegen und Edge Mac benutzen, also man kann da auch wieder sehr, sehr viele Dinge tun. Hier haben wir noch so ein perfektes Passwort, erfüllt alle fünf Kriterien, ist aber kein gutes Passwort, deswegen außer solchen Vorgaben, die kann man positiv und negativ sehen, ob die sinnvoll sind, dann lieber länger, keine Ahnung, aber was hier die Idee ist, dass man halt durchaus auch Wörterbücher benutzt und bestimmte Worte verbietet, wenn der User die benutzt sagt, das geht aber nicht und dann da die Risiken etwas minimiert. So, was machen wir, wenn wir das Passwort vergessen haben? Wir sind ja nicht nur bei der Authentication hier, da kann man auch auf bestimmte Aspekte achten oder die halt gar nicht erst dran denken, also es gibt ja diese berühmten Fragen, ich habe mein Passwort vergessen und jetzt, also mindestens zwei Fragen, was man dann nimmt, hängt sicherlich auch von der Umgebung ab, in der man sich bewegt. Hier gibt es auch wieder ein Cheat-Cheat dafür, wo man sich Input holen kann, was vielleicht sinnvoller Security-Questions sind, weil das ist auch nicht trivial, da die meisten User da ja die echten Antworten reinschreiben, also sollte man nicht, die dann aber auch wieder leicht auffindbar sind heutzutage in vielen Fällen. Genau, Out of Band, ja, hat sein Passwort vergessen, ich schicke ihm eine E-Mail, ob das noch sein E-Mail-Account, das weiß ich nicht, deswegen geht man, er kennt das sicherlich auch in vielen Anwendungen hat man sagen, hinterlegt man noch eine Handynummer, dann kann man eine SMS bekommen. Aber auch das kann man natürlich irgendwie angreifen, aber es macht die Sache schon mal komplexer für den Angreifer, das heißt nicht, dass es dann sicher, dass es dann total sicher ist, aber es macht es schwerer für die Leute, die da nicht ran sollen. Genau, ich sehe auch noch Lockout-Policy, wenn immer irgendwas Komisches passiert, lockt die Leute aus, weil die normalen User machen kein Scheiß mit der Session und wenn irgendein Scheiß passiert, dann ist Ende Session, dann kann er sich wieder neu anmelden. Es ist relativ trivial, machen aber auch nicht viele, die versuchen immer, das noch am Leben zu erhalten, User-Convenience, aber es ist vielleicht der falsche Ansatz, weil der normale User, der macht das System in der Regel nicht kaputt, es macht nur der Angreifer. Genau, und wann, hier sind jetzt noch Beispiele, wann mache ich eine Re-Ausentication? Oft kommen ja neue E-Mail-Adresse, dann gebe ich halt die neue E-Mail-Adresse eigentlich auf Safe, super. Wenn es noch meine Session ist, wenn die Session gerade jemand anderen gehört, ist es doof, weil dann kann er auch hinterher den Passwort-Reset-Clicken und dann kommt die E-Mail halt nicht mehr bei mir, sondern bei dem anderen, weil es ihm sehr einfach gemacht wurde, dieses Datum zu ändern. Deswegen ist es wichtig, wenn man kritische Daten, was auch immer das im jeweiligen Kontext der Anwendung bedeutet, ändert, es ist eine gute Idee darüber nachzudenken, eine Re-Ausentication vorzunehmen. Das heißt, dann muss ich noch mal neu authentifizieren, das heißt, dann muss ein Passwort angeben. Das heißt, jemand, der die Session stil, der kann nicht einfach bestimmte Daten ändern oder da kommt er gar nicht erst dran, weil er trotzdem noch mal das Passwort eingeben muss und das kennt er nicht. Es ist also eine Safety-Maßnahme und die ist relativ trivial, die ist ein bisschen inconvenient, aber letztendlich ändere ich nicht so oft meine E-Mail-Adresse oder diese Daten, die sind halt wichtig und dann ist auch die Akzeptanz vom Nutzer relativ hoch. Man muss das vielleicht auch ein bisschen in den Kontext setzen, ein bisschen erklären, warum muss ich ja jetzt noch mal mein Passwort eingeben. Ich bin doch schon eingeloggt, aber das hilft gegen Haufenunfälle oder mögliche Angriffsszenarien, weil das mit dem XSS ist halt nicht so einfach, sauber zu kriegen. An der Stelle kann halt der Angreifer sogar meine Session übernehmen, weil er kommt nicht an diese Daten ran oder er kann sie zumindest nicht einfach ändern. Auch hier gibt es wieder jede Menge Feedcheats, die sind immer so ein, zwei, dener vier Seiten im Prinzip, wo man das in komprimierter Form dann nochmal schauen kann, was in Best Practices, wie geht man damit um, was macht man da Sinnvolles, Aus-Hedication-Password-Storage, wie geht man vergessen, Password-Session-Management und so weiter. Eine gute Quelle ist auch das ASVS-Projekt, das ist quasi der Application-Pentest-Standard oder Application-Security-Verification-Standard. Das ist auch eine gute Quelle, weil das, was die Pentest-Stars oder so checken oder was so üblich angewiesen sind, ist auch immer eine gute Idee. Da gibt es auch ein extra Projekt für, was soll ich denn eigentlich als Verteidiger in dem Sinne tun, weil was sind denn die Standard-Fahde, über die die Leute kommen, die ich nicht bei mir im System haben will. Genau und ja, Identitätsdiebstahl ist doof, deswegen schützt die Leute und ihre digitalen Identitäten. Genau, das ist auch das zweithöchste Risiko aktuell, nämlich Broken-Authentication-And Session-Management. Darüber passieren die meisten Sachen und das ist richtig, richtig hässlich. Es gibt ja immer diese schönen Blog-Post, ja, wie mir mein Amazon-Account gestohlen wurde und dies und jenes oder von was auch immer, weil es da nicht funktioniert hat oder der Support ein bisschen leicht, glaube ich, war oder die Security-Questions nicht gut waren, aber das sind kritische Sachen. So, dann kommen wir zum nächsten, das Rollen-Management. Neben den normalen Usern gibt es ja oft auch noch Back-Entusers oder Leute mit Mehrrechten als den anderen. Genau, wie macht man das richtig oder falsch? Genau, hier sind so ein paar wieder, wie macht man das vielleicht nicht richtig? Verspielte, warum ist der erste Teil blöd? Der ist genau dann blöd, wenn ich eine Rolle ändere, eine neue Rolle dazubekomme, dann viel Spaß, weil ich dann an jeder verdammten Stelle im Code an, also wo so ein rechte Check passiert, was darf der, darf der diese Funktion jetzt benutzen und ich dort hartgekordete Rollen drinstehen habe, habe ich schon verloren? Das kriegt kein Mensch gemanagt, wenn es ein bisschen größere Anwendung wird als ein Homepage oder so Deswegen auch hier nicht keine zentrale Stelle, wo diese Zugriffslogik gemacht wird, sondern komplett verteilt im Projekt. Das ist schon klar, dass es irgendwann schief geht. Ja, hier auch wieder, irgendwer hat ein Cookie, da steht Atmen gleich eins drin oder sowas. Kann man machen, muss man nicht. Genau, sichere die Forts und es gibt so ein paar Prinzipien in der IT-Sicherheit oder in der Informationssicherheit, nie to know. Also ich komme da nur hin, wenn ich es wissen muss und ich kann es auch nur machen, wenn ich es darf. Man kann es auch andersherum machen, das heißt aber, ich habe verdammt viel zu tun. Interessant, was soll ich denn? Das weiß ich nicht, was damit gemeint war. Ja genau, das habe ich eben schon erzählt. Das hat auch mit den Opernpunkten zu tun, wenn ich an jeder Stelle, wo ich so einen Check mache, das so programmiere, dass ich jedes Mal, wenn ich was an meiner Security-Änderung den Code anfassen muss, dann ist das blöd. Kann man machen, sollte man aber nicht. Genau, hier ist auch noch mal das sticky per session. Ja, wenn du als Atmen authentisiert bist, dann bist du das und wenn jemand die Session hat, dann ist das auch. Kann man machen, muss man aber nicht. Man kann es auch anders machen. Und dann auch, dass ich pro User eine eigene Policy habe, das ist halt schlecht zu managen. Man kann das alles so machen, was da steht, aber das hat so ein Rucksack hinten dran von Dingen, die man schlecht gemanaged kriegt. Das sind dann so Prozessfragen und so und das kriegt man in der Regel langfristig nicht koordiniert. Genau, also Roar-Based Access Control wird ja von vielen Frameworks propagiert und oft wird es so gemacht hier oben. Das ist genau dieses, ja, wenn der User die Rolle XY hat, dann darf er die Funktion Z ausführen. Und genau, das ist schlecht, wenn man das so macht. Man kann das so machen, aber man sollte das vermeiden und man könnte das auch so machen, dass er das jetzt hier so ein bisschen nicht die Rolle, sondern er hat ein Recht. Da habe ich auch immer noch so ein bisschen das gleiche Problem. Am besten ist es, wenn man, oder was heißt am besten oder was ich gut finde, ist, wenn man im Prinzip so eine zentrale Security Funktion hat, wo man das eine Stelle Code hat und man gibt den User und den Kontext drüber und die entscheidet dann, was da passiert. Und dann kommt halt ein True oder ein Forts zurück und ich muss diese Zeile Code nie wieder anfassen. In dem Fall ist das hier eng gekoppelt, aber ich habe hier auch so ein definiertes Recht. Das verweilt zwar einer anstelle. Das heißt, ich muss hier das nicht wieder anpassen. Ich kann da auch beliebige Rollen dann mit dem Recht versehen und außerhalb des Codes kann ich das rechte Management machen. Deswegen ist das auf jeden Fall besser als die Variante hier oben mit den hard gekodeten Rollen. Genau, dann gibt es noch die Variante mit diesen Claims. Hier oben ist wieder das Beispiel, ich habe hier wieder hard gekodete Rollen in meinem Code stehen, ist zwar diesmal als Attribut definiert, aber immer noch schlecht. Ich muss dann wieder an jede Stelle, wo diese Dinge sind, wenn da meine Rolle dazukommt oder eine rausfällt und dann übersieht man irgendwas. Danach suchen ist auch schwierig, weil sieht es jetzt immer so aus. Und ich habe da beliebige Kombinationen, also das ist nicht gut. Und hier oben ist halt auch wieder, der hat ein Claim, also der hat eine Permission und die check ich und ich check nicht seine Rolle, in der er ist. Aber wenn er die Rolle hat, dann hat er halt entsprechende Menge an Permissions oder halt Claims, er claimt, dass er das darf. Und dann gibt es hier eine Funktion, die prüft das dann. Das ist jetzt jetzt Attribut dran, das macht den Quotschlanker übersichtlicher. Und dann darf er das ausführen. Hier ist noch ein Beispiel für JavaScript, ist das glaube ich, beziehungsweise nicht, hier geht es um Slogging. Genau, weil hier habe ich halt auch wieder diese, diese hat gekodete Rolle. Dann darf er das. Und hier ist halt auch dann wieder ist Permission. Das heißt hier geht es dann um das Recht und nicht um die Rolle, die er hat. Wir sind halt immer so hart gekodete Strings drin, beziehungsweise hier kann man, das kommt jetzt auch gleich noch, genau, auf Instancebene. Ihr seht hier diesen Doppelpunkt, das heißt das sind dann schon die Klassen und die Instanzen. Das muss man halt schauen, ob man das sinnvoll nutzen kann, aber das ist auch noch eine interessante Variante, wie man das heutzutage tun würde. Und dann kann man sogar auf Instancebene von Systemrechte definieren und abfragen. Genau, was mitigieren wir damit oder was adressieren wir mit diesen Controls? Funktion der WorkSets-Kontrolle, also dass das nicht richtig gemacht wird oder dass User Dinge tun können, die sie nicht sollen oder Dinge nicht tun können, die sie eigentlich sollen, weil dann da irgendwo so eine hart gekodete Rolle steht und die stimmt nicht mehr. Und dann funktioniert es nicht, entweder in die eine oder in die andere Richtung. So, was haben wir noch für ein Control? Datenschutz, Protect Data. Wichtiges Thema, Data in Transit, HTTPS kennt wahrscheinlich jeder hier. Genau und das ist heutzutage auf jeden Fall kein Performance-Problem mehr. Und es bringt eine Menge positive Eigenschaften mit, wenn man das macht. Es gibt immer noch einen Haufen Webseiten, die nicht auf HTTPS laufen oder die nur fürs Lock-in HTTPS benutzen und dann den Cookie wieder bei HTTP rum schicken, wenn die Session einmal authentifiziert wurde und solche Spiele, aber eigentlich gibt es keinen Grund mehr, wenn man, wenn man, also auch für Seiten, die gar keine Funktionalität haben, die in einem eingeschränkten Bereich ist, nicht HTTPS zu benutzen. Auf jeden Fall ist das Performance-Problem eigentlich nicht mehr relevant an der Stelle, weil die Systeme so leistungsfähig sind, dass das normalerweise kein Problem ist. Natürlich kann man darüber auch ein paar Angriffe machen, aber die sind eigentlich gut unter Kontrolle. Genau, man kriegt hier die drei, die CIA Eigenschaften, nämlich Confidentiality, Integrity, Authenticity, also Vertraulichkeit, Integrität und ich weiß auch, wo es herkommt und ich weiß auch, dass es unterwegs keiner verändert hat. Deswegen ist HTTPS immer eine gute Idee, auch wenn ich auf einer stinknormalen Webseite bin, dann weiß ich, wie gesagt, es kommt wirklich von der Seite und es sieht auch noch so aus, wie die es mir geschickt haben, ist ja schon mal ganz nett. Genau, hier gibt es auch wieder 1000 Millionen Best Practices, wie man das macht. Es gibt auch einen Haufen Scanner dafür, wo man seinen Domain eingeben kann und dann kriegt man eine Liste zurück, wie gut oder schlecht man das Setup da gerade hat. Und hier gibt es auch von der obersten Empfehlung, es gibt aber auch jede Menge andere gute Ressourcen, wie man das sicher macht. Ich habe vorhin schon mal kurz angesprochen, inzwischen gibt es ein paar zusätzliche Headers, die man mitschicken kann. Hier sind zwei davon erwähnt und das andere sind Settings vom Protokoll, also vom TLS Protokoll dann. SSL möchte man nicht mehr benutzen heutzutage. Das eine ist HSTS, heißt Ausgleichungs-Trick Transport Security, also das Halschiff für HTTPS. Was macht das? Das will man auch nur benutzen, wenn man auf der Seite ist, die HTTPS hat, weil das sagt dem Browser, lieber Browser, wenn du das nächste Mal kommst, gehst du nur per HTTPS hierher, auch wenn dein User HTTPS vorn dran schreibt. Warum ist das sinnvoll? Das vermeidet eine Menge von Angriffen, die möglich sind, wenn man von HTTPS auf HTTPS redirectet und das macht den Header kriege ich erst, wenn ich das erste Mal da bin und habe ich also immer noch ein Problem, bevor ich das erste Mal auf die Seite komme und um das zu umgehen, ich glaube das kommt noch weiter hinten, mache ich gleich, da gibt es eine extra Folie für. Was man auf Protokollebene macht, das nennt sich Forward Secrecy, das heißt die Session Keys, die man zum tatsächlichen Datenaustausch benutzt, weil diese Zertifikate, das nennt sich Public Key-Kryptografie, das ist ein bisschen aufwendig beim Rechnen, deswegen macht man das nur ganz am Anfang und wenn man dann die Datenaustausche, man symmetrische Kryptografie, das ist ein bisschen schneller und diese Schlüsse, die man da benutzt, die kann man so untereinander aushandeln, dass sie kein anderer abgreifen kann und auch später, wenn er mal diese Public-Private-Key-Pare von dem Server in die Hand kriegt, dann hilft ihm das nix. Deswegen will man diese Verfahren benutzen und ist dann auch sicher, wenn irgendwer, der dazu in der Lage ist, den Treffig mitgeschnitten hat und vielleicht an die Keys kommt, dann hilft ihn das nix, weil diese Keys, die nennt sich Ashrow Mill, also die sind nur temporär und wenn die Session weg ist, dann kann das nie wieder jemand entschlüsseln. Was es dann auch noch gibt, Relativ Noise, Certificate-Transparency, warum macht man das, warum machen wir auch dieses Pinning, was hier gleich noch kommt, weil diese ganze Public Key-Infrastruktur ist ja nicht so ganz zuverlässig und sicher, wie alle gedacht haben. Also das war schon immer klar, dass das sehr komplex ist und ich habe da kommen gleich noch ein paar Details zu, deswegen gehe ich jetzt noch nicht so weit drauf ein, aber auch diese Certificate-Transparency-Initiative, die ist glaube ich auch von Google gestartet worden, die ist dazu so ein bisschen mitzutrecken, welche CA hat denn gerade welche Zertifikate ausgestellt oder auf welchen Servern werden dann welche Zertifikate ausgeliefert und dann so ein bisschen mitzukriegen, ah da hat aber gerade jemand nochmal ein Zertifikat für die gleiche Domain ausgestellt, das ist aber komisch, es ist so ein bisschen diese Certificate-Transparency-Geschichte, die hat aber auch, naja die ist auch nicht unbedingt das gelbe vom Ei, also die löst nicht alle Probleme an der Stelle, man kann das auch umgehen und so weiter. Bei dem Pinning geht es darum, dass sich der Browser dann der Server schickt noch ein Hash mit von dem Zertifikat oder eines Zertifikats in der Kette und dann merkt sich der Browser, hey gestern hast du mir aber ein anderes Zertifikat geschickt als heute, ich gehe jetzt woanders hin, ich gehe jetzt nicht auf die Seite, die ist nicht von dir. Genau, also zum HSTS, aber da erzähle ich morgen, nee quatsch ich morgen heute Abend um 5, auch noch mal mehr drüber, weil es gibt da noch ein paar Mehrheader, es gibt den, es gibt den Keypinning-Header, der gleich noch kommt und dann gibt es noch vier andere, die momentrelevant sind. Genau, also was macht dieser Header, der zwingt den Browser und der merkt sich das auch, man kann aber in den Browser-Settings noch wieder rauslöschen, wenn irgendwas schief gegangen ist, der merkt sich das halt, dass man nur noch mit hat die TPS mit der Seite reden möchte, beziehungsweise die Seite kann den Browser oder dem User-Agent, das kann ja auch ein Mobile-View sein in der App, also gar kein direkt sichtbarer Browser, aber du gehst hier nur noch per hatte TPS hin. Das ist schon mal cool, aber wie gesagt, ich habe immer noch das Problem, bevor ich das erste Mal zu der Seite gehe, gehe ich vielleicht per hatte TPS hin, dann habe ich wieder die ganzen Probleme an der Backe, die es da so gibt, die man aber nicht haben möchte. Deswegen gibt es eine Preload-List, was ist das? Da kann ich meine Domain, die ist hardcoded im Browser-Sourcecode hinterlegt, dass man da nur noch per hatte TPS hingeht. Das heißt, bevor der User das erste Mal auf diese Domain geht, weiß der Browser schon, wenn er den Domain dann eingibt, ohne ein Protokoll von zu spezifizieren, ich gehe dann nur per hatte TPS hin. Fertig. Hat auch ein paar Nachteile, weil mit der Preload-List kann man wieder so eine Super-Cookie-Variante, da gibt es einen lustigen Angriff, der ist glaube ich immer noch existent. Das heißt, man kann für alle Domains, die auf der Liste stehen, gucken, ob der schon mal da war. Ja, irgendwas ist immer. Genau, wenn man da Mitglied werden möchte, trotz dieses Super-Cookie-Problems, was da quasi inherent ist, weil es auch wieder so ein Timing, Side-Channel-Angriff, weil dann irgendwas länger oder langsamer ist und darüber kriege ich das halt raus. Dann muss man als erstes den Header ausliefern, der Header muss bestimmte Eigenschaften erfüllen, da muss nämlich eine bestimmte Max-Age haben, das heißt, er darf nicht zu klein sein. Und inzwischen ist es glaube ich auch Pflicht, dass Subdomain True sein muss, das heißt für die Domain, für alle Subdomains ist das dann gesetzt oder enforced. Ich trage nur eine Domain ein, aber für tralala.xy.z gilt es dann auch, auch wenn ich nur tralala. Oder wenn ich nur xxy als Domain angemeldet habe. Und dann kann man das hier auf dieser Domain die URL geben, dann checkt er, ob der Header da ist, dann kommt es ins Change-Lock vom Chromium und dann ist es ungefähr zwei Monate später hardcoded im Browser. Was wichtig ist dabei, der HTS-Header hat so ein paar nette Eigenschaften, die einem aber furchtbar auf die Füße fallen können. Ihr kennt das ja, man kommt auf eine Seite und sagt, ja, irgendwann stimmt mit dem Zertifikat nicht, da hat jemand vergessen, die Domain da auch noch als Subject Alternative Name einzutragen und dann kann man sagen, hier gibt es einen Advanced-Button und dann sage ich, ja, ich weiß schon, was ich mache, jetzt lasse mich mal dahin, das geht nicht mehr. Das heißt, wenn der Chrom, der Firefox, der IE, beim Safari weiß ich jetzt nicht sicher, diesen Header gesehen hat, dann gibt es auch keine Exceptions mehr. Das heißt, ihr kriegt dann nur noch die Warnung, aber ihr könnt nichts machen, ihr kommt nicht an diese Seite ran. Wenn irgendwas mit HTTPS nicht stimmt, kommt ihr mit einem normalen Browser nicht mehr an die Seite ran, wenn ihr den HTS-Header mitstirbt. Wenn ihr nicht auf der Preloaded-Liste steht, dann kann man immer noch die wieder rauslöschen, da gibt es eine URL, die zeige ich dann heute Nachmittag, aber wenn die hardcoded ist, dann ist sie hardcoded und es gibt keinen Weg drumherum, außer einen anderen Browser zu benutzen, der HTS nicht kann. Also dann muss man, auch das ist wieder dieses Prozesting, wenn man also so ein Header da in seine Seite einbaut und das in der Welt verteilt und hat seine Prozesse hinten nicht im Griff, kann es furchtbar schmerzhaft werden. Man kann sich da wunderbar selber dossen, wenn man seine Prozesse nicht im Griff hat, weil dann läuft das Certificat aus, die Mähname stimmt nicht, was auch immer, dann sagt der Browser, du kommst hier nicht rein und ihr kommt da nicht rein und ihr könnt dann den Firefox aufmachen oder sogar den Edge oder den IE benutzen und ihr kommt nicht mehr auf diese verdammte Seite drauf. Dann müsst ihr irgendwas Altes aus der Bullet-Kiste holen, was den Kram noch nicht kann. Also muss man auch ein bisschen vorsichtig mit umgehen, aber ansonsten ist das eine super Sache. Also machen, aber man muss wissen, was man tut und man muss die Prozesse hinten im Griff haben. Genau, Certificate pinning, was adressiert, das habe ich ja gerade schon gesagt, das mit den CAs ist so eine Sache. Deswegen, so wie gesagt, ja dann schickt der Server jetzt einfach mit was denn der Hash von dem Key, nicht vom Certificat, das ist wirklich nur der Hash vom Pappel Key. Deswegen kann man, wer das sehen, es gibt immer mindestens zwei Hash oder drei, weil dann hat man noch so ein Vorberg Key, falls irgendwas mit dem anderen Key ist, muss den zurückziehen oder sowas. Dann kennt der Browser den schon und dann kann ich ein Certificat darauf aufstellen, das funktioniert aber trotzdem, weil der Hash geht auf den Key und das Certificat ist egal. Das heißt, wer wird wirklich der Key verifiziert, der benutzt wird. Und das kann ich auf jeder Ebene von der Chain machen. Ich kann die RUCA da einfach pinnen, das ist witzlos, weil die steht ich schon im Browser drin, die muss ich nicht noch mal pinnen. Kann ich, aber machen, weil ich dann sage, ich will nur von dieser RUCA-Zertifikate haben. Und alle anderen sind mir schnuppert und wenn jetzt einer da entscheidet, er muss für meine Domain auch ein Certificat ausstellen, weil er irgendwie in dem Land ist und der Geheimdienst vorbeigekommen ist, dann wird der User-Agent das Certificat von der anderen CA für diese Domain nicht akzeptieren. Wenn ich schon mal da war, hier habe ich also auch wieder dieses Problem, das funktioniert erst, wenn ich die Seite zum ersten Mal besucht habe. Das zeige ich heute Nachmittag noch. In dieser Briefage-Liste gibt es auch die Optionen, schon solche Keys zu hinterlegen. Das heißt, die sind dann auch Hard-Coded im Browser. Dann sind sie nur noch relativ schwer bis, also nur noch durch Austausch der Browser-Software zu manipulieren. Genau. Und das hier steht es auch ja Trust and First Use, ist wie mit dem HTS-Header. Der Server schickt mir halt einen Header mit, der bestimmte Dinge im Kleint triggert und die dann anders macht. Beziehungsweise bestimmte Features aktiviert, die per Default nicht aktiv sind. Genau. Hier ist das auch nochmal Trust and First Use. Gibt es ja auch noch ein Extra-Graph für, aber dieser, also TOFU ist jetzt nicht das deutsche Text oben, vollkrot unten, sondern Trust and First Use. Und dafür gibt es eine ganze Menge gute Gründe. Ihr seht, hier sind jetzt nur 10.000 Sekunden drin. Kann ich sagen, ja und wenn ich morgen wieder dahin komme, dann kenne ich den Pin ja gar nicht mehr. Bei HTS ist es ja schon so etabliert, dass man eine lange Zeit nimmt. Und hier ist die Idee, dass man zumindest während der Session, also während man auf der Seite ist, kann dann keiner ein anderes Zertifikat unterschieben in der Zeit. Wenn ich den Wert natürlich hör setze, wenn man jetzt so Let's Encrypt benutzt, zum Beispiel muss man ein bisschen vorsichtig sein, wenn er alle drei Monate das Ding wechselt und der Wert ist zu hoch und ich habe nicht genug Hashtag drin stehen für genug Public Keys, damit ich die Rotations hinkriege, dann habe ich mir wieder in den Fuß geschossen. Dann bin ich nämlich plötzlich offline, weil wenn irgendwas da nicht stimmt, dann lässt euch der Browser nicht mehr auf die Seite drauf und es gibt keinen Weg daraus, außer einen alten Browser zu benutzen, der das schon kann. Genau. Ja, so sieht das dann aus. Und hier gibt es diesen Advanced Singen, bloß da gibt es dann keinen Button mehr. Lass mich mal weitermachen, der ist weg. Könnte ausprobieren, ist so. Genau, jetzt nochmal dieses Forward Secrecy, das habe ich ja vorhin schon erklärt. Also gehe ich da jetzt mal drüber. Genau. Was kann man denn noch so auf so lustige Ideen machen, wenn man Software schreibt? Kryptografie einbauen. Total trivial. Gibt Libraries, tag fertig. AES, der Standard. Ah, jetzt gibt es hier, okay, weiß jeder was das ist? Irgendwie so drei verschiedene Varianten oder Modi, Codebooks, wie das benutzt werden kann. Okay, dann braucht man irgendwie einen Unique IV, Initialization Vector, so was wie das Sort beim Passwort, damit ich gleiche Nachrichten, nicht den gleichen Ciphertext rauskriege. Klebe ich da noch so ein bisschen Zufall dran, dann wird es auf jeden Fall mal unterschiedlich. Hat bestimmt auch jeder Entwickler drauf. Padding, was Padding? Weiß hier mal, was Padding ist? Ja, genau. Dann Key-Storage and Management, Kryptografie, Process-Asolation, Confidentiality, Age-Maker-Cypher-Text-Integrity, Traffic-Digitalization for the same master key. Don't forget your master key from good random source. Genau, viel Spaß. Und vor allem ist es sicher, dass es kaputt ist. Also Vorsicht. Auch hier gilt dann wieder irgendwie klar mit etablierten Bibliotheken arbeiten. Das ist halt auch so eine Sache. Die haben meistens auch irgendwelche Fehler, aber die haben wahrscheinlich weniger Fehler, als wenn man es komplett versucht selber zu machen. Also eine blöde Idee vor allem an einem Nachmittag ist garantiert, dass es kaputt ist hinterher. Weil man kann einfach so viel falsch machen und es ist verdammt schwer, alle Aspekte, die damit in Zusammenhang stehen, richtig zu machen. Und das sieht man ja auch immer an diesen Fehlern, die dann so hoch ploppen, auch von etablierten Bibliotheken. Man denkt, wie konnte das nur jemals passieren? Aber das ist halt nicht trivial. Auch hier gibt es wieder Unterstützung, weil ja, irgendwie, das kriegt ja kein Mensch auf die Reihe und welchen Modus muss ich ihn jetzt benutzen, damit das wirklich das tut, was ich wollte und nicht quasi so steht dran ist, aber quasi plaintext. Genau. Und das ist, hier gibt es eine Library von Google, die ist Open Source. Die deckt jetzt drei Sprachen ab. Noch mehr. Was? Der telefoniert. Der Obertroll telefoniert. Genau. Also hier sind, aber hier, also was der Vorteil von dieser Bibliothek ist, hier ist so die ganzen Stichworte, die wir da gerade gesehen haben, die sind da schon mal in einem vernünftigen Default-Modus und man kann, ja, also welchen Algorithmus benutzt man, welchen Modus benutzt man den? Was sind, das sind sinnvolle Schlüsserlängen? Wie macht man das mit der Key Rotation und so weiter? Das sind alles so Dinge, die sind nicht trivial. Und wenn man davor nicht drüber nachdecken, einfach Kot schreibt, dann kann das Böse ändern. Genau. Das ist eine weitere Library, die was Ähnliches macht. Könnte euch angucken, also wer das braucht, die meisten brauchen das jetzt nicht so, weil es das irgendwie schon an der Stelle hat. Genau. Was gibt es ja noch schönes, entweder Logging and Intusion Detection. Kontroll acht, wir haben es auch bald geschafft, nur noch zehn Folgen. Ja, Logging. Warum, warum soll man Logging machen, um die User auszuspielen? Nee, es gibt auch noch einen zweiten Aspekt, beziehungsweise aus IT-Sicherheitsaspekt. Es ist immer schön, wenn man weiß, was in dem System passiert, wirklich, man ist hin, man schreibt irgendwie sinnvolle Daten weg, vielleicht nicht alles. Das ist nicht auch minimal, aber effektiv. Also und auch hier ist es gut, nicht alles selber machen zu wollen, oder vielleicht auch etablierte Libraries oder Frameworks zurückzugreifen. Das sind hier auch wieder nur Beispiele. Das ist jetzt nicht so, das sind die besten oder sowas. Aber das ist halt auch nicht trivial. Und hier unten steht auch noch was schönes. Der dritte Punkt, auch bei Logs sollte man Encoding machen. Ja, haben wir vorhin schon gehört, wie ich so in meinem Log encode. Ja, wenn du das Log später anguckst, was passiert, dann hast du plötzlich eine XSS-Attacke in dem Viewer vom Log, so um drei Ecken. Und warum die Leute plötzlich so viel über dein Infrastruktur wissen? Könnte passieren. Deswegen sollte man auch, da steht wieder Antrase Data, ja, encode all, oder validate all input, encode all your input. Und auch noch richtig, ja, von sehen, es gibt ja fünf, sechs verschiedene Kontexte, muss man anders encode, damit es nicht so einfach ist. Genau. So, hier ist was schönes für die PEN-Tester. Der letzte Punkt, kommen wir gleich zu. Genau, also input validation muss ich, wenn ich es auf Kleinzeit mache, halt auf Serverseite nochmal machen. Da habe ich aber einen ersten Intusion Detection Point, weil wenn ich weiß, der schickt mir Sachen, die nicht aus dem Pasa da gekommen sind, dann hat irgendwer rumgespielt. Easy. Kann man also schon sehr leicht so so ein erstes Flag setzen. Okay, an der Session ist was komisch. Oder das hat zumindest im Log Flaggen. Da kommt input, der kommt nicht, wenn der User das System normal benutzt. Genau, dann auch sehr schön, kann man auch schön benutzen, um Bots so ein bisschen zu Detecten mit ein bisschen cleverer Heuristik. So versteckte Felder und so was, wenn dann da plötzlich Daten drin stehen oder Sachen zurückkommen, die normaler User eigentlich nicht klicken kann, aber der Angreifer vielleicht schon oder der Bord, der da drüber läuft, dann merke ich, ja, da ist auch was komisch. Genau. Forst Browsing to Common Attack Entry Points. Hier unten ist auch in der, weiß hier, was eine Robots TXT ist. Damit sage ich ja gut, der Submaschine, das sollts indizieren und das nicht. Und oft schreibt mal da rein, genau, das Lash, Atmen, Secret Lock-in. Das soll er bitte nicht indizieren, das macht dann Google und Amazon und Bing und all die guten Suchmaschinen und die anderen, die gehen genau dahin. Das kann ich aber auch ausnutzen, indem ich da eine URL hinschreibe, die gar nichts mit einer Einbildung zu tun hat, also Honeypot, und sage, ah, der Pentaster, was macht er jetzt? Erstens, da geht es zu dieser URL, da weiß ich schon, ah, da ist er. Habe ich also auch wieder so ein Links und für den ist es jetzt schwer zu unterscheiden, ist das jetzt echt oder nicht? Das sieht er nicht von draußen. Also ich habe eine Standardsoftware, wo ich weiß, dass heißt aber nicht so. Also das kann man auch benutzen, um Angriffe oder Manipulationsversuche frühzeitig zu erkennen. Aber deswegen ist Logging wichtig, sonst kriege ich es gar nicht erst mit. Genau. Ja, hier bleibt dann Secret Injection. Also so was kann ich auch sehen, das kann ich mitloggen. Genau, wenn die Reihenfolge von bestimmten Schritten nicht eingehalten wird, das sind alles so Standardsachen, die man zählen, loggen kann, auswerten kann und dann entsprechen, der User geht nicht von 1 nach 5 nach 3, aber irgendwer anders hat schon. Hier gibt es auch eine ganze Menge Sachen, wo man sich wieder weiter mit beschäftigen kann. Genau, das habe ich schon öfter gesagt. Control 9, benutzt Frameworks und Libraries und wenn ihr meint, die könne ich das, was ihr braucht, dann bringt euch ein und erweitert sie, ergänzt sie, macht sie besser. Genau. Die letzten drei Kontrolls decken quasi mehr oder weniger alle Punkte ab, aber den einen mehr oder den anderen weniger. Jetzt haben wir noch einen Punkt übrig, sind nur noch drei Slides, Air Run Exception Handling. Machen auch immer ganz toll, richtig. Genau. Man handelt eine Exception und dann wirft man eine neue. Was ist das? Ne, also Exception, aber was das ist, ist im Prinzip auch Exception Handling ist nicht trivial und wird meistens nicht richtig gemacht. Was sollte man tun? Man sollte es auch versuchen zu zentralisieren. Hier gibt es wieder so ein Ding, man will dem User was mitteilen, aber man soll ihm nicht alles sagen, aber man sollte alles loggen. Also ins Log kann ich ja mehr schreiben, als was ich in der Fehlermeldung auf der Seite dem End User präsentiere, aber sollte was damit anfangen können. Es gibt auch so ein paar schöne Guidelines, auch wenn die immer die Bösenjungs waren von Microsoft, das muss verständlich nachvollziehbar und actionable sein, eine Fehlermeldung zum Beispiel, auch bei Security-Meldung. Und wenn es nicht actionable ist, dann ist es schlecht, um so Geschichten. Genau. Für die interne Sicht kann ich ja aber viel mehr Daten wegschreiben, also dieses Logging Ding. Was GO, also die Sprache GO, macht, die haben gar keine Exception Handling mehr, weil es keiner richtig auf die Reihe kriegt. Die haben Error Handling und wenn die Exception auftritt, dann hält die Anwendung an. Also da gibt es nur Tod, es gibt keine Exception. Es gibt nur normale Fehler, die muss man, die kann man handeln, die muss man dann aber auch abfragen, weil ich dachte, das ist ja eine relativ junge Sprache und ich habe gesagt, ja das mit den Exceptions, das war zwar eine coole Idee, aber irgendwie macht das keiner richtig. Aber wir haben das halt in vielen Sprachen, deswegen müssen wir uns damit auseinandersetzen oder die Leute fit machen und zumindest sensibilisieren, dass sie darauf achten und dann kriege ich auch eine bessere, eine robustere Anwendung hin. Genau. Jetzt haben wir es geschafft. So, gibt es Fragen, sind alle eingeschlafen. Also es war relativ High-Level, an ein paar Stellen ging es ein bisschen weiter runter, aber nicht so furchtbar tief. Es ist halt einfach, das soll auch für den normalen Nicht-Security-Spezialisten-Entwickler ist das Ding halt auch gedacht, sondern dass man so ein bisschen das im Hinterkopf hat. A. Was sind die Risiken? B. Was sind die Controls? Also was sind die Möglichkeiten, damit auf Coat-Ebene umzugehen und was sind die Mache des möglichst richtig, weil man kann Coat auf tausend Arten schreiben. Die Funktion ist toll, die Security leidet eh immer, aber wenn man das so ein bisschen im Hinterkopf behält und ein bisschen berücksichtigt, dann ist es schon mal, sind wir ein ganzes Stück weiter und den Aspekt mit, ja man kann ja nicht immer den ganzen DigiSeekout behandeln, da kommen wir dann heute Nachmittag noch mal drauf mit diesen ganzen Headern, die es noch gibt, womit man das Problem so ein bisschen auf der Infrastruktur-Ebene angreift und sagt ja okay, wenn die Leute den Code nicht auf die Reihe kriegen, was quasi ein Fakt ist, dann gucken wir mal, was wir noch in der Infrastruktur tun können, um die Ebene ein bisschen sicherer zu machen. Das erzähle ich dann aber um fünf. Okay, dann vielen Dank.