Browser Security

Lisa Hallo und herzlich willkommen zu einer neuen Episode vom INNOQ’s Security Podcast. Heute wollen Christoph und ich über die Sicherheitsmechanismen, die von Browsern bereitgestellt werden, sprechen. Hallo, Christoph!

Christoph Hallo, Lisa!

Lisa Ich fange immer gerne damit an zu fragen, warum wir überhaupt über das Thema sprechen wollen. Gibt es da einen konkreten Vorfall oder einen konkreten Grund für?

Christoph Ja und nein. Es gibt zwei konkrete Vorfälle, die so ein bisschen, aber mehr zufällig gekommen sind. Normalerweise passiert uns das ja immer, dass die konkreten Vorfälle nach der Aufnahme der Sendung noch mal kommen. Diesmal kommen sie gerade passend rein, aber geplant hatten wir das schon ein bisschen länger oder ich hatte das schon ein bisschen länger auf der Liste. Aber warum wollen wir darüber sprechen? Erst einmal warum ist das schon länger auf der Liste? Der Browser ist ja eine der dominanten Plattformen für Applikationen, vor allem auf dem Desktop. Bei dem Mobiltelefon sieht das ein bisschen anders aus. Bei Android und iOS sind das typischerweise native Applikationen, die man aus dem App Store bekommt. Aber der normale Desktop, da kann man ganz viel mit dem Browser machen als Applikationsplattform. Es gibt ganz viele Arbeitsplätze, wo man den Computer nur dafür braucht, dass man mit dem Browser interagiert und alle Applikationen darüber laufen. Ich meine, das ist ja auch unser tägliches Geschäft. Wir machen beide ja auch Webentwicklung und machen solche Applikationen. Und das hat auch eine Menge Vorteile, wenn man das macht in Sachen Deployment, dass man das zentral machen kann. Kompatibilität: man braucht nicht irgendwelche alten Windows Versionen rückwärts kompatibel machen. Und hat dann das Problem wie in der öffentlichen Verwaltung, dass man noch extra an Microsoft zahlen muss, um seine alte Windows Version noch supportet zu bekommen. Hat ganz viele Vorteile. Aber ja, wenn er so dominant ist, dann muss man sich natürlich auch um die Security kümmern. So, und der aktuelle Anlass sind zwei Meldungen aus der letzten Zeit. Einmal ist Hot Pixels, das ist so ein Seitenkanal Angriff. Ähnlich wie Spectre, Meltdown und Co. allerdings nicht auf die CPU, sondern auf die GPU. Und warum ist das jetzt interessant für den Browser? Der Angriff ist so gestaltet, dass man per JavaScript Bilder auslesen kann, an die man sonst nicht rankommen könnte. Ist jetzt nicht ganz so gefährlich, weil da müssen auch so ein paar Umstände gegeben sein, die jetzt nicht so der Normalfall sind. Aber das betrifft das Sicherheitsmodell des Browsers. Da kommen wir später noch mal dazu. Das hat nachdem Meltdown und Spectre als so die ersten Hardware Seitenkanal Angriffe gekommen sind, sehr stark geändert gegenüber dem, wie es vorher war. Und das andere ist so eine aktuelle Meldung, dass eine ganze Reihe von Extensions für den Chrome Browser nicht sicher waren bzw. mit Malware Code infiziert sind. Und da war die Installationsbasis auch recht groß über 80 Millionen. Die Meldung können wir dann mal verlinken in den Shownotes. Was natürlich auch ein großes Risiko ist. Das ist auch noch mal ein Thema. Es ist ja nicht nur der Browser selbst, sondern auch diese so genannten Extensions oder Plugins, die man da nutzen kann und vielleicht nicht immer nutzen sollte.

Lisa Hast du schon vielleicht ein Tipp, wie man identifizieren kann, ob es sich um sicheres Plugin handelt oder nicht? Oder kann man das eigentlich gar nicht so sehen?

Christoph Der einfache Tipp ist, wenn es nicht installiert ist, ist es sicher. Aber sonst wird es schwierig. Die Hersteller für den Chrome von Google, die schauen natürlich schon drauf. Aber das sind so viele und da gibt es ja auch Techniken, das jetzt zu verstecken, dass das nicht sofort eindeutig ist, dass es Malware ist, normalerweise bekommen die so eine große Installationsbasis ja auch nur, weil die auch eine sinnvolle Funktion haben und die dann versteckt sind. Da haben wir wieder das Vertrauensproblem. Und das ist ja auch eigentlich ein Grund, warum wir darüber sprechen. Also ich hatte gesagt große Anwendungsplattformen, das ist jetzt Windows, auch Mac OS ist es wahrscheinlich auch und Mobiltelefone, iOS, Android ist das auch. Warum müssen wir denn nochmal speziell dann darüber sprechen? Und warum sprechen wir nicht gerade über die anderen? Erstens klar, wir machen beide Webentwicklung bietet sich das an, aber andererseits gibt es auch einen großen qualitativen Unterschied. Wahrscheinlich haben wir beide heute schon so viele Webseiten besucht, dass wir aus 50, 100 verschiedenen Quellen irgendwelche Ressourcen geladen haben, darunter auch jede Menge JavaScript Code, der dann einfach ausgeführt wird. Wenn man das jetzt vergleichen würde, wir würden uns täglich nicht 50 neue Applikationen installieren auf dem Desktop und wahrscheinlich auch nicht auf dem Mobiltelefon. Wahrscheinlich ist die größte Codeänderung an deinem Desktop-Rechner das Chrome und Firefox Update, was man immer so relativ regelmäßig bekommt, weil ja auch in dem Browser immer wieder neue Lücken entdeckt werden. Aber das Plattform Modell des Browsers sieht so aus, dass ich meine Applikation sozusagen täglich neu lade, neue Versionen lade, geändertes JavaScript oder so und wenn die jetzt mit vollen Rechten auf deinem System was machen können, das war ja das Sicherheits-Horrorszenario, was man sich überhaupt so vorstellen kann, deshalb müssen wir da auch mal schauen, wie der Browser verhindert, dass der ganze Code, der aus dem Netz geladen wird, nicht zu viel Unsinn anstellen kann. Das ist ja schon ein Unterschied, wie eine Applikation, die du einmal installiert hast und die dann erst mal so bleibt und die hoffentlich nicht infiziert war, als du sie installiert hast.

Lisa Du hast es schon angesprochen, der Browser tut ja schon Dinge für uns, dass wir nicht einfach ins offene Messer rennen bei all diesen unverifizierten, vielleicht nicht vertrauenswürdigen Quellen, die wir da dauernd runterladen, das ganze JavaScript, was wir tun. Also wir haben ja nicht automatisch jeden Tag auch 50 bis 100 Viren, nur weil wir von 50 bis 100 Quellen was runtergeladen haben bzw. hoffe ich das. Also was tut denn der Browser jetzt schon für uns, was uns hilft, was er vielleicht auch tut, ohne dass wir das wirklich mitbekommen?

Christoph Ja, also das ist sozusagen der Schutz für den Endnutzer. Sozusagen als Anwender den ganzen Tag bedient, wie wird der denn geschützt dafür, dass der Rechner nicht völlig infiziert ist? Da gibt es verschiedene Mechanismen. Zu einmal ist das so, dass dieser ganze JavaScript Code ja nicht so viel kann wie der native Code. Der hat keinen Zugriff auf das Filesystem oder überhaupt auch außerhalb des Browsers oder gar auch auf andere Browser Tabs oder Fenster sollte der eigentlich keinen Zugriff haben. Das wird gemacht, indem ein ganz starkes Sandboxing eingesetzt wird. Erst mal welche APIs das JavaScript im Browser überhaupt bekommt. Wenn es keine API gibt für den Filesystem Zugriff, dann kann JavaScript das auch nicht. Und andererseits aber auch der ganze JavaScript Prozess komplett in der Sandbox läuft. Das heißt, könnte JavaScript jetzt irgendeinen Fehler ausnutzen in den Browser selbst, um an native APIs heranzukommen zum Beispiel um ein Buffer Overflow auszulösen und beliebige Funktionen auszuführen, dann funktioniert das auch nicht sofort, weil der ganze Prozess liegt in der Sandbox. Also es ist nicht nur die fehlenden APIs, auch alle möglichen Funktionen sind auch gar nicht in dem Prozess verfügbar. Das heißt, auch wenn er da ausbrechen kann, erst mal aus der Stufe eins der Sandbox, den fehlenden APIs oder so, heißt das nicht, dass er dann weiterkommt. Und Sandboxing gibt es schon sehr lange, auch schon bevor die Browser so in der Form gab. Aber die Browser haben ganz viel dazu beigetragen, dass sich das sehr viel weiterentwickelt hat. Also wie man so eine Sandbox baut. Auf Linux gibt das Secure API. Damit kann man im Prozess eingrenzen, was der für Aufruf an das Betriebssystem überhaupt machen kann. Und da kann ich zum Beispiel auch sagen, er kann jetzt nicht auf Files zugreifen, dann werden die jeweils in ihren eigenen Prozess gebracht, eigener Speicherbereich. Gibt es ganz viele Mechanismen. Ja, und das schützt uns erst mal davor, dass JavaScript überhaupt irgendwelche Dinge tun kann, die uns nicht so zugutekommen, sondern erst mal nur im Kontext der geladenen Seite, der geladenen App irgendwie was tun kann. Dann gibt es aber noch mehr Sachen. Das zweite ist, dass die Browser uns helfen, alles über TLS, also verschlüsselt zu übertragen. Das war ja auch nicht immer so. Ich meine, das ist gekommen, nachdem Google gemerkt hat, dass sie selber gehackt wurden. Einmal von den Chinesen und einmal von den Snowden-Enthüllungen, das alles überwacht wird. Da haben die das ja stark vorangetrieben. Google aber auch Mozilla mit dem Firefox Browser, dass alles nur noch über TLS übertragen wird. Dadurch sind dann so Sachen entstanden wie jetzt Let’s Encyrpt, dass man Zertifikate, die man dafür braucht, auch preiswert bekommt. Also das Zertifikat selber ist erst mal umsonst, aber klar kostet mich das was, die Infrastruktur dafür auszusetzen, die Prozesse in Gang zu bringen, dass ich immer auch aktuelle Zertifikat habe. Das ist erst mal gefördert, dass ist indirekt, aber das andere ist die UX, die man hat. Wenn man was in die URL Leiste eingibt, zum Beispiel www.innoq.com, dann springt er auf https. Früher hat er http genommen und man musste sozusagen am Server noch mal eine Umleitung auf https machen oder so oder darauf nicht antworten. Heute ist der Standard, dass es https ist. Und auch so Dinge, wie wenn das Zertifikat ausgelaufen ist. Früher war dann: Ist gefährlich, hier klicken zum Weitermachen. Dann hat man natürlich gemerkt, nee, funktioniert alles nicht. Die Leute klicken dann einfach. Heutzutage ist es rot und dann gibt es ein Button Back to Safety oder so, dann kommt man nicht dahin und es ist deutlich schwieriger sozusagen dahin zu kommen, dass man trotzdem auf die Seite kommt obwohl das Zertifikat abgelaufen ist oder sonst ein Fehler hat. Zum Beispiel für eine andere Seite ist, muss man hier Fehlerdetails anklicken in irgendeiner Form und dann sich das Zertifikat anschauen und dann ist irgendwo das ganz klein ja trotzdem. Und das hilft dann. Der normale Nutzer drückt sozusagen den größten Button zuerst. Leute sind früher dann weitergegangen und heutzutage ist es…

Lisa Da kommt auch so ein Fenster, oder? Erst ist mir egal, dann kommt noch eins und dann muss ich noch mal sagen, dass ich da wirklich hin möchte.

Christoph Und auch ganz klein, der ist mir egal Button. Ganz groß Back to Safety. Das hat sich bewährt. Genau, das hat man dann gemacht. Also während früher die UX so ein bisschen in der Browserleiste war, da war er schön grün oder rot, aber darauf hat keiner geachtet. Jetzt ist zum Beispiel im Chrome, den ich gerade benutzte, ist da zwar noch ein Schloss da, aber in den grauen Farben, wie der Rest der UI ist, würde mir das wahrscheinlich gar nicht sofort auffallen, wenn das fehlen würde. Aber wie gesagt, dass es der Standard ist, ist es besser und dass es schwieriger ist, auf Seiten zu kommen, die kein TLS unterstützen, ist das auch ganz gut. Und wenn man dann doch auf Seiten ist, wo kein TLS unterstützt wird, dann gibt es noch so Mechanismen, dass man zum Beispiel beim Formular, wo ein Passwort Feld drin ist, dass man dann direkt bei dem Formular mit seinem Overlay gewarnt wird, dass die Daten unverschlüsselt übertragen werden. Und ich meine, die wollen es auch komplett ausbauen, dass das dann erst mal gar nicht geht.

Lisa Ist das wirklich nur bei einem Passwort Feld? Ich hatte das Gefühl, dass ist echt bei jedem Formular.

Christoph Kann sein, dass das sogar bei allen Formularen ist. Ich treibe mich so selten auf Seiten rum, die kein TLS haben und gibt da auch noch Daten ein, deshalb bin ich da gar nicht auf dem aktuellsten Stand. Das hat mit den Passwörtern angefangen. Kann sein, dass jetzt einfach bei jedem Form, also überall wo Daten übertragen werden, das jetzt gemacht wird. Wäre auch der richtige Schritt. Das wird immer so schrittweise eingeführt, solche Sachen, damit die User nicht komplett überfordert sind, wenn sich alles auf einmal ändert. Genau, und es treten natürlich auch noch ein paar andere Sachen in Kraft. Bei den Cookies werden nicht alle übertragen, wenn es nicht TLS ist, aber Cookies kommen wir später noch mal drauf. Erzählen wir dann noch mal wie das im Detail ist. Und da gibt es noch so ein paar mehr Sachen. Wir hatten im Vorgespräch darüber gesprochen, dass du noch nie auf seiner Seite warst, wo ganz große Warnung ist, dass da Malware verteilt wird. Aber alle Browser haben so eine Funktion, dass die warnen, wenn bekannt ist, dass die Seite irgendwelche Trojaner ausliefert, dann wird ganz groß gewarnt davor. Ist auch ein schöner roter Hintergrund.

Lisa Nachdem du das gesagt hast, habe ich echt Angst, dass ich es einfach noch nicht mitbekommen habe. Aber du meintest ja, dass das extrem auffällig ist.

Christoph Das ist wie bei den TLS Warnungen, also sollte das klar sein. Und dann sollen die Leute diese Seiten dann nicht mehr besuchen. Gleichzeitig hat das natürlich ein bisschen ein Problem, weil um das rauszukriegen, gibt es keine statische Liste. Von Google gibt es zum Beispiel die Safe Browsing API, da kann man das anfragen. Und das heißt auch, eigentlich bekommen die mit, wo man surft, weil jede Seite dann auch da hingeschickt wird und vorher gefragt wird, ist das denn sicher? Muss man den Herstellern Apple, Google und Microsoft vertrauen, dass die Daten dann nicht erstens mit einem korreliert werden in irgendeiner Form, dass man nicht identifiziert wird und dass die dann auch nicht gespeichert werden. Ist so ein bisschen zweischneidiges Schwert. Für uns beide vielleicht, die sicherheitsaffiner sind als andere, ist das vielleicht besser, wenn wir das vielleicht nicht benutzen oder ein Browser, der das vielleicht ausgeschaltet hat, wo solche Sachen dann nicht mehr benutzt werden. Sollte man aber nicht seinen Schwiegereltern empfehlen sowas zu machen. Da ist es vielleicht besser, dass die Seiten, die besucht werden, da alle exponiert werden.

Lisa Aber das macht der auch automatisch. Ich muss nichts einstellen, ich muss das aktiv ausstellen, damit das auch aufhört.

Christoph Das muss aktiv ausgestellt werden und ich weiß gar nicht, ob man es im Chrome noch aktiv ausstellen kann. Im Firefox gibt es sowas dabei und es gibt ja diese Ungoogled-chromium wo alles raus ist. Das ist dann auch so, aber wie gesagt, schwieriges Thema zu sagen, vertraue ich denn jetzt in Sachen Privatsphäre oder nicht? Oder verzichte ich darauf? Es kann ja durchaus sein, dass eine Seite, die ich sonst immer besuche, gehackt wird und dann da Malware ausgeliefert wird, ohne dass ich das weiß. Das sieht man dann nicht unbedingt sofort. Bei uns ist es vielleicht noch so okay, wenn wir dann ein Download bekommen mit einer Exceldatei, dann werden wir vielleicht auch stutzig, weil es den sonst von der Seite nicht gibt. Aber ja, das ist dann schwierig. Also wenn wir daran denken, zum Beispiel wollen wir dann eine Extension oder was anderes runterladen und die wurde dann ersetzt, dann wird es hakelig. Und wenn man dann gewarnt werden würde, ist das vielleicht auch nicht immer schlecht. Also ich tu mich schwer, da eine klare Empfehlung auszusprechen. Also einen nicht so sicherheitsaffinen Nutzer würde ich mal sagen, das ist eine gute Sache. Bei anderen, so wie bei uns beiden, würde ich eher sagen, da muss man mal aufpassen. Wobei ich sagen muss, ich habe es auch angeschaltet und war aber auch nie groß auf so einer Seite, es sei denn irgendwo kam mal die Meldung und ich bin da hin aus Neugier dann in frischen System oder eine VM, um zu schauen, was da los ist. Aber sonst eigentlich nicht.

Lisa Aber der sendet schon wirklich jede Seite, also wenn ich jetzt hier mit dir den Podcast aufnehme, musste ich auch auf eine Seite navigieren, also hat er dann auch diese Seite gescannt wahrscheinlich.

Christoph Hat er wahrscheinlich gemacht. Ich weiß nicht, wie lange er das cacht, also wie viel Millionen Browser sind gleichzeitig aktiv und machen immer irgendwelche Aufrufe. Ich glaube nicht, dass er es jetzt wirklich bei jedem Aufruf macht, sondern wahrscheinlich auch irgendeine Cache Verweildauer hat und sagt, letzte Prüfung war an Zeitpunkt X und dann brauche ich jetzt nicht schauen. Aber das weiß ich im Detail jetzt nicht. Aber dieses Safe Browsing API von Google ist eine öffentliche Ressource, da könnte man das nachschauen, vielleicht verlinken wir das in den Shownotes, dann können die interessierten Hörer:innen da mal selber nachschauen. Aber wo wir gerade bei Privatsphäre waren, da tun die Browser Hersteller ja auch was. Das Browser Fingerprinting, also feststellen, wie unique ist dein Browser und das ist oft erstaunlich hoch. Das hängt dann so ab an dem User Agent. Da steht dann alles mögliche drin, was du als Extensions hast oder welche Font du installiert hast kann man per JavaScript abfragen oder so bestimmte Details über dein Canvas Objekt in 2D und 3D, was die alle können und welches Timing die haben. Da gibt es ganz viele Möglichkeiten. Da gibt es auch so Textseiten und dann ist das immer erschreckend, wie wenig sozusagen eine ähnliche bis gleiche Konfiguration habe, die man nicht unterscheiden kann. So was wird ja auch versucht immer mehr auszubauen, indem man zum Beispiel Antworten erhält mit Standard Werten und nicht mit den echten Werten oder dass der User Agent auch bei einigen Browsern auch gar nicht mehr aktualisiert wird oder Extensions nicht enthalten sind usw. Also dass man da ein bisschen anonymisiert wird. Das ist vielleicht auch nicht so schlecht. Google hat wahrscheinlich andere Möglichkeiten einen zu erkennen, um einem die Werbung unterzujubeln, aber das wird auch abgestellt nach und nach. Genau, das sind so die Sachen, die man für den Nutzer erst mal hauptsächlich tut von Seiten der Browser Hersteller. Wie gesagt, es gibt noch diese Extensions auf den Marketplaces. Das ist ein bisschen schwierig. Da gelangen immer wieder welche durch, auch wenn da eine gewisse Art von Kontrolle ist darüber bei User Bewertungen. Und ich glaube auch zum Teil über automatisierte Scans, damit man so ganz plumpe Sachen an Malware direkt erkennt. Aber es passiert immer wieder. Das müsste man wahrscheinlich eher manuell prüfen in vielen Fällen und dazu ist die Power auch nicht da und auch wahrscheinlich nicht der Wille, so viel Geld auszugeben. Da muss man ein bisschen aufpassen. Extensions können gut sein, auch die Sicherheit erhöhen, zum Beispiel wenn man Adblocker benutzt oder JavaScript Blocker. In gewisser Weise können auch die Sicherheit erhöhen, aber man sollte nicht einfach beliebig irgendwo was installieren. Und da bietet sich es auch an, dass man zum Beispiel wenn man einen Arbeitsplatz Rechner hat, wenn die zentral gemanagt sind und alles geht wirklich über den Browser, dass man solche Extensions dann zentral managt und nicht den User das überlässt, die zu installieren und dann sagt, vielleicht X sind erlaubt, Adblocker ist vielleicht erlaubt, aber alle anderen komischen Dinger, da lässt man mal die Finger von. Und noch ein letzter Mechanismus, der noch da ist, ist das Auto Update. Alle Browser haben und waren führend darin, auto Update Funktionen zu bringen. Hat jetzt viel Software, aber die Browser waren da relativ stark, weil es nutzt nichts, wenn der Browser selber ein Problem hat, das ausgenutzt werden kann und man bekommt kein Update dafür.

Lisa Ja, das stimmt. Es war nicht wenig, muss man schon mal sagen. Der Browser tut schon ziemlich viel, dass Endnutzer:innen sicher sind, würde ich jetzt erst mal sagen. Klar, es gibt auch Probleme oder Manches ist nicht so einfach, aber wir möchten bestimmt noch darüber sprechen, was denn wir Entwickler:innen noch für Möglichkeiten haben. Also was können wir nutzen? Was sollten wir nutzen? Was für Möglichkeiten bieten Browser uns zusätzlich zu den Dingen, die für Endnutzer:innen sowieso schon aktiv sind?

Christoph Ja, da gibt es eine ganze Menge an Möglichkeiten, die sich auch ständig ändern, die zum Teil auch überlappend sind oder auch widersprüchlich. Aber das hat so ein bisschen mit der Geschichte zu tun. Man hat eigentlich am Anfang gar kein Sicherheitsmodell für Browser gehabt in der Form die heutzutage nötig sind, weil als das World Wide Web neu war und so mit dem ersten Browser, da hat man gar nicht so dran gedacht, dass die Sicherheitsmodelle, die vorher bestanden waren, vielleicht so was wie hier Time sharing auf so einem Großrechner oder so, wo man die Nutzer voneinander isoliert, aber dieses Modell, dass man beliebigen Content und dann runter auch ausführbaren Code sich aus dem Internet lädt und dann lokal ausführt, das war überhaupt kein Modell. Besonders weil JavaScript gab es ja am Anfang auch noch gar nicht. Da hat man ja noch relativ statischen Content gehabt, also Bilder, Text, Tabellen und Links. Da war das vielleicht auch noch nicht so das Problem, aber dann kam ja relativ schnell JavaScript und das ist ja auch in so ein drei Wochen Stand oder so entstanden und in den Browser gekommen. Da hat man sich wahrscheinlich auch noch nicht so viele Gedanken darüber gemacht und dann sind so nach und nach Sicherheitsrisiken oder richtige Sicherheitslücken aufgepoppt, um die man sich dann gekümmert hat. Und meistens hat man das dann so ein bisschen zu gespachtelt und sich nicht wirklich Gedanken darüber gemacht, wie das Sicherheitsmodell des Browsers eigentlich aussehen müsste oder der Web Plattform aussehen müsste. Das ist erst entstanden, seit es diesen Begriff der Web Plattform eigentlich gibt und das so eine dominierende Plattform auch geworden ist, dass man dann ein bisschen systematischer dran geht, wie man das Sicherheitsmodell entwirft. Und vielleicht können wir mal in die Geschichte gehen, wie so eins der ersten Dinge, die so entstanden sind, das ist das berühmte Cross Site Scripting. Wir verweisen da noch mal vielleicht auf die OWASP Folge, das auch ein ganz komischen Namen hat für das, wie es heute gebraucht wird. Das war nämlich früher was anderes. Und dieses früher, da kommen wir jetzt mal drauf. Es ist nämlich so, es gab JavaScript und Webseiten und die konnten so ein bisschen an dem Dobn manipulieren, also so viel konnten die noch nicht, dass schon nicht aus File System und sowas zugreifen durften und auf viele andere Dinge. Das war schon immer klar. Das war sozusagen die Webseite irgendwie ein bisschen dynamischer zu machen, aber nur innerhalb der Webseite. So, und dann gab es auch noch tolle Frames und iFrames, um seine Seiten dann so ein bisschen besser zu gestalten. Früher gab es immer so links einen Frame für die Navigation oder oben eins, was so fest stand und dann ein großes Hauptframe zum Beispiel. Braucht man heute wahrscheinlich alles nicht, die optische Gestaltung mit CSS ist auch vielleicht ein bisschen einfacher, aber gut. Also es gab Frames, es gibt JavaScript und es gibt Webseiten. Und jetzt war es so, dass man mit JavaScript von einem Frame auf das andere Frame, auf ein Frame gegenüber zugreifen konnte. Deshalb Cross Site Scripting. In so einem iFrame kann ja eine ganz andere Seite drin sein als in einer Hauptseite, die dieses iFrame embedded hat. So, und wenn ich da auf die Daten zugreifen kann, dann kann ich vielleicht auch da Sachen auslösen oder Authentifizierungsinformationen klauen oder ähnliches über Seiten hinweg. Und das war natürlich ganz schlecht und deshalb kam man dann auf die Same Origin Policy, dürfte eigentlich jedem Webentwickler, Webentwicklerin auch bekannt sein schon mal gehört haben. Das besagt ja, dass ich mit meinem JavaScript nur auf Sachen zugreifen kann, die von der selben Origin kommen. Und Origin ist in dem Fall das Triple Protokoll, also https Host, Domain Name und Port. Und wenn es woanders her ausgeliefert wurde, dann kann ich nicht untereinander darauf zugreifen. Das heißt, wenn das iFrame eine andere Seite war, dann konnte das sozusagen nicht mehr auf das andere Frame oder die Hauptseite zugreifen und sowas machen und dann hätte man kein Cross Site Scripting mehr. Heute, wie gesagt, hat das eine ganz andere Bedeutung, ist das Code Injection in die Hauptseite. Aber das war der Begriff dafür und sozusagen die Entstehung der Same Origin Policy. Aber das war nicht ganz so hart dabei, weil an der Seite kann ich ein Bild einbetten, sagen wir mal von innoq.com, können wir ein Bild einbetten von google.com oder von Microsoft oder Bing oder von Pixabay, kann man einfach Image und der Link kann darauf gehen. Das heißt, die Ressourcen, die aus der Seite kommen, können von verschiedenen Seiten geladen werden, sogar beim Scripting. Ich kann JavaScript, kann ich von J Query laden und meine Seite wurde trotzdem von INNOQ ausgeliefert. Und damit sie die nicht vermischen, sind das sogenannte opake Ressourcen. Also wenn ich so ein Bild lade von anderen Seite, dann kann ich nicht das in den Canvas stecken und da auf die Pixel zugreifen zum Beispiel, weil das ist dann opaque. Die sind dann so ein bisschen getrennt voneinander und haben keinen gegenseitigen Zugriff. Das war pragmatisch, ist aber, sehen wir vielleicht später noch auch an einigen Stellen, problematisch. Heutzutage wird man das nicht mehr so machen. Da wird man das ganz klar sagen: Es gibt die Same Origin Policy und die wird eingehalten und hat nicht so Sonderfälle, weil die Sonderfälle machen so in der Weiterentwicklung der Sicherheitsmechanismen dann immer Probleme und dann muss man die immer berücksichtigen. Gibt es immer noch. Image kann ich von beliebig einbetten und es wird erst mal angezeigt. Ich habe zwar keinen programmatischen Zugriff, aber kann ich erst mal einbetten, genauso für Scripts. Also das ist so eine der Geschichten, wie man so drauf kommt, wir brauchen Sicherheitsmechanismen. Erstens keine Erfahrung dafür, das gab es vorher nicht andererseits man wusste auch nicht, wie sich das entwickelt, deshalb so ein bisschen zusammen gekittet dafür, so.

Lisa Und wie spielt jetzt CORS mit rein? Das ist ja so der nächste Begriff, der einem als Webentwickler häufiger um die Ohren fliegt.

Christoph Genau, CORS ist ja die Aufweichung der Same Origin Policy. Also genau, wo man so sieht, man hat was schnell zusammen gekittet und weiß jetzt aber nicht in die eine Richtung, wir machen sicherer in die andere Richtung, das soll aber auch noch für die Entwickler ordentlich sein. Wo geht es hin? Und CORS, also Cross Origin Resource Sharing, sagt von wo darf ich denn Ressourcen auf meiner Seite laden? Und eigentlich müsste es ja sein, du darfst Same Origin Policy machen, außer diese opaken Ressourcen, die darfst du überall laden, aber in JavaScript von meiner Seite darf zum Beispiel nicht auf eine andere Seite zugreifen mit so einem XML, http Request, Ajax Request oder heutzutage mit Fetch, sondern nur wieder auf dieselbe Origin. Und das wird aufgeweicht mit dieser Cross-Origin Ressource Sharing. Es wird gesteuert, über Header, die der Server mit sendet. Und da kann ich dann so einen Allow Header zum Beispiel machen, dass ich sage: Sternchen Wildcard heißt, ich kann von allen Ressourcen geladen werden oder ich gebe eine bestimmte Domain an, von der ich geladen werden kann. Und dann gibt es relativ komplizierte Mechanismen, wie das geprüft wird, weil es gibt solche simple Requests, die müssen nur ein paar bestimmte Bedingungen erfüllen, zum Beispiel ein einfacher get Request, wo auch nicht viel an den Headern manipuliert wird. Der geht direkt durch. Und bei anderen gibt es einen sogenannten Preflight Request. Da wird erst mal geprüft mit einem Option Request, dann sagt der Browser, der nächste Request, der heißt dann Allow Origin Request und dann noch ein weiterer Punkt, wo dann die Details spezifiziert werden. Der fragt dann an, sozusagen würde der nächste Request durchgehen, ja oder nein? Wird das erlaubt oder nicht? Und da kann man dann sehr fein Granulat eigentlich steuern, welche Ressourcen dann da geladen werden und dann kann man da so ein bisschen umgeben und muss nicht alles unter der einen Domäne dann haben, sondern kann dann sagen: Ich kann von überall geladen werden. Was natürlich auch ein gewisses Problem ist, weil wenn ein JavaScript, was irgendwie injiziert wurde, also Cross Site Scripting in der aktuellen Verwendung oder ich muss es noch nicht mal per Cross Scripting gemacht haben, ich ziehe JavaScript vom CDN, da wurde mir was untergeschoben. Und das soll jetzt Daten aus dem Browser irgendwo anders hin senden, dann kann natürlich ein Angreifer auch entsprechende CORS, das auf seinem Server setzen und sagt, von mir aus, hier ist alles erlaubt. Also ich mache ja eine Wildcard. Ist jetzt eigentlich kein Sicherheitsmechanismen, sondern ist eher einer, der Sicherheitsmechanismen aufweicht, um den Entwickler:innen Möglichkeiten zu geben, diese ganz strenge Policy so ein bisschen zu umgehen, weiß ich auch nicht, ob man das heute noch in der Form machen würde. Ja, kompliziertes Thema, kann man ganzen Podcast drüber machen. Wichtig ist halt, dass Ressourcen auch von woanders geladen werden können, wenn die Header entsprechend gesetzt werden. Interessanterweise du kannst nur Wildcard geben oder eine Domain. Das heißt, du musst es immer dynamisch entscheiden. Du kannst nicht sagen, ich habe jetzt fünf Domains, von denen ich geladen werde, das funktioniert so erst mal nicht.

Lisa Das war jetzt die Geschichte und die Aufweichung der geschichtlichen Ereignisse. Was sind denn noch so aktuelle Security Mechanismen, die man vielleicht auf dem Schirm haben sollte? Du hattest eben schon Header angesprochen. Ich glaube, da gibt es ja noch mehr Header als nur die, die schon angesprochen wurden.

Christoph Ja, viele der Mechanismen, die die Web-Entwickler:innen in der Hand haben, sind halt Header gesteuert. Ich gebe meiner Seite Informationen mit, die landen dann im Browser und der wertet die aus, um bestimmte Sachen halt zu erlauben, wie bei CORS bzw. um gewisse Dinge wieder einzuschränken, wie bei den meisten anderen Security Headern. Die meisten sind auf der Server Seite. Es gibt aber auch welche vom Browser. Fangen wir mit der Server Seite an, da gibt es Content Security Policy. Hat man bestimmt auch schon mal gehört. Da kann ich meiner Seite mitgeben, von wo dürfen überhaupt weitere Ressourcen geladen werden? Also ist jetzt auf meiner Domäne oder ist es woanders? Und wo dürfen die ausgeführt werden? Die müssen halt extern geladen werden oder dürfen die auch im HTML Code stehen? Also ich könnte im HTML Code einfach ein Script Tag inline machen oder ein DOM Element. Und das könnte ich zum Beispiel dann verbieten, wenn einer zum Beispiel das HTML manipulieren kann durch Cross Scripting oder so was, dann wird das einen gewissen Schutz davor bieten, dass ich sage, das ist nicht erlaubt und das kann ich für ganz viele Ressourcen tun. Diese Content Security Policy ist nicht nur JavaScript, das ist JavaScript, das sind Images, das sind Web Fonts, da sind Texturen für WebGL, Audiodateien, also alles mögliche, was ich an Ressourcen lade, kann ich dann sagen: Nee, wenn das von den nicht angegebenen geladen wird, dann bitte blockiert das. Dann geht meistens die Webanwendungen kaputt, wenn man es blockiert. Deshalb gibt es den Mechanismus, das gibt es auch bei einigen anderen Headern, so ein Report URL oder URI anzugeben, die, wo dann solche violations der Content Security Policy gemeldet werden, wo der dann ein request macht und die man dann sammeln kann. Dann kann man, wenn man es anschaltet, erst mal sehen, wo man noch Bedarf hat, seine Anwendungen ein bisschen besser aufzubauen oder wo welche Ausnahmen noch sind, welches CDN vielleicht neu erlauben muss. Das kann man dann einstellen. Und wenn man keine Reports bekommt eine gewisse Zeit, dann kann man sich vielleicht auch trauen, das sozusagen richtig scharf zu schalten, dass der Browser auch sagt: Ich melde das nicht nur, sondern ich blockiere dann wirklich den Aufruf.

Lisa Und ich kann das Ressourcen Typ abhängig machen. Also ich kann Images von anderen Ressourcen ausladen lassen als das JS zum Beispiel.

Christoph Ja, ich kann so ein Default machen, das ist auch so eine Art best practice, Default, da sag ich Self nur von der Seite, die es ausgeliefert hat, nur von mir selber kann ich Ressourcen laden. Das heißt alles was ich vergessen habe, fliegt erst mal auf und dann sage ich, JavaScript darf, aber auch von CDN XY geladen werden, aber meine Bilder liegen wieder auf dem speziellen CDN für Bilder und meine Web Fonts. Na ja, bei Google hostet man die nicht mehr, da wird man ja abgemahnt, aber da habe ich vielleicht auch noch eine Domäne von, das kann ich dann sozusagen pro Ressourcen Typ einstellen, wo die herkommen, weil die auch unterschiedliche Bedürfnisse haben. Also bei Bildern ist es wahrscheinlich deutlich weniger Security relevant, von wo ich die Bilder lade als wo ich das JavaScript lade. Das ist ja schon ganz gut, dass man das je nach Ressourcen Typ dann unterschiedlich definieren kann. Das ist wichtig. Und eigentlich sollte man immer JavaScript inline ausschalten. Das geht aber mit so manchen SPA Frameworks nicht mehr so leicht, aber das wäre ganz gut, weil das ist oft Inhalt, den kann irgendein Außenstehender leichter irgendwie was reinschmuggeln. Wenn Daten, die der User eingegeben hat, wieder zurück kommen, weil sie waren in der Datenbank, sie werden auf der nächsten Seite gesagt, also Wizard gibt es 1000 Anwendungsmöglichkeiten, wo Daten, die der User eingegeben hat, wieder zurück an den User gespiegelt werden oder auch an andere User. Und wenn ich dann inline verbiete, dann habe ich schon jede Menge Potenzial für so Cross Site Scripting ausgeschaltet.

Lisa Super. Was gibt es noch für Header, Christoph?

Christoph Es gibt noch ein paar. Zum Beispiel X Frame Options. Wir haben vorhin gehört, mit den iFrames oder mit Frames kann es ganz problematisch werden. Auch wenn jetzt mit der Same Origin Policy viel geändert wurde, gibt es aber noch Möglichkeiten, da Schwierigkeiten zu machen. Also wenn ich zum Beispiel so einen Frame von der Seite Full Screen embedde und dann sozusagen was anderes darauf mache oder beim User abfangen und der gar nicht weiß, dass er gar nicht auf der Seite ist, sondern die nur im iFrame geladen wird, dann kann ich das dann verbieten. Dann kann ich dem Browser sagen, ich werde nicht in einem iFrame angezeigt oder in meinem Frame angezeigt, dann macht der Browser das nicht. Oder ich werde nur in einem Frame von meiner eigenen Domain, also Same Site oder Same Origin, da kann ich als Frame angezeigt werden, aber nicht, wenn mich hier eine dritte Partei lädt. Das kann ich steuern. Sollte möglichst immer darauf geschaltet sein, dass man gar nicht angezeigt wird oder nur von welchen Seiten, die man selber ausliefert. Also von Same Site oder Same Origin, dass man sagt, davon kann ich vielleicht eingebettet werden, das gibt es. Da gibt es noch so ein paar Sachen, wo wir sagen in Sachen Transport Sicherheit haben wir immer gesagt, TLS wird enforced von den meisten Browsern bzw. die UX ist so gestaltet, dass man wahrscheinlich eher auf https geschützten Seiten landet. Dazu gibt es auch Header. Da gibt es nämlich die Strict Transport Security HSTS, die sagt, diese Seite wird nur sowieso nur über https aufgerufen. Da kann man dann eine Zeitdauer angeben, wie lange das gültig sein soll. Und das heißt, wenn man erst einmal auf der Seite war, auch auf http wird beim nächsten Mal sozusagen dann gesagt, ja, okay, du bist jetzt immer da. Also bei der ersten Benutzung muss man dem schon vertrauen. Aber es gibt auch solche Listen, die die Browser schon mitbringen von solchen Seiten. Dann kann man sich auch eintragen lassen. Dauert manchmal, wenn man so eine 0815 Seite hat, aber wenn man für eine Bank oder für einen Onlineshop was macht, dann ist vielleicht gut, wenn man sowieso in dieser Liste ist und der Browser diese Seite nie ansteuern wird, auch wenn man explizit http eingibt. Der Nutzer kann daran auch nicht mehr vorbei. Und es gibt ja immer so Sachen wie dann wurde der Link falsch abgedruckt. In der Werbekampagne steht der http Link und die Leute kopieren es einfach raus und für so was hilft das dann, weil dann ist auch wenn du http eingegeben hast, kommst du nur über https raus. Es gibt auch noch welche, die gibt es jetzt aber schon zum Teil nicht mehr, sind zum Teil wieder ausgebaut. Dass man die Public Keys, die benutzt werden, gepinnt hat, weil man sagt, ja, das Zertifikat, da muss folgender Public Key drin sein, sonst bin ich das nicht. Das sollte sozusagen noch auf einer höheren Ebene schützen. Von wegen, dass jemand das falsche Zertifikat machen kann, irgendwie die CA hackt. Gab es ja auch schon, dass für Google falsche Zertifikate ausgestellt wurden, wo das Leute das geschafft haben und sich dann dafür ausgeben können. Aber dann haben sie ja nicht den Public Key in der Hand bzw. den Public Key hätten sie schon, aber die haben den Private Key nicht, also bekommen sie dafür kein passendes Zertifikat. Und dann könnte man da sagen, nur mit diesem Public Key ist das okay. Das hat sich aber nicht bewährt, weil da haben sich die Leute ihre Seiten ausgesperrt und kaputt gemacht. Wenn der Browser da nicht mehr drauf geht und dann ist die Server Festplatte kaputt gegangen, neu aufgesetzt, Zertifikat musste neues ausgestellt werden, aber die Keys waren verloren, weil die da drauf waren und alle möglichen Sachen oder der Key war dann kompromittiert. Und das hatte halt auch eine Lebensdauer, die man da angibt. Und dann war das halt für die Zeit. Die Browser, die da einmal waren, haben der Seite dann nicht mehr vertraut mit einem neuen Key. Das hat sich nicht so als praktikabel herausgestellt und die sind deprecated. Und ich glaube, die meisten Browser haben es schon auch wieder ausgebaut.

Lisa Wie lange ist das schon deprecated?

Christoph Es ist schon lange, drei, vier Jahre ist es bestimmt schon deprecated. Ich wollte es aber noch mal erwähnt haben in Sachen, was es auch mal so gab. Also da sieht man, ich hatte vorhin gesagt, als man angefangen hat, solche Security Mechanismen zu planen, wusste man nicht so wo die Reise hingeht und was geht oder nicht. Und das ist so ein Beispiel. Das war sehr gut gemeint, hat aber in der Praxis überhaupt nicht geklappt. So ein Zertifikat oder Public Key Pinning oder CA Pinning gibt es ja zum Beispiel noch in anderer Form auf mobilen Apps oder so, die sagen, dass mit Servern kommuniziere ich, da hab ich ein Zertifikat dran gepinnt oder so. Oder es gibt so Mechanismen über DNS, dass man im DNS ja seine Certificate Authority angibt, von wem man Zertifikate bekommt. Und das funktioniert ja bis jetzt ohne Probleme. Ist wahrscheinlich nicht so weitverbreitet wie Browser, aber es gibt da halt Möglichkeiten, die dasselbe erreichen wollten oder Ähnliches erreichen. Aber da klappt es halt besser und im Browser hat das halt nicht funktioniert. Gibt es jetzt halt nicht mehr. Was gibt es noch so? Es gibt zum Beispiel die Referrer Policy, das ist so ein bisschen Datenschutz. Also, wenn ich auf eine Webseite kommen, dann sendet der Browser immer so ein referrer mit, woher kam der denn? Kann man dann sehen, ob seine Werbung gewirkt hat oder nicht. Das kann man aber auch ausschalten und sagen: Ja, wir senden jetzt hier kein referrer von mir mit, so ein bisschen Anonymisierung, Datenschutz fällt auch weit in den Bereich von Security. Und was ich noch ganz interessant finde, ist der Permission Policy Header. Da kann ich der Seite sagen, und auch so sub Elementen wie iFrames oder auch Ressourcen, die da drauf sind, also dem JavaScript, was da vielleicht ausgeliefert wird, welche der ganzen tollen Features, die die Browser heutzutage alle unterstützen, denn überhaupt genutzt werden dürfen? Kann ich die Geo Location abfragen? Kann ich die Kamera einschalten? Kann ich in den Fullscreen Modus gehen? Kann ich Auto Play einschalten? Kann ich Bluetooth APIs abfragen? Und so weiter und so fort. Kann ich schon sagen, du brauchst das auf meiner Seite nicht. Ich schalte das ab. Dann funktioniert es eigentlich über Allow list, wenn ich sage, was darfst du denn? Und was dürfen sozusagen die sub Ressourcen? Das JavaScript, was vom CDN geladen wird, dem vertraue ich vielleicht nicht so sehr, wie dem, was ich selber geladen habe, dann sage ich, das von der Origin CDN, die dürfen darauf nicht zugreifen, sondern die kritischen und sensitiven Sachen, die liefere ich mit meinem eigenen JavaScript aus. Die dürfen dann vielleicht einen Kamera Zugriff machen oder Mikrofon Zugriff. Da muss man ein bisschen aufpassen, das ist nicht die Permission API, die kennt man vielleicht auch, wenn man JavaScript programmiert. Da kann man abfragen, was darf ich denn benutzen? Das ist aber kein Sicherheitsmechanismus, sondern mehr der Use Case. Wir beide haben jetzt hier auch eine Browser basierte Podcast Software, die wir benutzen und da muss der Browser schon auf das Mikro zugreifen können, sonst funktioniert das nicht. Wenn man mit der Permission API abfragt, ist Zugriff erlaubt. Wenn das nicht so ist, dann kann der Browser dann zum Beispiel was rendern und sagen: Hier, du musst bitte das freigeben. Das Mikrofon ist nicht freigegeben, dann weiß er das. Und dann kann man das machen und normalerweise wird der User gefragt. Du kennst das auch, wenn du auf die Software gehst, der will Zugriff auf dein Mikrofon, will Zugriff auf deine Kamera erlauben oder nicht oder immer erlauben oder nur diesmal erlauben. Und die werden alle abgespeichert. Und mit der Permission API kann man halt abfragen, wurde jetzt Zugriff darauf gegeben? Aber wenn ich es abgeschaltet habe mit diesem Permission Policy Header, dann kann der User auch gar nicht einen Zugriff mehr drauf geben. Also dann kann die Seite nicht sagen, ich überschreibe das und fragt den User, das geht dann nicht. Da wird der User nicht gefragt, dann antwortet die API sozusagen immer: Computer says no. Geht halt nicht. Sieht man eigentlich relativ selten im Einsatz, muss ich sagen. Könnte man auch sagen, ich sage immer, eigentlich soll die erst mal nichts können. Ich glaube, das sind so die hauptsächlichen Header, die wir auf der Server Seite haben. Auf der Browser Seite gibt es auch noch Header, die was machen. Zum Beispiel den Origin Header, der war bei CORS, der wird zum Beispiel mit gesendet, woher kommt denn überhaupt der Aufrufer? Und es gibt eine ganze Reihe, die heißen alle sec-fetch und ein Minus und dann kommt Dest, also Destination Mode Site User. Also vier Stück insgesamt. Und da sendet der Browser mit, aus welchem Kontext die gesendet werden. Zum Beispiel dest könnte Image sein. Das soll für ein Bild sein, was geladen wird. Der Browser wird in eine Art Bit Buffer oder Datei sein. Der Mode zum Beispiel ist kein Cross Origin, also no CORS, nicht Cross Origin, kein Cross Origin Ressource Sharing. Also ohne die Header, bei Bild geht das ja, habe ich ja gesagt, da gibt es ja Ausnahmen. Mode no CORS oder könnte auch sein Mode same Site, same Origin. Also da steht nur, ob es CORS ist. Die Site ist nämlich noch mal ein weiterer Header. Da steht dann same Origin drinnen, same Site Cross Origin und ob der User diesen Request getriggert hat. Das ist wichtig beim Seitenwechsel. Also wenn du in der Top Navigation auf ein Link klickst und du kommst auf eine neue Seite, dann wird mitgeliefert, ob der User, der kann nur den Wert true haben und das heißt, der User hat diesen Navigationswechsel verursacht. Und dann kann der Browser entscheiden, ist das im Kontext überhaupt wo dieser Request legitim ist und könnte den dann einfach ablehnen aus diesen Metadaten und die kommen halt aus dem Browser. Das heißt, der Angreifer oder so kann auch dementsprechend nicht manipulieren. Er kann natürlich ein Request faken außerhalb des Browsers, aber wenn er dem Nutzer jetzt irgendwas unterjubeln will, irgendeine Seiten Navigation, wir gehen von einer legitimen Seite, kommen wir auf einmal auf einer Seite, wo es nicht so sein sollte, dann könnte der Server entscheiden, das mache ich jetzt nicht. Wobei das Beispiel natürlich jetzt nicht so ganz sinnvoll ist, weil wenn wir ihn umleiten auf eine Seite, die nicht legitim ist, wird der Server das nicht ablehnen. Ist ja sein Sinn, aber in anderen Kontexten, können wir das sagen, dieser Request kommt uns komisch vor, aus der Situation sollte der nicht getriggert werden. Und wenn er schon nicht vom User getriggert ist, dann lehnen wir den ab. Habe ich bis jetzt auch eher selten gesehen, dass diese Header irgendwie ausgewertet werden, muss ich gestehen. Aber ist halt eine Möglichkeit. Das ist so kein direkter Sicherheitsmechanismus, sondern Kontext Informationen, die es auf der Server Seite den Entwickler:innen leichter machen zu sagen, ist legitimer Request oder auch nicht, kommt mir ein bisschen komisch vor. Und ich glaube sonst wüsste ich auf der Browser Seite jetzt keine speziellen Header, die ganz speziell für die Security sind. Klar, wir haben noch die CORS Header vorhin genannt, die sind im weitesten Sinne so ein bisschen was. Diese Preflight Sachen und so.

Lisa Da fällt noch das Stichwort subresource integrity ein, was man als Entwickler:in vielleicht kennen sollte. Worum handelt es sich dabei?

Christoph Die ganzen Ressourcen, die wir laden Bilder, Fonts, JavaScript, wenn wir die von fremden Domains laden oder auch von unserer eigenen, dann kann man damit sicherstellen, dass da rüberkommt, was erwartet ist und dass vielleicht nicht ausgetauscht wurde, indem man einfach Check Summe bzw. ein Hash Wert angibt. Also wenn die Datei hasht, die da geladen wird, das JavaScript, dann steht die schon da drin und da könnte ich zum Beispiel erkennen, das CDN liefert mir jetzt irgendwas anderes aus, da ist ein bit flip oder so drin. Und dann wird diese Ressource nicht geladen bzw. nicht in den Browser Kontext geschoben und nicht ausgeführt. Kann man Manipulationen erkennen, wenn ich sage, in meiner Seite binde ich fünf verschiedene JavaScripts ein und die hätten folgende Char Summe und wenn du was anderes bekommst, dann wurde die ausgetauscht. Es muss ja noch nicht mal böswillig sein. Manche Leute versionieren nicht, sondern ändern einfach die Datei und dann fliegt es. Das ist ein bisschen problematisch, wenn Sachen geändert werden, die eigentlich keine semantische Änderung haben, haben sie anders komprimiert, haben eine Variable umbenannt und dann halt irgendwie keiner hat Versionierung drin, dann fliegt es immer auf die Nase. Deshalb wird das leider nicht so oft benutzt, wie man es benutzen sollte. Ich finde das ein super Mechanismus. Also da kann man ganz viele Angriffsvektoren sozusagen mit ausschließen. Klappt in der Realität halt auch nicht ganz so gut. Wie gesagt, wenn zu viele kleine Änderungen da sind, die für eine andere Char Summe sorgen, aber semantisch überhaupt keinen Unterschied machen. Aber es gibt es noch, nicht wie der Public Key Pinning Header. Das ist noch nicht raus und das ist auch kein Header. Das schreibe ich dann in das Image Tag rein oder in das JavaScript Tag. Und das Tag, das die Ressource lädt, schreibe ich die erwartete Char Summe rein. Mache auch noch Cross Origin, manchmal muss ich das noch markieren dann meistens, wenn es Cross Origin ist und dann wird es nach dem Laden gecheckt und dann nicht ausgeführt oder das Bild nicht angezeigt oder davon nicht benutzt oder whatever, welche Ressourcen wir da nehmen.

Lisa Das Nächste, worüber wir sprechen können, sind wahrscheinlich Cookies.

Christoph Ja, Cookies sind ein Mechanismus, der ziemlich wichtig ist für viele Web Applikationen, denn darin sind oft die Authentifizierungsinformationen enthalten. Also wer ist der User nach dem Einloggen auf irgendeiner Web App und Seite bekommt man ja meistens ein Cookie gesetzt, um zu sagen, das ist jetzt die Lisa oder das ist der Christoph. Und deshalb sind die wichtig, dass man die schützt. Und ja, die haben von Haus aus immer schon ein paar Sachen gehabt an Security Mechanismen, zum Beispiel für welche Domain sind die gültig, dass die auch nur wieder an die Domain gehen, wo die auch hingehören. Und auch der Pfad und die Lebenszeit. Weil wenn sie überall hingeschickt würden, dann könnte man ja da keine Authentifizierungsinfo groß machen oder irgendwelche Tokens oder so, aber das sind dann noch Sachen dazugekommen. Sind Attribute, die man an als Cookie setzt, sind drei an der Zahl, das ist HTTP Only, Secure und Same Site. HTTP Only heißt, ich finde, das ist ein total verwirrender Name, das heißt nicht, dass sie nicht per https gesendet werden und nur http, sondern das heißt, sie werden nur über http und https requests gesendet und sind nicht über JavaScript zugreifbar. Sie werden geschützt vor JavaScript. Das heißt, wenn ich mir durch Cross Site Scripting irgendwie da was eingefangen habe, kann man den Cookie mit den Authentifizierungsinformationen halt nicht entführen. Das ist ein Schutz, den man dann einsetzen kann. Würde ich immer empfehlen, dass man das macht. Bei so Single Page Apps ist das halt manchmal schwierig. Der Cookie wird trotzdem mit gesendet an den Requests. So ist es ja nicht, aber die wollen dann vielleicht gerne drauf zugreifen und zum Beispiel zu sehen, ist meine Session noch gültig? Und nicht erst vom Server irgendwie ein 401 bekommen, sondern sagen, ich will das vielleicht frühzeitig verlängern oder sonst was. Also muss man ein bisschen aufpassen. So, dann Secure wäre eigentlich https only. Also sicher muss das dadurch nicht sein durch secure, sondern das heißt, es wird nur verschlüsselt übertragen, also Transport verschlüsselt. HTTPS only wäre eigentlich ein besserer Name, aber gut. Auch wichtig, sollten nicht abgehört werden können. Authentifizierungsinformation sollte man auch immer dran haben, gerade da ja sowieso heutzutage alles leicht über HTTPS geht. Und dann gibt es noch Same Site. Da wird geschaut, auf welchen Seiten der Cookie geschickt wird. Ich kann ja aus meiner Seite Requests an anderer Origins haben oder an andere Seiten. Und da ist die Frage, wird er dann mit gesendet oder nicht? Das ganze Werbe Tracking basiert ja so ein bisschen darauf, dass wir irgendwie auch gleichzeitig ein Request an Facebook und an TikTok, Twitter und sonst wo. Und dann ist die Frage, werde ich da mit gesendet oder nicht? Da wird unterschieden zwischen First Party und Third Party Cookies und Same Seite kann das so ein bisschen steuern. Same Site kann man halt einstellen, ob das überall mit gesendet wird. Es gibt man, lax und strict oder ob das dann auch nur auf die eigene Seite mit gesendet wird. Und wie ist es bei Lax, da gibt es so Sonderfälle, wie ist es beim Seitenwechsel? Ich folge einem Link, komme auf eine andere Seite, ist das dann sozusagen schon die First Party oder nicht? Das kann man schützen, kann man nutzen. Das schütz zum Beispiel für Cross Site Request Forgery. Also ein Angreifer hat eine Seite gemacht, da ist ein Formular für die Banküberweisung. Ein klassisches Beispiel, was so nie funktioniert, weil das ja noch 3000 andere Mechanismen gibt, wie zum Beispiel die TAN. Aber ne, bleiben wir mal dabei, um das anschaulich zu machen. Eine Überweisung und der schickt das dann heimlich ab. So, oder das Formular ist gar nicht zu sehen. Die Seite lädt per JavaScript oder im nicht sichtbaren Bereich des Formular, JavaScript drückt dann auf den Knopf und dann würde ja der Cookie ohne Same Site mitgeschickt bei diesem Post Request und dann würde ich irgendwie eine Bank Transaktion starten oder eine Onlineshop Bestellung, whatever. So, dazu hat man früher, und sollte man heute vielleicht auch noch, irgendwelche C-Serve Tokens benutzt. Also irgendwelche geheimen Dinger, die in dem Input Field sind im Original Formular, die der Angreifer nicht haben kann, die dann noch mal verglichen werden müssen. Es gibt auch so ein Cookie Mechanismus für SPAs, die dann sowas machen können. Genau, das war ein Mechanismus, in dem man das abgewehrt hat. Wenn man jetzt eine Same Site da drinnen hat, dann werden die Cookies nicht mehr mitgeschickt, weil die Angreifer Seite für die ist die Seite, auf die der Angriff geht, eine Third Party und dann wird dieser Third Party Cookie nicht mehr mitgeschickt. Deshalb sollte man das auch machen, nicht nur gegen das Tracking, sondern auch gegen CSRF, also Cross Site Request Forgery Angriffe kann man dann dafür einbauen. Das sind so die Mechanismen, mit denen man das Cookie beschützen kann. Als Alternative gibt es noch den Local Storage. Da könnte ich jetzt zum Beispiel auch Sachen ablegen, wie Token oder andere Authentifizierungsinformationen. Da muss man ein bisschen aufpassen, ein bisschen abwägen. Local Storage hat halt den Vorteil für diese ganzen SPAs, die können darauf zugreifen, können das auslesen, können dann auch den Token zum Beispiel in einem Authentication Header mitschicken und nicht nur als Cookie dabei, also auch an anderen Stellen, also über andere Transportwege. Das macht das ein bisschen leichter. Das Problem ist, alle von dieser Domain bzw. von dieser Origin können das auslesen. Das heißt, habe ich einen Cross Site Scripting, kann dieser Token aus dem Local Storage ausgelesen werden. Beim Cookie wird das nicht gehen, wenn ich ihn zum Beispiel auf http only. Man könnte das JavaScript, was ich per Cross Site Scripting bekommen habe, zwar immer noch irgendwelchen Unsinn auf der Seite machen, aber es kann erst mal die Cookies nicht auslesen. Deshalb ich bin kein Freund davon die Sachen in Local Storage zu machen, wird aber in so SPAs dann doch gerne gemacht. Muss man abwägen, wie hoch man das Risiko da einschätzt. Ich würde wahrscheinlich eher abraten, aber es gibt bestimmt legitime Gründe, gerade in so großem SPAs, dass man den Zugriff darauf hat.

Lisa Früher wurde ja noch viel mit WebSockets gemacht. Bieten da Browser auch irgendwelche Sicherheitsmechanismen? Ich glaube, es ist wirklich nicht mehr so viel, was mit WebSockets gemacht wird. Aber vielleicht bilde ich mir das auch nur ein, weil ich es lange nicht gesehen habe.

Christoph Ich habe keinen Überblick darüber, wie viel davon noch gemacht wird, aber sie gibt es ja noch. Ja, das ist ein gutes Beispiel für so Dinge, die so ein bisschen außerhalb laufen. Wir haben gerade gesehen, ganz viel wird über Header gemacht und sind auf Request Basis und auf Ressourcen, die da drinnen sind. Aber die WebSockets sind ein bisschen so außerhalb, da muss man ein bisschen aufpassen. Auf der Server Seite bin ich nicht automatisch authentifiziert. Also nein, es gibt keine Authentifizierung, sondern der verbindet sich erst mal. Ich muss das selber prüfen, indem ich zum Beispiel schaue, wo kommt dann der Origin Header her? Es wird ein Origin Header mitgesendet zum Beispiel beim WebSocket. Also Problem dabei ist, es könnte sich auch eine beliebige andere Seite mit meinem WebSocket verbinden. Ich kann nicht darauf vertrauen, dass es meine Seite ist. Deshalb muss ich das alles noch mal von Hand prüfen, ist jetzt alles nicht so schwer. Das Problem ist, die anderen Mechanismen, über die wir jetzt so viel gehört haben, die greifen da alle nicht so wirklich. Das ist so ein schöner Sonderfall. Da hat man gesagt, ja, wir brauchen irgendwie WebSockets, kann Gründe geben, warum man die braucht, aber sind halt nicht das typische Web Modell und fallen dann auch bei den Sicherheitsmechanismen so ein bisschen raus. Und da muss man aufpassen. Wahrscheinlich ist es auch ähnlich wie jetzt hier die Software, wo unser Audio übertragen wird mit WebRTC. Das sind auch so Dinge, die nicht dem typischen Web Modell entsprechend, die dann wieder eigene Mechanismen benötigen dabei. Muss man ein bisschen aufpassen.

Lisa Gibt es noch ein großes Thema, über das du in der Folge sprechen möchtest?

Christoph Wir hatten ja gesagt, dass wir den einen Aufhänger mit den Hot Pixels haben, Hardware Side Channels. Darüber sollte man noch mal reden, weil das hat angefangen mit Meltdown und Spectre, diese Hardware Site Channels in CPUs. Das war ein ganz großes Thema und da hat sich das Sicherheitsmodell oder das Thread Modell für so einen Browser halt grundlegend geändert. Und das hatte große Auswirkungen. Sowohl in der Architektur als auch in der Implementierung mussten jede Menge Dinge geändert werden. Vorher hatte man halt versucht, ein bisschen die Browser auf performance zu trimmen. Versucht man heute immer noch, aber ein Mittel dazu war zum Beispiel, dass man sagt, wir haben einen Thread basiertes Modell, das heißt die verschiedenen Dinge vielleicht in so einer Webseite oder die verschiedenen Tabs in meinem Browser sind alle ein Thread, weil das weniger overhead ist, als wenn wir jetzt einen Prozess machen. Und das macht sich dann auch spürbar bemerkbar. Dann sind so Messungen, die die Browser Hersteller gemacht haben, waren so 10 bis 15 % overhead, wenn alles in Prozessen läuft. Und die Richtung ging immer, wir machen so ein Threading Model. Und dann hat man gesehen, okay, aber Thread Model, dann sind die alle in einem Speicherraum und die Mechanismen, die wir jetzt alle gehört haben, die nutzen gar nichts drinnen, wenn ich jetzt über die Hardware Site Channel in der CPU den Speicher auslesen kann und wenn jetzt die Tabs so nicht gut voneinander isoliert sind, weil sie den gleichen Speicherraum haben, dann kann ich in einem Tab könnten Angreifer ein JavaScript ausführen, das den Speicher des anderen Tabs ausliest und da sind dann vielleicht meine Authentifizierungsinformation für meine Bank drinnen oder beliebige Authentifizierungsinformation. Und das heißt, da hat man dann gesagt, okay, wir müssen unsere Architektur hier ändern, wir müssen auf ein anderes Modell gehen, wir müssen die Seiten, die Tabs und Ressourcen deutlich stärker voneinander isolieren. Und das hat zu großen Umbau in den Browsern geführt. Heute ist alles nach Prozessen getrennt. Der Render Prozess wird von dem Content Prozess getrennt, der dann in dem Hauptbrowser Prozess ist, die alle dann auch noch mal in eigenen Sandbox laufen. Man hat aber auch direkt Implementierungsdetails geändert, zum Beispiel damit man das per JavaScript ausnutzen kann so einen Site Channel. Braucht man relativ präzise Timer und die hatte JavaScript und die hat man einfach erst mal abgeschaltet, weil da gab es kein Mittel gegen. Also da musste man halt sehen, was man tut, schaltet man halt ab. Genauso dieser Shared Array Buffer, der nötig war, damit man sagen kann, sind jetzt Sachen im Cache oder nicht? Kann ich da Dinge auslesen? Das wurde erst mal einfach abgeschaltet in der Implementierung. Da hat sich viel geändert. Man kann die Dinge jetzt zum Teil wieder einschalten, indem man bestimmte Bedingungen erfüllt, indem man seine Seite isoliert hat, nicht nur im Browser von anderen Tabs oder so, sondern das heißt dann Cross Origin isolated. Das kann man auch per JavaScript abfragen und also Cross Origin isolated ist eine property und die gibt dann true oder false raus. Und wenn die true gibt, dann habe ich auch wieder Zugriff auf diese hochpräzise Timer und Shared Array Buffer. Und was hat man gemacht? Man hat wieder so ein paar neue Header eingeführt, um zu sagen, ja, es kommt jetzt alles von einer Origin oder von erlaubten Origins. Was ist das Angriffs Modell? Ganz einfaches Beispiel, nicht praktisch, aber für die Erklärung vielleicht ganz gut. Ich hole mir ein Bild rein und das kommt von einer anderen Origin. Dann hatte ich am Anfang ja erzählt, dass man da nicht auf die Pixel oder auf den Inhalt zugreifen kann. Dies opak, die wird im Browser angezeigt, aber das JavaScript kann da nichts draus machen. Auf dem Bild könnte eine TAN Nummer dran stehen, die mir meine Banking Software anzeigt, die ich woanders angeben muss und Bild, damit man es halt nicht auslesen kann. So, jetzt habe ich das Bild irgendwie geschafft in meine Seite zu bekommen, nützt aber nichts, ich muss ja da die Informationen, die Pixel müsste ich ja irgendwie rauskriegen. Geht nicht. So, wenn ich jetzt einen Site Channel mache, dann kann ich halt den Speicher auslesen, kann auch diese Pixel auslesen. So, also muss man gegen solche Angriffsszenarien sich irgendwie schützen. Und es gab schon so ein bisschen was vorher. Das ist Cross Origin Read Blocking, dass ist kein Header oder so, sondern das ist ein Mechanismus, der verhindert hat, dass Ressourcen überhaupt in den Speicher gelangen. Zum Beispiel Angriffsszenario: Wir wollen eine JSON Datei von irgendwo laden und die auslesen, können wir nicht, weil es eine andere Origin ist. Da sind irgendwelche geheimen Informationen und der Browser wird sie aber überladen, weil der Nutzer an dieser Domain oder an dieser Origin angemeldet ist. So, das angreifen JavaScript aus der anderen Origin könnte jetzt auch über so ein Seiten Kanal Angriff das machen. Und es gab vorher so Möglichkeiten zu sagen, wie bekommen wir das überhaupt in den Prozess rein? Also wir nehmen Image Tag, laden aber JSON. Nun lädt er diese Ressource in den Speicher. Er scheitert dann beim Rendern, gibt eine Fehlermeldung auf der Konsole. Das Bild ist nur der Platzhalter, aber die Daten sind schon in dem Speicher und deshalb heißt es Read Blocking. Wenn der mir so was erkannt hat, der Browser, hat er verhindert, dass solche Daten überhaupt geladen werden, also überhaupt in den Prozess reinkommen. Aber es gab schon und das reicht dann aber nicht. Das war auf sehr spezielle Angriffsszenarien geeicht dieses Cross Origin Read Blocking, deshalb gab es halt neue Header und da sind drei Stück an der Zahl. Das ist die Cross Origin Embedder Policy, die Cross Origin Resource Policy und die Cross Origin Opener Policy. Wir gehen sie mal durch: Diese Embedder Policy, was macht die? Die bestimmen, wo denn meine Ressourcen herkommen sollen, die meiner Seite geladen werden. Und die bewirken so das Umgekehrte von dem, was CORS macht. Also die erweitern nicht den Raum, sondern die schränken ein. Der Standardwert, der vorher war, war unsafe none, das heißt kann von überall kommen. Ich kann Bilder von überall oder required CORP. Also CORP ist Abkürzung für Cross Orion Resource Policy und das ist ein weiterer Header, der kommt dann an die Ressource dran, nicht an die Seite und der beantwortet die Frage, die Ressource, die ich habe, wo darf die überall geladen werden? Und dann kann ich der mitgeben Same Site, Same Origin oder Cross Origin. Vorher war es immer der Default Cross Origin, also das Bild was ich hoste, wenn ich das ausliefer mit dem Header, also ohne Header kann von überall geladen werden, bei Cross Origin wird der Browser das dann halt auch noch laden, dass ist der Standardwert, aber bei Same Site oder Same Origin wird er das blockieren, wenn es nicht Same Site oder Same Origin ist. Das heißt, ich kann die Bilder noch nicht mal mehr von anderen Seiten laden, wenn sie es nicht explizit erlauben. So, und das ist halt genau der umgekehrte Weg zu CORS. Ich verkleinere den Kreis, wo meine Ressourcen herkommen. Damit kann ich halt sicherstellen, dass Ressourcen nur explizit erlaubt sind. Und wenn das so ist, dann heißt das okay, du bist halt Cross Origin Isolated, du hast nur Ressourcen, die auch explizit erlaubt wurden oder die von deiner eigenen Origin kommen. Und dann kann ich dir auch deine Timer und deine Shared Array Buffer und sonst wie zurückgeben. Das ist wahrscheinlich das Modell, wie man es heute sowieso machen würde. Man wird nicht die Ausnahmen für Bilder und JavaScript oder so, sondern das ist halt so eins, egal was, es gibt eine Policy und die muss stimmen. Und das wäre ein Modell, was man heute wahrscheinlich standardmäßig machen würde. Das ist jetzt leider so ein bisschen drauf geklatscht. Passt weder zu diesen opaken Ressourcen noch zum CORS Modell richtig zusammen. Also da merkt man so die Entwicklung, alles ist noch da, es überlappt sich zum Teil, das eine macht es größer, das andere macht es kleiner, das eine hat Sonderfälle. Und ja, wie gesagt, heute wird man wahrscheinlich halt mit diesem Cross Origin Embedder Policy, Resource Policy und Opener Policy dann anfangen. Und die Opener Policy hatte ich jetzt noch nicht gesagt. Da geht es darum, wenn ich ein neues Tab oder Fenster oder so ein Popup offen habe, das ist dann, die haben da eine Verbindung im Dom, da steht der Opener drin und die sind dann noch im selben Kontext und im selben Speicherbereich. Und das will man halt verhindern. Die haben dann auch wieder die Sache Same Origin an safe none, wie jetzt. Also dann bist du halt nicht isoliert. Same Origin, okay, von derselben Origin, dem vertraue ich. Oder es gibt noch eine Ausnahme Same Origin Allow Popups. Das heißt, wenn ich so eine Authentifizierung, so ein Popup Fenster öffne oder für was anderes, gibt es ja bei Kreditkarten Zahlung, da muss man einen Secure Code oder sonst irgendwas eingeben, da sind für solche Fälle dann noch mal einen Wert. Brauchen jetzt nicht im Detail machen. Ist auch auf der Audiospur ziemlich kompliziert, wenn man alle Details durchgeht. Ich glaube, jetzt schon war es nicht so einfach, aber die gibt es auch noch. Spielt eine Rolle, wenn ich andere Fenster öffne, dass die dann auch isoliert werden. Wie wir es am Anfang gesagt haben, es kommen neue Seiten Kanal Attacken. Dieses Hot Pixels, ist auch wieder per JavaScript aus nutzbar. Wie gesagt, nur unter sehr speziellen Umständen. Aber wird man heute anfangen die Sicherheitsmodelle zu bauen, dann sehen die eher so aus. Aber damals hatte man das Wissen noch nicht und man wusste nicht was kommt. Und jetzt haben wir ein großen Mischmasch, der für Entwickler:innen auch nicht einfach ist. Da kommt man da und sagt, ja, hast du schon CORS? Ach so! Das. Also schwierig.

Lisa Du hattest ja vorhin schon von diesem Public Key Pinning erzählt und dass deprecated ist und heute keiner mehr nutzt, weil das so oft schiefgegangen ist, basierend auf diesen drei neuen Headern, denkst du, dass gerade diese Version eins CORS, das ältere Dinge jetzt wegen der neu entstandenen Dinge auch auf Dauer deprecated werden? Oder denkst du, es wird nicht gemacht, um immer bei CORS kompatibel zu sein?

Christoph Also es werden bestimmt Dinge mal wieder rausfliegen, allerdings nicht an diesen drei neuen Headern und den neuen Sicherheitsmodell, wo ich jetzt gerade behauptet habe, man wird es jetzt wahrscheinlich so machen, weil die sind bis jetzt auch kaum im Einsatz. Weil man sagt, ja, das ist Hardware Side Channels, die werden ja auch im bios gepatcht und der User muss sich drum kümmern oder das ist out of scope für uns und die schränkt natürlich die Developer Experience ganz schön ein. Deshalb glaube ich nicht, dass das so schnell kommt, dass so was wie CORS wieder rausgeschmissen werden, glaube ich auf keinen Fall. Auch nicht die opaken Ressourcen. Wenn man jetzt verbieten würde, dass man Images einbettet, ohne dass wenn das Image ausgeliefert wird, ein spezieller Header gesetzt wäre, dann hätte man einen Text Internet. Würde manche freuen, aber die Bilder gibt es nicht mehr so, das wird so nicht passieren. Das glaube ich nicht. Es ist leichter für die Browser Hersteller, Sachen rauszuschmeißen, die dann den Browser nur betreffen. Aber wenn ich was rausschmeiße und auf einmal müssen alle ihre Webanwendungen ändern, das wird nicht passieren. Und dann muss man sehen, was das erfordert. Und jede Menge der Sachen, die wir heute besprochen haben, würde es erfordern. Was ich noch am ehesten vorstellen kann, ist Sub Resource Integrity. Das sieht man nicht oft im Gebrauch, weil da auch viel schiefgeht und so und das kann ich mir vorstellen, dass sowas vielleicht rausfällt auf Dauer. Bei dem Rest sehe ich nichts, wo ich sagen würde, das fliegt jetzt erst mal in den nächsten fünf Jahren raus bzw. wird nur als deprecated gekennzeichnet. Vielleicht schon eher die neuen Sachen, also die Embedder Policy oder Source Policy, Opener Policy, weil die nutzt ja auch keiner und machen die Developer Experience schlecht. Und wenn ich sie rausschmeiße und einer setzt die bei dem es ja kaum Unterschied zu merken. Es funktioniert ja dann immer noch. Also das ist jetzt nicht so, dass die Leute da was ändern müssen. Dann senden sie den Header mit und der Browser wird den ignorieren. Aber trotzdem der Sicherheitsverlust sozusagen eher marginal. Von daher schwierig.

Lisa Also ich habe auf jeden Fall mitgenommen, dass der Browser eigentlich schon ziemlich viel für uns tut. Das Gefühl habe ich jedenfalls. Und dass die Browser das gleiche Problem haben wie JavaScript quasi immer Altlasten mitschleppen, die mal entstanden sind, die dann eventuell noch mal ein bisschen gepatcht werden.

Christoph Auf jeden Fall. Und was die Zuhörer:innen auch mitnehmen sollten, ist, der Browser, dass ist jetzt so eine große Plattform und auch wenn der viel für uns tut, wir müssen auch was für den tun. Also wir müssen diese Sicherheits Header, Security Header, die es alle gibt, auch einsetzen. Das schützt unsere Anwendung und das schützt die Anwender unserer Anwendung und Anwenderinnen unsere Anwendung. Das muss man auch machen, das kommt nicht mehr umsonst. Das ist so, vorher gab es das nicht, brauchte man sich nicht kümmern und das Web war eine einfach zugängliche Plattform. Das ist heute vielleicht nicht mehr so einfach, doch sie ist immer noch einfach zugänglich, weil sie den Teil ausblendet und weil der nicht verpflichtend ist, aber man sollte sich damit ein bisschen beschäftigen und sozusagen es dem Browser auch leichter machen. Was hat der Browser für uns getan? Was tun wir für den Browser?

Lisa Schönes Schlusswort. Vielen Dank, Christoph, für die Folge heute. Ich habe viel mitnehmen können und viel gelernt. Ich hoffe, dass es euch da draußen genauso ging und dass ihr auch Spaß hattet beim Zuhören. Ich würde noch sagen, wenn ihr Spaß hattet oder irgendwelches Feedback hattet, könnt ihr euch natürlich gerne bei uns melden. Am liebsten per Mail bei [email protected]. Wenn ihr einen Themen Wunsch habt, was hier im Podcast behandelt werden sollte, könnt ihr das auch gerne per Mail einreichen. Wenn es euch hier gefällt und ihr das gerne auch weiterempfehlen möchte, dann tut das gerne. Bewertet es auch gerne. Wir bedanken uns ganz herzlich bei euch allen da draußen und sagen bis zum nächsten Mal. Ciao!