Jahresend-Mix 2020

Simon: Hallo, willkommen zum INNOQ Security Podcast. Zu unserer Abschlussfolge für das Jahr 2020. Wir haben ein bisschen anderes Format dieses Mal gewählt. Und zwar habe ich mir gedacht wir fragen einfach mal die Kollegen und Kolleginnen, was hat sie denn irgendwie im Jahr 2020 irgendwie beschäftigt, was irgendwie einen Security Bezug hat. Häufig sind das ja so ein bisschen triviale Dinge, wo man der Meinung ist eigentlich müsste das ja jeder wissen und man hat selbst schon fast so ein bisschen ein schlechtes Gewissen. Und gerade so im Gespräch mit den Kollegen stellt sich dann raus, dass ist dann für den ein oder anderen auch etwas Neues mit dabei. Und wir haben einfach die Hoffnung, dass euch da vielleicht ein paar Impulse gibt, guckt einfach mal in die Shownotes, wenn euch ein Thema näher interessiert. Ja und ansonsten viel Spaß damit! Ja, das einfachste wird sein mit dem Christoph mal anzufangen. Was hattest du denn 2020 so für Learnings oder ein Thema, was dir irgendwie begegnet ist und das in Erinnerung geblieben ist?

Christoph: Also ich hatte 2020 ganz viele Themen und ganz viele Learnings. Aber eins würde ich gerne ganz besonders herausstellen und das liegt daran, dass 2020 ja ein ganz besonderes Jahr war mit der Corona Krise. Und eins ist mir dabei aufgefallen, was ich vorher schon so ein bisschen unterbewusst gewusst habe oder so mitgekriegt habe, aber was jetzt also wirklich stark vor Augen geführt war. Und zwar, dass wir in der Security noch ganz viel zu lernen haben in Sachen UX. Und warum ist mir das aufgefallen? Jetzt hat das Jahr 2020 so mit sich gebracht, dass ganz viele Leute das erste Mal irgendwie im Homeoffice arbeiten müssen oder remote arbeiten müssen und dafür müssen halt Computer Arbeitsplätze irgendwie zu Hause eingerichtet werden. Und das habe ich halt bei vielen Bekannten mitgekriegt und auch in der Familie und wurde da auch öfter mal zu Rat gezogen. Und da habe ich gesehen, dass die UX in allen Security Bildern halt völlig hinterherhängt. Das fängt an, wie richte ich überhaupt so eine zwei Faktor Authentifizierung ein? Oder ich habe so eine Windows VM Client da, der mir nochmal ein zweites Windows Desktop anbietet, das dann auch im Fullscreen laufen kann. Wo ich dann nicht weiß, in welchen muss ich meine Passwörter eingeben? Wo befinde ich mich überhaupt? Und ich habe da gemerkt, dass bei solchen Sachen die meisten nicht Technik affinen Benutzer alle scheitern. Also ich hatte bis jetzt gedacht zwei Faktor Authentifizierung super. Einmal eingerichtet und danach geht alles wieder einfacher. Aber die Realität hat mir gezeigt: Für die Meisten viel schwieriger und wenn sie es nicht müssten und sie daran scheitern, dann machen sie es erst auch gar nicht. Und das ist in so vielen Aspekten so. Und diese Diskrepanz zwischen wir machen sicher und wir machen es benutzerfreundlich, die müssen wir ab jetzt, ab 2021 ändern in vielen Belangen. Das war mein größtes Learning.

Michael: Hi, ich bin der Michael und habe zwar vielleicht nichts Spektakuläres dieses Jahr über Security gelernt, aber wir haben in dem Rahmen von ein paar INNOQ remote Events immer abends so capture the flag gemacht. Das ist… ja vereinfacht gesagt, man löst Aufgaben durch Hacking, indem man eben irgendwelche Dinge machen muss, um an irgendwelche versteckten Flaggen zu kommen. Und dabei ist mir nochmal klar geworden, wie wichtig eigentlich so Security Grundlagen sind, dass man da vielleicht auch ein bisschen Wissen drüber hat. Also da sind SQL Injections ganz spannend, wie kann man bei SQL Injections eben nicht nur Werte rauskriegen, sondern auch über Timing Dinge erraten? Wie, wenn das etwas länger dauert, dann ist wohl der nächste Buchstabe des Passortes richtig. Und das ist einfach superwichtig, dass wir als Profession uns das nochmal bewusst machen, dass man eben gerade auch die Grundlagen absichern muss, weil das eben ist eben auch die Basis von guter Sicherheit neben den ganzen anderen Mitteln, die man da so hat.

Lucas: Hallo, ich bin der Lucas und was ich dieses Jahr gelernt habe, ist ein bisschen etwas darüber, wie man Passwörter richtig in der Datenbank speichert. Ich habe schon vor langer Zeit gelernt, dass man das am besten als Hash macht. Das haben wahrscheinlich die meisten Hörerinnen und Hörer schon gehört, dass das so ist und das sollten wir auf jeden Fall alle tun. Aber ich habe nie so wirklich darüber nachgedacht, wie genau das dann aussieht. Also in meinem Kopf war es dann tatsächlich einfach so, dieser Hash wird einfach so in die Datenbank abgelegt und fertig. Vom Christoph habe ich aber dann gelernt, dass man vielleicht darüber nachdenken sollte, ob man neben diesem einfachen Passwort auch vielleicht Informationen darüber ablegt mit was für einem Verfahren man das denn da erzeugt hat, mit was für Parametern man das vielleicht erzeugt hat. Denn wenn man das vielleicht irgendwann mal verändern will, weil man merkt so: Hm, diese Hashing Funktion ist vielleicht nicht mehr ganz so super, man sollte die vielleicht durch eine neue ersetzen. Dann weiß man ja erstmal grundsätzlich nicht, welche haben denn noch die alte Version? Welche haben denn die Neue? Es wird sich ja erstmal schrittweise verändert, wir können ja nicht automatisch updaten. Da es ja Hashes sind, können wir nicht einfach sagen: Hash geht zum neuen Hash. Wir kennen ja den Originalen halt nicht mehr. Also sollten wir irgendwie wissen: Der hier ist noch im alten Verfahren gemacht. Damit wenn der User oder die Userin sich das nächste Mal einloggt, wir vielleicht das einfach überschrieben können mit der neuen Version, die dann ein neueres Verfahren verwendet. Und da habe ich das PHC String Format kennengelernt und das hat das standardisiert, wie man das ablegt. Ich musste das selber noch nie implementieren, ich habe da immer Libraries für benutzt, aber ich fand es sehr interessant zu verstehen, wie das so funktioniert. Ja, das war es.

Simon: Larysa beschäftigt sich bei uns unteranderem mit Themen wie Machine-Learning. Kennt vielleicht jemand aus dem normalen INNOQ Podcast, der im Juli erschienen ist: ML Ops mit dem Robert. Was hast du den 2020 so in Richtung Security Themen für dich so ein bisschen mitgenommen?

Larysa: Ja, Security Machine-Learning natürlich. Das ist ein riesiges Thema geworden, weil Machine-Learning zunehmend in Softwaresystemen deployed wird und genau da muss auch Security best practic von DevOps auch eingesetzt werden. Ja, weil Machine-Learning in Software hat eine ganze Reihe von Möglichkeiten von Security Schwachstellen offenbart und das hat auch dazu geführt, dass es einen riesen Forschungsgebiet wie Adversarial Machine-Learning entstanden ist, wo die häufigsten… Man sagt also, es gibt wo Machine-Learning Security wichtig ist, weil es gibt verschiedene Attacken, die Machine-Learning spezifisch sind. Zum Beispiel Data poisoning, dass wir die Daten vergiften, wenn… Damit wird ein Versuch bezeichnet die Integrität eines Machine-Learning Models zu beschädigen, indem man Trainingsdaten korrumpiert, ja. Und das ist natürlich…, man kann das auch Machine-Learning Model Vandalismus nennen. Oder auch so eine häufige Attacke ist so reverse Engineering, wenn man ein Machine-Learning Model in Software beschattet, zum Beispiel mit Public APIs und die Outputs von den Machine-Learning Model einsammelt, ja. Und dadurch, durch solche Querrys wird die maximale Information über ein Machine-Learning Model eingesammelt. Und ja, warum ist das wichtig? Es ist ja, auf diese Art und Weise kann man ein… quasi man nennt es so das als Machine-Learning Model Stealing oder so ein Plagiat in Machine-Learning, weil Machine-Learning Modelle sind intellektuelles Eigentum und das kann man genauso stehlen, wie anderes Eigentum. Oder es gibt so eine der häufigsten Attacken ist Model Inversion und ist eng mit reverse Engineering verbunden. Da versucht man an die Trainingsdaten ranzukommen, beziehungsweise die wiederherstellen. Und wenn wir auf Privacy zum Beispiel nicht aufgepasst haben, auf diese Art und Weise kann man aus den Trainingsdaten auf die Privatinformation aus den Daten ranzukommen.

Lars: Hallo, mein Name ist Lars und was ich dieses Jahr über Security gelernt habe, dass man nicht einfach nur bei Webseiten TLS anschalten sollte, sondern dass man auch sich mal genau die http-Header anschauen muss. Also TLS ist ja mittlerweile sehr verbreitet und durch Let’s Encrypt gibt es ja praktisch für alle Webseiten kostenfrei Zertifikate, aber die http-Header werden gerne mal vernachlässigt. Da gibt es zum Beispiel die Content Security Policy, damit kann man dem Browser mitteilen aus welchen Quellen so externe Inhalte geladen werden können. Zum Beispiel JavaScript, CSS oder irgendwelche Images. Und wenn man das nicht setzt, dann lädt der Browser einfach gerne mal auch Script Files von anderen Hosts. Und das kann natürlich ein Sicherheitsproblem sein und kann auch mal die ganze schöne TLS Verschlüsslung eigentlich unnütz machen, weil gegebenenfalls private Daten an andere Hosts weitergeleitet werden können. Und da gibt es noch eine ganze Reihe von anderen Headern, da gibt es noch sowas wie CORS und irgendwelche Frame Embedding oder was auch immer, gibt es eine ganze Menge Header und ich habe gelernt, dass es da auch verschiedenen Analysewebseiten gibt dazu. Da kann man seine eigene Webseite mal eintragen, die Domain und dann überprüft der erstens, ob die TLS Verbindung in Ordnung ist und dann halt auch ob die Header richtig gesetzt sind. Der macht dann auch Vorschläge was man da noch verbessern könnte.

Martina: Hallo, ich bin Martina. Ich habe mich im letzten Jahr hauptsächlich oder sehr viel mit Spielen und Security auseinandergesetzt. Spiele im Sinn von Spielen, mit denen man sich mit dem Thema Security und Software auseinandersetzt, weil man soll ja irgendwie an ein Thema herangeführt werden, indem es einen Spaß macht und nicht indem man irgendwie einen Frontalvortrag kriegt dazu oder sich durch haufenweise Dokumente oder sonst irgendwas wühlen muss. Und man setzt sich halt durch Spiele meistens auch ein bisschen anders mit einem Thema auseinander als im normalem Arbeitsalltag, weil man da halt anderen Situationen ausgesetzt ist. Und es gibt halt da eine recht große Vielfalt von Spielen von allen möglichen Herstellern, aber auch von Organisationen, von Einzelperson. Und zum Beispiel ist da recht bekannt von OWASP, das snake and ladders, das heißt glaube ich auf Deutsch Leiterspiel. Dann gibt es natürlich auch dieses elevation of privilege, davon gibt es einen Haufen Abwandlungen, auch sehr stark mit Privacy-Fokus oder mit Privacy Extensions. Das ist halt ein Gebiet, mit dem ich mich beruflich mehr beschäftige. Und in dem elevation of privilege gibt es dann noch eine Abwandlung, die speziell auf E-Commerce ausgelegt ist. Also an für sich sehr viele Bereiche, die den Softwareentwickler Alltag so abdecken. Das Einzige daran ist, was mir bisher aufgefallen ist, dass diese Spiele eigentlich eher so als Kartenspiele, als klassische, vorliegen. Also das heißt dieses Kartendeck ist halt aus Papier oder Karton, wie man das bei Kartenspielen so kennt und das ist halt in den letzten Wochen/Monaten echt nicht das praktischste, weil klassische Kartenspiele oder Spieleabende sind halt in Zeiten wie diesen eher ein bisschen schwer. Und da haben sich aber in den letzten Monaten auch entsprechende digitale Versionen davon entwickelt. Und die eignen sich dann zum Beispiel auch für Teamaktivitäten, die man auch remote durchführen kann oder auch für einen online Spieleabend mit Freunden. Und da möchte ich halt noch erwähnen von denen, die digitalisiert wurden sind, das LINDDUN GO, das ist halt privacy threat modelling von einem belgischen Spin-Off einer Universität. Und natürlich gibt es von dem elevation of privilege auch diverse Abwandlungen unter anderem auch von Alexa als eigenes Alexa Skill. Das letzte was ich gelesen habe, hatte ein relativ tolles Akronym, nämlich AWATO. Das heißt 'another week at the office’ und momentan, nachdem die Meisten doch eher im Homeoffice sind, kann ich mir sogar vorstellen, dass man simuliert zu spielen, wie es im Office so ist. Weil selbst wenn man jetzt eben auch mal ins Office schaut, dass ist ja doch etwas leer bei den Meisten und da ist man halt auch nicht so unbedingt den üblichem Office-Alltag ausgesetzt und eben den üblichen Threats, die eine so im Office-Alltag begegnen. Das Spiel wurde unlängst schon auf einer Konferenz vorgestellt, aber es ist leider noch nicht verfügbar, vielleicht dann in den Ferien irgendwann.

Dimitrij: Hier ist der Dimitrij. Bei mir geht es heute ein bisschen um GDPR, je nachdem wie viel Zeit wir haben. Und zwar die Erkenntnis, die ich gemacht habe ist, es dreht sich eigentlich so um Artikel 6 und recital (Erwägungsgrund) 30, in dem es um das was man als lawful basis in Englisch bezeichnet direkt. Und zwar steht da zum Beispiel, dass es sowas wie technische Identifikatoren gibt und der Ansatz von GDPR ist, dass man ja eigentlich verhindern möchte, dass so eine Art online Footprint oder Fingerabdruck des jeweiligen Cers entsteht. In einem Projekt, in dem ich jetzt unterwegs bin, finde ich, dass das ein bisschen ausartet, indem alle technischen identifier, die irgendwelchen Bezug mit der Person haben, also Person in Sinne der Attribute, im Sinne der kombinierten Attribute, Name, Vorname und so weiter. Wenn da ein Bezug existiert, unabhängig davon, ob dieser identifier überhaupt online irgendwo sichtbar sein wird, dann wird das schon als Person bezogenes Datum markiert oder angesehen. Und man kann sich denken, das hat dann sehr interessante Ausprägungen am Ende des Tages. Weil das bedeutet, dass jegliche Sequenz in der Datenbank, jegliche foreign oder primary key in der Datenbank als ein Personen bezogenes Datum betrachtet wird. Inklusive der organisatorischen… inklusive Einfluss auf die organisatorischen Prozesse, wie zum Beispiel der DPO muss ja involviert werden. Ja, der muss ja entscheiden: Darf das überhaupt verwendet werden oder nicht? Obwohl das ein notwendiges Übel ist, ja. Ohne kann das System gar nicht funktionieren. Und so gesehen haben wir sehr interessante Diskussionen in diesem Zusammenhang gehabt und haben immer noch. Und das war für mich so ein ‚aha‘ Erlebnis, von im Sinne eigentlich etwas sehr, sehr einfaches, simples, wo man überhaupt keine andere Möglichkeit hat, hier ein sehr… Ja, eine Art Elefanten aus der Mücke machen, mit anderen Worten. Das war halt interessant. Ja und jedem, der sich damit beschäftigen möchte, kann ich das nur nahelegen, man kann das wirklich ausarten lassen. Ja, das war meine Erkenntnis.

Thorsten: Hallo, ich bin Thorsten und ich habe in diesem Jahr in einen meiner Projekte zum ersten Mal an einem Threat Modelling Workshop teilgenommen. Natürlich haben wir uns in den Projekten, in denen ich vorher unterwegs war, auch mit Security Themen befasst und Schutzmaßnahmen umgesetzt. Über den Threat Modelling Workshop haben wir das Ganze aber wesentlich strukturierter und intensiver gemacht. Und haben dadurch einen viel besseren Überblick über die möglichen Bedrohungen bekommen. Wir haben das STRIDE Model verwendet, das Bedrohungen in verschiedene Kategorien unterteilt. Das sind nicht nur die üblichen Kategorien, wie zum Beispiel Manipulation von Daten oder Zugriff auf sensible Daten, sondern insbesondere auch weniger offensichtliche, wie Identitätsverschleierung, Verleugnung oder denial of service. Diese Kategorisierung kombiniert mit einer guten Moderation hat uns dann auf einige Bedrohungen aufmerksam gemacht über die wir uns ansonsten vermutlich nie Gedanken gemacht hätten.

Franzi: Hallo, ich bin die Franzi und ich habe mich dieses Jahr endlich mal im Detail mit Maßnahmen gegen CSRF auseinandergesetzt. Endlich habe ich mal die Zeit dafür gefunden. Und das Ganze war im Kontext von verteilten Systemen mit stateless implementierten Services, die mit mehreren Instanzen deployed werden. Und da habe ich rausgefunden, welche der Maßnahmen in dem Kontext gut funktionieren und am Ende bin ich hingewiesen worden, habe ich empfohlen bekommen, das OWAS CSRF cheat sheet und da ist quasi alles nochmal super schön zusammengefasst und aus dem Grund packen wir den Link dahin auch in die Shownotes.

Simon: Phillip, was war denn eins der Themen, die dich irgendwie mit Security Bezug 2020 begleitet hat?

Phillip: Ja, das war schon eine Weile her. Ein Kunde wollte halt, wie man das halt momentan so tut, eine Anwendung hinter einem single sign-on absichern. Dazu wurde Okta gewählt, das ist so ein öffentlicher single sign-on Provider und es wurde OpenST genommen halt als Sidecar, um halt das Token entgegenzunehmen und die Java Spring Boot Anwendung dahinter sollte dann halt dieses Token verwenden, um dann die Authenitification zu machen. Wir haben das Ganze dann als primäres Development Set erstmal aufgesetzt, um halt lokal auch diesen ganzen Flow nachbilden zu können und hatten alles so aufgesetzt, wie man da tun sollte. Alle Konfigurationen waren richtig, alle Settings waren korrekt, aber die Java Spring Boot Anwendung hat konstant einen 404 gemeldet. Und dann haben wir halt angefangen die Dinger zu Debuggen und ich glaube so nach 2–3 Stunden sind wir dann zu einer Stelle gekommen, wo bei Spring Boot eine Web Security Konfiguration ist und da gab es ein paar Filtersettings. Und dann konnte man sich so durch einige Stack Traces durchklicken und am Ende kam dann ein unkown issue von einem gewissen Zertifikat. Und dann kam halt raus, dass der Okta Log-In Service nicht mit einem Standard öffentlich signierten Zertifikat lief, sondern mit einem self signierten Zertifikat und dass die JBM auf dem natürlich die Anwendung lief mit diesem Zertifikat nichts anfangen konnte. Der Hintergrund ist halt der, dass die Anwendung, also speziell die Spring Boot Bibliothek den Token quasi mit bekommt und theoretisch gar nicht mehr mit einen Service reden muss, um ihn zu verifizieren. Allerdings werden die Konfigurations-Settings, wie dieser Token zusammengebaut ist und welcher Algorithmus verwendet wird, von einem Okta Service geladen. Und wenn diese Verbindung nicht stattfindet, dann meldet die Spring Security Implementierung einen 404 zurück und keinen 401. Und als wir dann die Zertifikate alle in den Cert Store importiert hatten, die waren natürlich da und irgendwo hat das natürlich gestanden, weil für das Docker Image brauche man die halt auch, um das zu bauen, hat halt auch alles funktioniert. Aber so nach… seit einigen Jahren, wenn mir sowas im Projekt begegnet, stelle ich halt immer die Frage: Wieso macht ihr halt immer noch selbstsignierte Zertifikate? Es gibt doch sowas wie Let’s Encrypt, es gibt tausend Anleitungen, wie man das vernünftig aufsetzt. Ihr habt überhaupt keinerlei Probleme mehr mit dem Rollout, das funktioniert alles automatisch. Und über Seitenkanäle war dann irgendwie… ja, kam so die Rückmeldung: Ja, aber manchmal möchte man den Verkehr ja auch kontrollieren und dementsprechend müsste man diese Verschlüsselung ja auch irgendwie aufbrechen können. Was für mich halt auch so ein bisschen das Sinnbild der, naja, der Politik in den letzten Jahren ist: Wir wollen halt sichere Verbindungen und wir wollen alles absichern und wollen alles auch hinter sichere Systeme stellen. Aber auf der anderen Seite wollen wir verlässliche, funktionierende Abläufe soweit umbiegen, dass wir halt trotzdem mitlesen können. Und in Quintessenz hat uns das einen halben Tag an Debugging Arbeit gekostet und es ist halt immer noch eine Lösung, wo man sagen muss, es ist zusätzlicher Aufwand, um eigentlich ein Standardverfahren soweit abzubilden.

Lisa: Hallo, ich bin die Lisa und mein Security Learning ist entstanden als ich für Softwarearchitektur im Stream den Christoph interviewt habe, beziehungsweise im Vorgespräch zu diesem Interview. Wir haben ein bisschen über OWASP gequatscht und ich dachte: Ja, die kenne ich so ein bisschen. Und ich wusste, dass es eine SQL Injection gibt, aber der Christoph, der hat mir noch gebeichtet oder berichtet oder wie man das nennen möchte, dass es eine Command Injection gibt, was ich total faszinierend fand. Einen Link zu der YouTube Folge zu Software Architektur im Stream packen wir in die Shownotes.

Jochen: Hi, ich bin Jochen. Was hat mich in diesem Jahr im Bereich Security am meisten überrascht? Keine Überraschung für mich ist, dass sich OpenID Connect als Authentifizierungsmethode durchgesetzt hat. Was wir seit diesem Jahr aber häufiger sehen ist, dass Active Directory mit der Komponente ADFS neben SAML auch eine OpenID Connect Unterstützung bereitstellt. Und immer mehr unserer Kunden setzten dies ein und sparen sich damit einen eigenen Authentifizierungsservice in den Anwendungen.

Felix: Hey, ich bin Felix und dieses Jahr habe ich im Bereich Security und Software am ehesten etwas über das Thema Threat Modelling gelernt. Das hat mich am meisten interessiert. Dazu gekommen ist es, weil viele Kolleginnen und Kollegen mir das Buch Threat Modelling von Adam Shostack empfohlen hatten und ich mich einfach mal hingesetzt habe und angefangen habe das zu lesen. Und dabei habe ich echt eine Menge gelernt. Als Consultant beantwortet man ja ganz viele Fragen damit, dass man sagt: Das kommt drauf an. Und in Security Fragen kommt es halt oft drauf an, was genau das Bedrohungsszenario ist, gegen das man sich eigentlich schützen möchte. Es gibt halt irgendwie, wenn man sich klarmacht, gegen was man sich schützen möchte und nicht sagt: Ne, wir müssen gegen alles geschützt sein, dann kann man die Ressourcen, die man für Security hat, konkret auf die Sachen, die wirklich Sinn machen, konzentrieren. Und genau dabei hilft eben halt Threat Modelling, Bedrohungsszenarien für die eigene Anwendung zu identifizieren und dann entsprechend Gegenmaßnahmen effektiv einleiten zu können. Die Strategien und Methodiken, die ich dabei gelernt habe, haben mich wirklich so ein ganzes Stück weitergebracht. Also ich bin da echt ziemlich von überzeugt, weil ich mache mir nicht mehr Gedanken: Wie schütze ich mich denn gegen alles und jeden? Sondern ich mache mir Gedanken: Was sind wirklich die schlimmsten Szenarien und die realistischsten? Und so weiter und so fort. Ich glaube Threat Modelling ist für alle Entwicklerinnen und Entwickler ein relevantes Thema und man sollte sich damit mal ein bisschen auseinandersetzen, nicht nur, wenn man sich auf Security spezialisieren möchte. Und besonders interessant an dem Thema fand ich, dass anders… also wirklich komplett anders als von mir erwartet, es gar nicht unbedingt immer zielführend ist sich in eine Angreifer-Perspektive zu versetzen, um Bedrohungen in einer Anwendung zu finden. Sondern dass es häufig sogar mehr Sinn macht, wenn man die Anwendung gut kennt und sich den Datenfluss der Anwendung anguckt.

Joy: Mein Name ist Joy Heron und das was ich dieses Jahr im Bezug auf Security gelernt habe ist, dass der SameSide Attribut von Cookies inzwischen sehr gut unterstützt wird von allen modernen Browsern. Das hat mich sehr gefreut. Was das bedeutet ist, dass wenn dieses Attribut an einem Cookie gesetzt ist, kümmert der Browser sich darum, dass dieses Cookie wirklich nur zu dem Server geschickt wird, wenn der Benutzer auch der wirkliche Domainer ist. Und das schützt also vor so diesen CSRF Angriffen. Ich habe auch den Unterschied zwischen SameSide…, es gibt zwei Werte, der SameSide Strict oder der SameSide Lax. Genau, und also die diesen Schutz auslösen. Ich glaube es gibt auch SameSide None, aber das kann man sich sparen an der Stelle. Aber ich habe mir auch…, also dieser Unterschied zwischen SameSide Strict und SameSide Lax kann ich mir tatsächlich sehr schwer merken. Was ich aber schon gemerkt habe ist, wo man wann was einsetzt und dass es das SameSide Strict tatsächlich Probleme macht mit single sign-on Systeme oder wenn irgendwie der Benutzer von einem anderen Service über einen Link zu deiner Anwendung kommt, dann werden die Cookies so manchmal nicht mitgeschickt, was für sowas wie Authentifizierung wirklich doof ist. Deswegen wenn man diesen Schutzmechanismus für so eine Anwendung einschalten möchte, sollte man an der Stelle lieber SameSide Lax nehmen. Das habe ich mir gemerkt. Ich muss genau den Unterschied zwischen den beiden jedes Mal, wenn ich es entscheide, wieder nachschauen, was der genaue Unterschied ist. Aber das… diese Regel habe ich mir dann gemerkt. Man muss natürlich immer noch schauen, ob der Schutz also an der Stelle ausreichend ist und man wirklich davon ausgehen kann, dass alle Benutzer so moderne Browser haben. Aber es hat mir einfach so ein bisschen Hoffnung gegeben, dass wir in der Zukunft so nicht mehr so diese zum Teil komplexen CSRF Logik in einer eigenen Anwendung schreiben kann. Das ist tatsächlich eine Aufgabe, die unser Browser schon längst hätte machen müssen und jetzt kann der das inzwischen. Und ich habe mich auch gefreut, dass weil wir das, auch wenn wir für alte Browser noch so Protection einbauen, dass wir das jetzt zusätzlich dazu einschalten können, als ein zusätzlicher Schutz. Genau, das hat mich gefreut.

Sebastian: Wir haben dieses Jahr für einen Kunden eine Cluster-Migration durchgeführt und dieser Cluster erzeugt für Geräte des Kunden Zertifikate. Die Geräte holen die sich beim Cluster ab. Und in diesen Zertifikaten ist auch ein OCSP Responder eingetragen. Die Geräte verwenden diesen dann um zu validieren, ob das Zertifikat auch wirklich von der eigenen Zertifikatsautorität ausgestellt wurde. Circa eine Woche nach dieser Migration kamen dann einige hundert Support Anrufe ein, denn die Geräte der Kunden konnten sich nicht verbinden. In unseren Logs sind keine Fehler aufgetaucht, das Monitoring war auch okay und es hat sich nur um eine ganz bestimmte Untergruppe dieser Geräte gehandelt. Das war halt auch nur aus einem bestimmten Land und durch diese Besonderheit muss das also irgendwie am Kunden liegen oder an einer Besonderheit beim Kunden. Ja, dank der Daten vom Support konnte auch eingegrenzt werden, dass es sich um Mobilfunkprovider und Android handelt, die da Probleme gemacht haben. Aber auch nicht alle, es gab viele erfolgreiche, aber einige halt nicht. Die nicht erfolgreichen hatten halt diese Besonderheit. Es wurden also Handyhotspots eingesetzt vom Kunden, damit sein Gerät sich mit dem Internet verbindet. Ja, da Debugging hat sich äußerst schwierig herausgestellt, da das alles auch über die wacklige Mobilfunkverbindung von statten ging. Wir wären gerne zum Kunden gefahren irgendwann, allerdings war das durch Corona dann auch nicht drin. Das musste also alles irgendwie remote organisiert werden. Ja, am Ende stellte sich raus, dass es der OCSP Request war. Das Zertifikat wurde übertragen, das fand über https statt, aber der OCSP Request ist der dann über http. Und über diesen Android Hotspot hat das halt nicht funktioniert. Und das auch nur über LTE, wenn man einen schlechteren Empfang hatte oder nur eine 2G oder 3G Verbindung hatte, aus welchen Gründen auch immer, dann hat es funktioniert. Das sind also alles Konstellationen, die den Request beeinflusst haben. Der Mobilfunkprovider hat halt den Request als schädlich eingestuft, da er unverschlüsselt ist und hat versucht seinen Kunden damit zu beschützen. Das wir das innerhalb von wenigen Tagen rausgefunden haben, war auch nur durch Hilfe des Mobilfunkproviders möglich. Der ist auch recht schnell aktiv geworden, was vermutlich daran lag, dass diese interne Netzoptimierung zeitlich mit unserer Cluster-Migration zusammenfiel. Der Fix war dann, dass unsere IPs beim Mobilfunkprovider freigeschaltet wurden sind, was natürlich keine nachhaltige Lösung ist. Ich habe auf jeden Fall gelernt, dass man Security den anderen OSI Layern überlassen sollte.

Till: Ja hi, ich bin Till. Ich bin Softwareentwickler bei INNOQ. Und was ich in den letzten Jahren schon fast gelernt habe, was für mich eine wahnsinnig wichtige Erfahrung war, dass es sowas wie die intelligent tracking protection in Safari gibt. Das ist etwas, was meines Wissens nach Apple vor einigen Jahren angefangen hat einzuführen und vor allem dazu führt, dass zum Beispiel Cookies, wenn man ein IFrame öffnet der auf eine fremde Domain zeigt, was dafür sorgt, dass diese Cookies nicht mehr mitgeschickt werden, weil man damit ja logischerweise User ausspionieren kann, wenn man das böse betreibt. Und Apple hat dafür ja dann eigentlich eine gute Motivation gehabt das einzuführen. Also ich als User finde das natürlich toll, wenn ich einfach irgendwelche Cookies sehe, dass da alle möglichen Request drangeklebt werden. Aber ich als jemand, der sich auch für Architektur von verteilten Systemen und für das Thema Frontintegration ganz besonders interessiert, findet das jetzt keine so tolle Nachricht, weil das Problem da natürlich ist, dass mir IFrame als Integrationsmöglichkeit so ein bisschen schwächer vorkommt, wenn ich plötzlich keine Dinge mehr integrieren kann, die auf anderen Domänen liegen. Das heißt das ist etwas, was uns glaube ich auch als Firma immer Mal wieder ein bisschen beschäftigt hat, wo es sehr viele Diskussionen gab und wo mich sozusagen der Stand und die Daumenschrauben, die Apple und ich glaube mittlerweile auch Google, da immer weiter anziehen, immer wieder interessieren. Was ich in dem Kontext weiß ist, dass es eine API gibt, die Storage Access API, mittlerweile auch schon in relativ vielen Browsern unterstützt wird, die einen sozusagen erlaubt per JavaScript diese Restriktion zu umgehen. Also in einem IFrame den Zugriff auf Cookie und Tracking Daten letzten Endes anzufragen und den IFrame dann in die Lage versetzten diese Information doch wieder mit zu versenden. Aber ja, mittlerweile sieht der Browsersupport glaube ich auch ganz gut aus. In der Zeit, wo es diese API noch nicht in jeden Browser gab, war das aber eine ganz schöne Wildwest Erfahrung aus meiner Sicht, weil man halt tatsächlich einfach das Problem hatte, dass man früher IFrames verwendet hatte um Fremdinhalte zu integrieren, und zwar authentifiziert zu integrieren und dass das plötzlich einfach von heute auf morgen nicht mehr ging. Also das hat meine Welt ziemlich erschüttert muss ich ehrlich sagen.