 Dann fangen wir mal an. Genau, ich erzähle ein bisschen was über HTTP Security-Header, hat auch irgendwie was mit HTTPS zu tun, aber nicht nur. Aber da schauen wir auch mal ein bisschen drauf, weil das ja irgendwie alles miteinander zusammenhängt. Ja, wo kommen wir her? Irgendwie ist das alles nicht so richtig schön, was wir da haben. Genau, alle Anwendungen reparieren, die es schon gibt, wird wahrscheinlich nie passieren. Auch Sequel-Injection, die kriegen wir auch mit den Headern leider nicht weg, aber das ist immer noch ein Problem, seit es Sequel gibt eigentlich. Das ist übrigens auch ein Problem für Non-Sequel-Systeme, nur wenn wir denken, machen wir keine relative Datenbank, dann haben wir die Probleme nicht. Da gibt es ähnliche Angriffsvarianten, da gab es auf den 33C3, glaube ich, einen schönen Vortrag zu. Also das ist immer noch ein Problem. Irgendwie haben sich viele Leute gesagt, wir müssen was tun. Es muss irgendwie skalieren, mit dem ganzen Zeugwasser draußen ist. Ich will aber nicht alle Anwendungen anfassen. Und das soll es zumindest den Angreifen schwerer machen. Also, hat man sich überlegt, gehen wir in die Infrastruktur. Was verstehe ich jetzt in dem Vortrag unter Infrastruktur? Also so ein bisschen die Protokolle, weil sind ja auch HTTP-Header. Um die es geht, also eine Protokollerweiterung im Fall von HTTP, neue Header, neue Features, die der Kleint dann im Prinzip ausführen muss. Die sind durch Standards abgedeckt und natürlich geht es irgendwie um den User-Agent und die Server. Das ist irgendwie die Infrastruktur, aber nicht um die Anwendungen an sich. Auch wenn man diese Header benutzt, manchmal vielleicht was in der Anwendung ändern muss, um die benutzen zu können. Aber das ist jetzt nicht das Ziel des Vortrags. Genau, habe ich gerade schon gesagt, irgendwie hat man sich gedacht, was kann man tun? Wir kleben noch ein paar mehr Header ins HTTP-Protokoll, weil da sind ja noch nicht genug drin. Und inzwischen ist man auch soweit, dass man diese Header nochmal versioniert, damit man mehr Spaß beim implementieren hat. Also, das wären auch immer mehr. Ich habe den Vortrag auch letztes Jahr schon gehalten und vor zwei Jahren. Da waren es, glaube ich, noch sechs, jetzt haben wir zehn. Anscheinend findet man jedes Jahr auch neue Probleme, die man noch fixen muss, an die noch keiner gedacht hat vor zwei Jahren oder vor zehn Jahren, als man alles gebaut hat. Aber der Vorteil ist natürlich, ich muss Prinzip ja erstmal nicht in die Anwendung reingreifen. Ich kann einfach einen Header mit schicken und dann macht der Kleint. Also, der User-Agent, üblicherweise der Browser oder die Web-View in der Mobile-App, macht dann irgendwie verhält die sich anders. Genau, es macht es für den Angreifer schwerer, aber natürlich muss ich trotzdem an Anwendung sicher bauen. Also, das geht nicht. Es reduziert nur ein paar Standardrisiken oder macht ein paar Angriffe schwieriger, die dann immer noch gehen. Was ist jetzt das Problem damit? Wenn der User-Agent das falsch implementiert, skaliert der Fehler auch wunderbar, dann haben nämlich alle das Problem. Das Problem sieht man auch immer schön an Android. Und so, wenn da ein Back ist, dann trifft es halt viele auf einmal und bis dann alle mal den Backfix ausgeräut haben, das kann dauern. Aber wenn sich es mal tun, skaliert es auch schnell mit einer neuen Version. Man wird unabhängig von Anwendungsproblemen, aber halt nicht nur. Aber die Infrastruktur hilft halt nicht. Also, das ist nur ein Zusatz. Wenn man diese Header benutzt, muss man seine Anwendung trotzdem genauso sicher oder robust gegen Fehler und Angriffe absichern, als ob die Header nicht da wären. Sehen wir auch gleich noch warum, weil vielleicht kommt der Header ja gar nicht beim Kleint an. Weiß ich ja nicht. Genau. Und was wichtig ist, ich muss alle Leute immer trainieren, die irgendwie mit Web-Anwendung, mit Mobile-Apps, mit den APIs hinten dran, das muss alles irgendwie zusammenspielen. Die einen müssen wissen, dass die anderen da vielleicht noch irgendwas mitschicken, was auch das Verhalten des User-Agents verändert. Das mache ich so ein kleiner Überblick. Wie gesagt, das ist jetzt nicht ganz vollständig, weil das werden fast wöchentlich mehr. Aber da schauen wir gleich mal auf eine Seite. Wer kennt Observatory? 4, 5, 6, 6 von 60, immerhin 10 Prozent. Ich habe letztens einen Vortrag an der DHB Wege gehalten. Da waren 20, da ging gar keine Hand hoch. Ich habe eine bessere Quote hier. Was ist das? Das ist ein Tool, im Prinzip. Mit dem kann man seine Anwendung testen oder die API, also eine URL eingeben. Das können wir auch gleich mal machen. Und dann bewerten die das, die testen da auf die Zertifikate, ob die vernünftig sind, also die richtigen Hashes benutzen, nicht zu lange laufen. Und dann halt auch eine ganze Menge Hedder, die man setzen kann und halt auch, ob bestimmte Cookie Flex gesetzt sind. Also so ein Projekt von der Mozilla-Organisation, die die Web-Sicherheit verbessern wollen. Jetzt haben wir gesehen, 5 oder 6 von denen, die hier sind, kennen das überhaupt. Das ist schon mal das erste Problem, keiner kennt die Tools, die schon da sind. Deswegen ist es auch so ein bisschen das Ziel, das zu verbessern, dass man auch diese Toolchain oder die Hilfsmitte, die es gibt, kennt und benutzen kann und dann kann jeder seine eigene Seite da mal eintippen und gucken, was er für ein Rating kriegt. Ja, welche Seite soll ich da mal eintragen? Wer will sein Blog testen oder so? Ja, aber das Security-Punkt fehlt, das machen wir danach. Ein anderer Vorschlag, das können wir mal machen. Da ist ein bisschen was drin, aber wir machen natürlich auch nicht alles. So, jetzt muss ich hier mal kurz widschen. Mal sehen, ob der Scanner das überlegt. Das sieht schon mal gut aus. Also Observatory. Ja, also ganz einfach, da gibt es auch eine API zu, muss das also nicht übers Interface machen. Man kann ja auch sagen, man möchte nicht öffentlich schlecht aussehen, weil es gibt hier immer so Statistiken. Also hier kann man dann gucken, wer so zuletzt gescannt wurde und was dabei rausgekommen ist. Wir sehen auch gleich auf dieses Observatory, ist ganz nett, weil das macht selber eine Bewertung und benutzt noch ein paar Third-Party-Tools. Den war gleich. Also die werden alle vom Browser ausgetriggert und die machen alle was Ähnliches. Und auf die gehe ich nachher auch ein bisschen ein, weil man wird sehen, dass nicht alle Bewerten alles gleich. Man hat dann irgendwo einen F, man hat vielleicht trotzdem noch ein A irgendwo. Also A steht für supergut. F ist ganz schlecht. Und dann kann man auch mal ein paar Google Domains eingeben und dann sieht man so wie sich das so verhält. So, was für eine Seite sollte ich jetzt nehmen? Entropia. Da sind ein paar Heller drin, aber nicht alle. Das dauert jetzt auch einen kleinen Moment. B- ist schon mal ganz gut. Was das Schöne an der Seite ist, hier rechts sieht man, da gibt es auch immer ein paar Hilfestellungen. Was könnte man dann noch reinpacken für so eine? Hier ist gleich so einer. Dann sage ich gleich was zu. Dann kann man hier auch draufgehen und kriegt eine Hilfe. Dann gibt es hier so ein Blog. Sieht man hier Content Securities. Wenn keine Cookies da sind, muss ich auch keine besonderen Flags beachten. Wenn man so mit Sessions arbeitet, dann gibt es ja so ein Secure Flag. Das heißt, dieses Cookie wird nur über eine gesicherte Verbindung, also HTTPS übertragen und dann noch ein HTTPS Only Flag. Das heißt, ich kann nicht mit JavaScript auf dieses Cookie zugreifen. Cross Origin Resource Sharing. Das sind auch spezielle Heller. Manchmal wollen Webseiten unter einer Daten austauschen, dafür benutzen wir das. Dann gibt es hier irgendwas mit Keypinning. Das ist hier neutral bewertet, weil der ist auch optional. Der ist beim meisten optional, weil wenn man das falsch macht, hat man so einen Self DOS. Das hat man bei einigen dieser Heller bei dem Nächsten. Wenn man da bestimmte Flags setzt, sind dann vielleicht plötzlich irgendwelche Internet Domains nicht mehr erreichbar. Auf der Hauptdomain, wo man sagt, dann ist auch alle Subdomains mit berücksichtigen. Also die sind nicht ganz ungefährlich. Redirection ist einfach, wenn man den Heller mit benutzt und mit der Preload List, da komme ich auch noch drauf. Inzwischen gibt es auch was, wo man steuern kann, wann der Browser oder der User Agent, der Kleintreferer an wen zurück schickt, unter welchen Bedingungen, wenn sich die URL erinnert, dann nicht. Oder nur die Domain, aber nicht mehr die Domain Details. Sub-Resource Interview, das sind zwei relativ neue Heller und dann gibt es hier ein paar relativ alte Heller. Ich gehe dann noch auf die einzelnen Heller ein. So, jetzt sieht man hier, wie oft wurde die Domain schon getestet. Da gibt es so eine öffentliche Historie, wenn man das öfter macht. Das war am 22. Mai 2016, das war wahrscheinlich letztes Jahr zur GPN. Und da war es auch B-. Also da haben wir jetzt nichts weitergemacht. Ach so, die haben das geändert. Die hatten das früher auf einer Seite, jetzt haben sie Taps gemacht für diese Scannerelle Summary. Hier sieht man auch, was der Server für Heller mitschickt. Und dann kann man hier schauen. Okay, führt dann raus. Jetzt sehen wir hier, also da haben wir ein B-. Hier haben wir jetzt plötzlich ein A+. Besser geht es ja nicht. Aber die testen nur auf TLS Settings im Prinzip und die Settings vom Zertifikat. Und dann sieht man hier, ja, es ist irgendwie auch kompatibel zu bestimmten Standards, zu anderen nicht. Also für HIPAA wird das jetzt nicht ausreichen. Das ist ein nordamerikanischer Standard für den Medizinbereich. Und NIST ist der nordamerikanische Standard-Body so wie den in Deutschland im Prinzip. Die haben also noch irgendwie besondere Anforderungen, die wir jetzt nicht erfüllen. Das ist jetzt aber auch nicht so spannend. Dann gibt es hier noch so ein Test, der auch TLS Settings testet. Der war jetzt gerade nicht verfügbar. Hier gibt es hier ein Test, der testet speziell auf diese Header, die man einführen kann. Da haben wir jetzt ein D. Und dann gibt es hier noch dieses Preload. Was auch immer das ist, da kommen wir noch drauf. Also eine ganze Menge Zeug, mit dem man sich beschäftigen kann. Und jeder hat auch eine andere Meinung zu dem ganzen Thema. Ist also nicht trivial. So, jetzt schauen wir hier. Der ist ja auch noch beschäftigt. Dann kommen wir wieder zu den Folien zurück. Jetzt haben wir den U-Endern. Genau. Also da kriegt man schon mal so einen Überblick. Ja, diese Header, wenn ich die jetzt über HTP schicke, dann können die beim Kleint ankommen oder auch nicht. Man kann die unterwegs verändern. Dann macht der Kleint was anderes. Also wenn ich über einen komischen Proxy laufe oder in meinem Lieblingscafé sitze und die haben kaputtes Internet. Und ich ruf eine Seite über HTP auf. Dann, wenn ich die jetzt baue und da diese Header mit schicke, dann ist das schön. Aber ich habe keine Garantie, dass die auf der anderen Seite ankommen. Da muss man also deswegen, das war vorhin, ich muss meine Anwendung in sich sicher machen und die Header sind eine schöne Sache. Das heißt, wenn ich mich da drauf verlassen möchte, dann muss ich sowieso HTP-S machen. Weil sonst habe ich keine Garantie, die ich dann mit schicke, überhaupt auf der anderen Seite ankommen. Oder ob sie nicht anders ankommen und dann deaktiviert sind im Prinzip beim Kleint. Und er macht weniger, als ich denke, dass er macht. So, das haben wir, HTP-S hat irgendwie was mit Publiki Infrastructure zu tun. Da kommen diese ganzen Zertifikate her. Das Zeug ist auch nicht ganz ungefährlich, wie wir gelernt haben. Man kann den Dinger dann doch nicht vertrauen. Oder wenn ihr in euer Lieblingsbetriebssystem schaut, da sind eine ganze Menge Routes drin. Das sind meistens dreistellige Anzahl. So wem ihr so alles traut, dass Sie das A richtig machen und B dann allen traut, den die Zertifikate geben. Das ist also nicht ganz ohne. Jetzt habe ich hier mal einen Link von Google gemacht, der nicht mit S funktioniert. Das ist, glaube ich, der einzige Google-Link, der nicht mit S funktioniert. Wir können auch mit HTP-S aufrufen, aber ich glaube, das ist die einzige Google-Seite, die man ohne HTP-S aufrufen kann und wo man nicht auf HTP-S redirectet wird. Dafür gibt es einen einfachen Grund, weil man kann auch mit PKIs ganz viel falsch machen. Der Grund ist, wenn ich jetzt, da gibt es irgendwie eine CA und dann gibt es so OCSP-Händler. Da kann man online überprüfen, ob das Zertifikat noch gültig ist. Das ist alles UALT. Wenn die mit HTP-S gesichert sind, da ist was abgelaufen, dann schlägt man eine Überprüfung zum Beispiel schon fehl und dann komme ich dann nie wieder raus. Jedenfalls nicht so einfach, jedenfalls nicht als normaler Nutzer. Das ist ein Grund, warum diese Seite auch per HTP-Recht für alle Informationen, die ich hier runterladen kann, die sind in sich schon kryptografisch gesichert. Also so ein CA, das ist ja irgendwie signiert, unterschrieben und auch so eine Revocation List von OCSP Response, der ist in sich kryptografisch gesichert. Dann kann ich also über eine ungesicherte Domain aufrufen. Alle Informationen da drin sind öffentlich. Aber das ist nur mal so ein kleiner Ausflug. Aber ansonsten werdet ihr wahrscheinlich keine Google-Domain finden, die nicht per HTTPS oder die per HTTPS erreichbar ist. Das dürfte die Einzige sein. Inzwischen bauen sie ja auch eine Eigen. Hier sieht man noch, dass die noch auf einer anderen aufgesetzt haben. Nein, jetzt haben sie es inzwischen schon gesichert. Aber das war nur ein kleiner Randausflug. Was vielleicht einige doch schon kennen, wer kennt Let's Encrypt. Das sind schon mehr als Observatory. Wenn wir jetzt noch dahin kommen, dass das nächste bei Observatory genauso viel hin hochgehen, weil Let's Encrypt, dann sind wir auf einem guten Weg, weil das eine ist gut. Aber ohne dass man den ganzen anderen Kram macht, dann hat man HTTPS, aber vielleicht ist es trotzdem schlecht eingestellt. Dann hat man tolle Zertifikate, die kommen auch automatisch, aber das ist halt nur die halbe Wahrheit. Und dann gab es auch auf einem 33-C3 einen schönen Vortrag zu PKIs. Und da gibt es auch einen schönen, genau, ich habe hier nicht auf Pause gedrückt, aber das ist der Vortrag. Was ist jetzt Certificate Transparency? Das ist auch so eine Art Protokollerweiterung. Das hat man deswegen gemacht, weil man eben nicht diesen ganzen PKIs vertrauen kann. Da gab es ein paar Unfälle. Das kann man sich hier in aller Schönheit in diesem Vortrag anschauen. Da gehe ich jetzt nicht weiter drauf ein. Aber es gibt jetzt heutzutage ein paar solcher Zertifikate Ausstellungseinheiten weniger, unter anderem, weil die sich nicht gut verhalten haben. Aber auch Simantec, von denen die ungefähr 75% aller Zertifikate im Internet bereitstellen, die sind gerade auf der Abschlussliste bei Google, weil sie ein paar Sachen nicht so schön gemacht haben. Und deswegen, weil man, weil diese Zertifikate-Ausstellern Betreiber nicht immer die Wahrheit sagen und auch einem nicht immer alles erzählen, hat man sich Certificate Transparency überlegt. Da passiert im Prinzip folgendes, man muss, wenn die CA ein Zertifikat ausstellt, dann schreibt ihr das in ein öffentliches Protokoll. Das macht auch Letz-Encrypt für alles, was sie tun. Das heißt, wenn ihr interne Systeme mit Letz-Encrypt-Zertifikaten versehen, dann weiß das das ganze Internet. Das ist die Kehrseite der Medaille, sollte man sich also überlegen. Wenn man Dinge hat, die man also interne Infrastrukturen nicht im Internet veröffentlichen möchte, dann sollte man dafür keine Letz-Encrypt-Zertifikate aus sich generieren. Weil dann ist das komplett öffentlich einsehbar. Der Vorteil ist von diesem Certificate Transparency, ich kriege zum Beispiel mit, wenn noch jemand ein Zertifikat für die gleiche Domain ausstellt. Und dann kann man da mal nett nachfragen gehen, was das denn soll. Aber die ganzen Details dazu gibt es in diesem Vortrag, der ist hier nur als Referenz erwähnt. Einfach nach Certificate Transparency 33 C3 Googlen, dann findet man den sehenswert, wenn man sich da weiter mit beschäftigen will. So, genau, Certificate Transparency. Dann kommen wir zurück zu HTTPS. Genau, also ist immer noch die Abkürzung für SSL, aber SSL ist tot. Das benutzt man nicht mehr, das benutzt man TLS, sozusagen der Nachfolger. Genau, da haben wir jetzt ganz viele lustige Protokoll-Versionen. Die aktuell gültige ist die 1.2, die kommende ist die 1.3. Dafür gab es auch schon Unterstützung in einigen User Agents, unter anderem wurde sie aus Chrome wieder rausgenommen, weil es Infrastruktur gibt, die die RFC nicht ordentlich implementiert hat und jetzt mit der neuen Version kollidiert. Das sind meistens so Unternehmensproxies, die HTTPS aufbrechen, um nachzugucken, dass da nichts Böses drin ist, bevor sie es ans Firmennetzwerk weitergeben. Und die haben gesagt, die haben mit 1.3 redigt nicht. Aber eigentlich hätten sie es einfach ignorieren müssen und Downgrade auf 1.2 machen müssen, das kann, aber das halbe Internet nicht. Deswegen hat man es aus dem User Agent wieder ausgebaut, weil der Chrome es halt hingegangen hat, gesagt, du kannst bestimmt 1.3, weil das ist das sicherste, was es gerade gibt. Und haben gesagt, nee, mit dir redigt nicht. Das ist natürlich blöd. Da gibt es auch einen schönen Vortrag zu TLS1.3. Die sind alle beide auf Englisch, habe ich nicht dazu gesagt. Da wird das auch in aller Tiefe besprochen. Was sind die Vorteile, was sind die Nachteile, was geht schon, was ist schiefgegangen. Das ist ein Vortrag von, ach, wie heißen sie jetzt wieder? Steht's da? Na, da stehen die Namen, weil die kennen vielleicht einen oder andere. Cloudflare, genau, so ein Anti-DDoS-CDN-Provider. Und die haben da schon ein bisschen was mitgemacht und die haben da ganz viele spannende Sachen erzählt. Gehe ich jetzt auch nicht weiter drauf ein. Hatta war auch mit dem Thema im Prinzip zu tun, sollte man sich mit beschäftigen, wenn man selber Webseiten betreibt. Kommen wir zu den Headern. Also zu den zusätzlichen Headern. Ich rede heute nicht über HTTB Headern, nur die, die irgendwas mit Security zu tun haben oder zusätzliche Dinge im User-Agent aktivieren oder auch deaktivieren. Weil früher war das Internet ja ziemlich kaputt. Und dann haben die User-Agent, also die Browser, immer alles möglich getan, um dieses kaputte HTML, JavaScript und CSS trotzdem noch zu was sinnvollem darzustellen, damit der Nutzer die Seite benutzen kann. Das ist halt manchmal auch ein Problem. So, dann gehen wir mal auf diese Header. Die wir hier gesehen haben. Fangen wir mal mit den Einfachen an. Zum Beispiel XSS Protection. Brauche ich prinzipiell erst mal nur, wenn ich JavaScript auf der Seite habe, sonst bringt das nichts. Was macht das jetzt? Hier gibt es jetzt immer diese schönen Wiki-Seiten. Da wird das ganz ausführlich erklärt. Ich mache das nur ein bisschen kurz. Es gibt einen unglücklichen Standard-Mode. Der ist so. Das heißt, wenn man XSS Protection 1 ist in Chrome, Firefox und Internet Explorer und Konsorten so der Default. Das heißt, die haben so Magic eingebaut, um fiesen JavaScript Code zu erkennen. Aber natürlich muss ich extrem fehler-tolerant sein, weil ich will die Seite ja nicht kaputt machen. So, was ist jetzt das Problem mit dem Default-Mode? Wenn er was findet, dann schmeißt das raus, macht aber weiter. Deswegen will man dieses Flag-Mode-Leicht-Block haben. Das heißt, wenn der Browser was Komisches im JavaScript findet, dann rendert er die Seite nicht. Weil sonst merke ich es ja nicht, dass da was Komisches passiert. Er macht das im Hintergrund, sagt es mir aber nicht. Deswegen sollte man den Header mitschicken, und zwar halt mit diesem Mode-Block-Flag hinten dran, dass die Seite nicht gerendert wird. Dann kann man auch noch eine Reporting-UAL aufschalten, sodass man als Betreiber selber mitkriegt, wenn komische Dinge im Klein passieren. Weil das kriege ich ja auf der Server-Seite nie mit, wenn auf dem Klein komische Sachen passieren. Das haben wir bei einigen dieser Header. Gibt es dann eine Reporting-URI, an die kann ich, wird der Klein dann also ein Protokoll zurückschicken, wenn Fehler aufgetreten sind oder komische Dinge passiert sind. Und das kann ich dann wieder auswerten und merke, ah, okay, da macht irgendwer fiese Sachen auf der Klein-Seite. Das sehe ich sonst auf dem Server nicht. Einer der einfachen, der ist auch relativ ungefähr, den kann man einfach setzen, da passiert eigentlich nichts. Natürlich sollte man es trotzdem vorhin mal ausprobieren, aber den kann man einfach so benutzen. Einen, den man auch noch einfach so benutzen kann, sind diese X-Frame-Options. Da geht es darum, wenn meine Seite, wenn ich nicht will, dass die in einer anderen Seite per iFrame eingebunden wird, dann kann ich diesen Header benutzen. Da gibt es alle möglichen JavaScript-Dinge, die funktionieren, aber nicht immer, weil ich kann in einem iFrame auch sagen, ja, so erstmal kein JavaScript ausführen, innen drin. Dann ist der Framebuster, so nennt man das, schon mal kaputt, per default. Und das Einzige, was funktioniert, ist dieser Header, weil dann macht der User-Agent das und dann macht das einfach nicht. Und den kann man einfach mitschicken. Und da kann man sagen, ah, ich will mich aber selber frame dürfen, warum auch immer, oder ich will es komplett verbieten. Der Nachteil ist natürlich, manchmal gibt es Use-Cases, in denen man Teile seiner Seite in anderen Webseiten benutzen lassen möchte. Das kann ich mit dem Header nicht machen. Da kann ich nämlich maximal eine Domain angeben. Aber dafür gibt es einen furchtbar komplizierten Header, der nennt sich CSP Content Security Policy. Da kann ich dann beliebig viele Domains angeben. Den gibt es inzwischen auch schon, ich glaube, in der dritten Version, warum man jetzt den X-Frame-Options nicht auch einfach mal erweitert, mehr Domain-Namen angeben zu können, hat mir noch keiner verraten. Aber wahrscheinlich, weil man diesen Header fördern will, der hat die gleiche Funktionalität als Sub-Funktionalität, wie der X-Frame-Options-Header. Aber ich bin flexibler, wenn ich dieses Framing zulassen will, indem ich die Wideless, ich kann also eine Wideless angeben, mit beliebig vielen Domains. Das geht bei dem nicht. Es ist prinzipiell ungefährlich, außer man weiß nicht, dass man geframed wird, wollte es aber, wenn man den X-Frame baut, dann geht es nicht mehr. Also kann ein Teil der Anwendung kaputtgehen, sollte man also vorher testen. Dann gibt es hier noch einen, das ist der aus der Vergangenheit, X-Content-Type-Options, was macht der? Wie gesagt, zum einen haben die Browser früher immer versucht, alles Mögliche zu fixen, wenn das HTML-Tag nicht geklostet und so, dann klosen die das selber und raten, das ist jetzt hier bestimmt zu Ende die Tabelle und jetzt kommt wieder anderer Content. Was die auch noch gemacht haben, weil viele Leute, das in der Vergangenheit nicht hingekriegt haben, mit X-Content-Type mitzuschicken, haben die Browser oder die User-Agent-Zeit angefangen zu raten und gucken. Also die machen Sniffing, die machen erstmal die Daten, die da kommen gucken, die in die ersten bytes rein und sagen, ah, das ist ein Bild, auch wenn es als Text geschickt wurde. Also renne ich das mal als Bild. Oder das ist irgendwas anderes. Das kann man aber auch wunderbar für Angriffe benutzen. Ist auch schon öfter in der Vergangenheit passiert. Und deswegen kann man jetzt ein Fleck mit schicken und sagen, lieber Browser, ich weiß, was ich tue. Du brauchst nicht zu raten. Wenn ich sage, das ist ein Texterteil, dann ist das ein Texterteil. Und dann renner sie als Text oder als HTML oder das ist ein JavaScript und nichts anderes. Nicht raten. Relativ ungefährlich könnte aber auch sein, dass irgendwas kaputt geht. Zudem kommen wir später. Dann gehen wir mal auf zwei, die speziell für HTTPS eingeführt wurden. Dann fangen wir mit Strict Transport Security an. Dabei geht es darum, wenn man jetzt eine URL im Browser eingibt, dann gibt man meistens einfach den Namen ein und ich will da jetzt unbedingt sicher hingehen oder unsicher per HTTPS, sondern ich gebe einfach den Domainnamen ein. Und dann geht der Browser per Default erstmal auf Port 80, also HTTPS, das unsichere Protokoll. Und dann findet heutzutage üblicherweise ein Redirect statt auf die sichere Variante, also auf HTTPS. Das ist aber angreifbar, weil der erste Request, wenn ich jetzt über eine unsichere Verbindung gehe, der kann manipuliert werden. Dann komme ich vielleicht nie da an, wo ich hin wollte. Was macht jetzt dieser Header, wenn ich den dann über HTTPS mitschicke, dann stellt er sicher, dass sich der User-Agent merkt, ah, der will da immer über eine sichere Verbindung hingehen. Und dann, wenn ich das nächste Mal die gleiche Domain eingebe, dann geht er automatisch über HTTPS dahin und dann bin ich sicher. Das nennt man auch Trust on First Use, weil der erste Kontakt zu dieser Webseite ist unsicher, aber die Nachfolgenden sind dann gesichert, weil man dieses Flag mitgeschickt hat und da gibt es aber noch ein paar Zusatzfeatures. Zum einen kann man halt sagen, wie lange soll sich der User-Agent das merken. Da gibt es so eine Empfehlung, die im Moment aktuell gültig ist, das ist ungefähr ein halbes Jahr, das gibt man in Sekunden an. Das wird hier auch dann mit bewertet bei diesen ganzen Checks. Wenn ihr jetzt hier noch mal drauf schaut, dann sieht man hier, hier gibt es einen und er ist auch in Ordnung, gibt fünf Pluspunkte, super. Allerdings können wir hier unten mal gucken, was wir da eigentlich mitschicken als Entropia, was wir jetzt ausgewählt haben als Beispiel. Wir schicken jetzt, wo ist er, genau. Hier ist das Alter in Sekunden, kann jetzt nicht mal eben umrechnen, vielleicht kann es jemand anders. So lange merkt sich der User-Agent diese Information und wenn ich innerhalb dieses Zeitraums wieder auf die gleiche Domäne gehe, dann bin ich automatisch gesichert. Jetzt habe ich gerade erzählt, der erste Kontakt zur Seite ist immer noch unsicher. Das ist der Reload dazu. Da kann man sich auf einer Seite registrieren und sagen, der Browser oder der User-Agent soll das schon wissen. Auch wenn derjenige Nutzer noch nie auf meiner Webseite war, will ich, dass er auch, wenn das erste Mal kommt, direkt über HTTPS dahin kommt. Das ist bei entropia.de auch der Fall. So, da gibt es so eine schöne Reload-Liste. Oder auch nicht, jetzt das Internet-Code. Genau. Da gibt man dann seine Domäne ein, zum Beispiel entropia.de und die prüft dann erst mal, ob man den header mit schickt. Sonst könnte ein ja irgendwer da eintragen, es wäre nicht so lustig, weil danach ist die Seite nur noch per HTTPS erreichbar. Wenn man die gar nicht auf HTTPS betreibt, wäre das nicht so schön. Deswegen, aber hier sieht man, wir stehen auf dieser Liste, die Liste hat natürlich auch wieder Nachteils, es gibt nix Gratis auf der Welt und schon gar nicht im Bereich Security, weil mit diesen HTTPS Preload-Listen und auch mit den HTTPS Cookies kann man super Cookies bauen zum User-Tracken. Und das kann man auch nicht verhindern, weil das kann man dann wieder mit JavaScript clever prüfen und kriegt dann halt auch und kann sich eine Bitmaske bauen. Ob der User dann schon mal dort war oder nicht, dann kriegt man halt eine andere Antwort zurück. Kann man auch in einigen Blogposts und Vorträgen sich im Detail anschauen, wie das funktioniert. Das hat der Nachteil davon. Kann man aber nicht vermeiden, der ist designbedingend. Ja, gibt nix Gratis auf der Welt. Genau, wie funktioniert das dann, wenn man also, man muss ein paar Vorbedingungen erfüllen. Hab jetzt gesehen, wir haben kein Includes-Up-Domains und wir haben auch kein Preload drin. Wieso stehen wir trotzdem auf der Liste, weil wir haben das schon vor langer Zeit gemacht. Als das noch ganz neu war, da gab es noch nicht so viele Randbedingungen. Inzwischen ist das so. Man muss einmal eine bestimmte Mindestgröße beim Alter erfüllen. Man muss Includes-Up-Domains als Flagg mit schicken. Was macht Includes-Up-Domains? Wenn ich jetzt Entropia.de hab und dieser User-Agent, der das einmal bekommen hat, auf alle Domains, also auf alle Subdomains, zum Beispiel Test.Entropia.de oder wiki.Entropia.de oder meine interne Domain.Entropia.de nur noch per HTTPS zugreifen und es gibt keinen Ausweg. Außer wieder von der Liste runterzukommen, was ungefähr zwei Monate dauert. Solange ist es dann kaputt und man muss ganz schnell interne HTTPS aufbauen. Deswegen, man kann diese Header benutzen, man sollte sie aber mit Sinn und Verstand benutzen, sonst kann es weh tun. In größeren Unternehmen, was weiß ich, wenn man jetzt ein großer Konzern.de wäre und schickt da diesen Header mit, dann gehen plötzlich interne Seiten nicht mehr, weil die irgendwas, punktint.großerkonzern.de heißen. Das ist auch ein spannender Angriffsvektor, weil wer prüft denn jeden Tag, was seine Webseite für Header da nach draußen und die User-Agent raus schickt? Wer macht das? Einer. Das ist auch noch ein lustiger Angriffsvektor nachher für diesen anderen Header mit dem Public Key Pinning. Da kann man dann auch viel Spaß haben. Also wenn jetzt jemand den Server hackt und gemeint ist, dann schickt er halt erst mal eine ganze Weile irgendwelche Header mit, da komme ich nachher noch drauf bei dem Public Key Pinning und irgendwann schickt er ein Erpressabbrief und dann tut es weh. Deswegen sollte man ab und zu mal checken, was die eigene Webseite so für Header nach draußen in die Welt schickt, weil es könnte sonst in der Zukunft sondern genehm werden. Weil dann keiner mehr auf die Domain zugreifen kann. Da kommen wir gleich zu, wie das geht. Also dieses Inclus-Subdomain-Fleck, das kann man immer setzen oder weglassen, aber wenn man das setzt, sollte man wissen, was man tut. Und dann gibt es halt noch dieses Spreeload-Fleck, das setzt man nur, wenn man auf diese Liste will. Wenn man das nicht setzt, kommt man nicht auf die Liste. Genau. Aber diese drei Bedingungen muss man erfüllen. Das Max-Edge muss ein bestimmendes Mindestgrößer haben. Hier unten steht das auch nochmal, also 5 Minuten funktioniert nicht. Und Inclus-Subdomains muss drin sein und das Spreeload-Fleck muss gesetzt. Und dann kann man das hier eintragen. Und dann dauert es ungefähr 2 Monate, bis es funktioniert. Warum dauert das so lange? Weil das ist hardcoded im Sourcecode des Browsers. Kann man auch auf JitHub sich die Liste angucken. Das wird also hart in den Chromium und dann auch in den Chromien einkompiliert. Deswegen dauert es ungefähr 1 bis 2 Monate, bis man drauf ist. Und wenn man dann hinterher feststellt, dass man ein paar internal Domainzungen dauert, ist ungefähr 1 bis 2 Monate, bis man wieder runter ist. Solange ist es dann kaputt. Und die werden keinen Release machen, nur weil irgendwer zu blöd war, seine Infrastruktur zu maintainen. Google ganz bestimmt nicht. Kann man viele Image schreiben? Das hilft nicht. Also braucht man auch nicht unbedingt. Aber wenn man das machen will, sollte man vorher schauen, ob man das wirklich haben will. So. Dann haben wir diesen anderen Ominoisenheader, der sich da Public Key Pining nennt. Warum ist er optional? Da kann man auch ganz viel falsch machen und dann tut es weh. Also im Prinzip wieder Self DOS Option. Wenn man es falsch macht, ist die Seite nicht mehr von außen erreichbar. Warum ist die nicht mehr von außen erreichbar? Was der Header macht, also der pinned Public Keys, hat irgendetwas mit Zertifikanten zu tun, weil die benutzen Public und Private Keys. Da kann man, weil das Ganze mit den PKIs nicht so einfach ist, oder man den vielleicht nicht allen vertrauen will, weil irgendwie es gibt so viele davon auf der Welt. Und ich sage, ich will aber nur zwei. Es gibt zwei, denen ich vertraue. Dann kann man einmal den Public Key der CA, der RUCA sozusagen, das ist ja immer so ein Baum. Und dann sagt man, okay, ich möchte jetzt nur noch Zertifikaten, denn dieser Agent soll meine Domain nur noch vertrauen, wenn die von der CA ausgestellt ist, die ich hier, wo ich ein Hash von diesem Key den schicke ich mit. Das sieht dann ungefähr so aus. Man muss ja auch immer zwei mit schicken, warum ja gleich auch gleich. Ich mache es mal ein bisschen größer. Das war zu groß. Genau. Also man kann das oben machen. Man kann das aber auch auf dem eigenen Zertifikat machen. Hier ist auch dieses Letz-Encrypt Beispiel. Das ist schon ganz praktisch, weil wenn ich das mit dem eigenen Zertifikat mache. Und das muss man bei Letz-Encrypt ja alle 90 Tage erneuern, wenn das dann automatisch passiert. Und man addert den header nicht. Das ist blöd. Dann ist man nämlich offline, weil dann geht da keiner mehr hin. Jetzt können wir mal auf diese Fehldomain kurz schauen. Weil das ist ganz schön. Weil wenn man diese header mit schickt, passiert noch was. Also einmal jetzt sieht man hier, ja, es ist irgendwas komisch noch hier. In dem Fall auch mit dem Zertifikat. Das erkennt er nicht. Und dann gibt es hier immer diesen Advanced-Button. Und dann gibt es hier unten dieses, ich weiß, was ich tue, Button. Lass mich da hin. Ich bin schon groß. Dann kommt man trotzdem auf die Seite. Wenn man jetzt diese header mit schickt. Mist. Ja, genau. Jetzt habe ich mir das hier gemerkt. Dann geht das plötzlich nicht mehr. Hier ist irgendwas kaputt. Dann klick ich auf den Advanced-Button. Jetzt ist hier aber kein ... Ich weiß schon, was ich tue. Die Seite ist offline für den Nutzer. Da kommt da nicht mehr hin. Ha? Ja, gleich. Also, ich habe das hier auch mal gemacht. Wenn ich jetzt mal dieses Subdomain da weg mache, da ist ein Zertifikat drin. Dann geht es. Wenn ich jetzt auf dieses Subdomain gehe, oder auf dies, egal, kann man irgendeine nehmen. Dann geht es nicht. Weil dieser hier steht das. You cannot visit, bla, bla, bla. Weil die Seite schickt ein HSTS-Header mit. Das heißt, die haben gesagt, die wissen, was sie tun. Und wenn da jetzt unterwegs was Komisches passiert, dann ist entweder ein Angriff oder sie waren zu blöd. Und das, ja, dennächst wahrscheinlich schnell wieder funktionieren. Das ist ja fast fehl. Man kriegt dann ganz viel Rückmeldung, dass die Seite down ist über Twitter, was weiß ich. Und kann dann gucken, was man falsch gemacht hat. Also, das ist halt auch von diesen beiden Headern. Die haben halt so kleine Seiteneffekte. Der Useragen verändert sein Verhalten. Und das verändert zum Beispiel auch dieses Verhalten im Fehlerfall. Und lässt einen nicht mehr dahin, weil man davon ausgeht, dass irgendwer Dinge manipuliert, ihr nicht manipulieren soll. Deswegen, das sind nützliche Dinge. Aber man sollte vorsichtig damit umgehen und wissen, was man tut. Hier sieht man jetzt, man kann das auch wieder. Da kann sich das eine Zeit lang merken. Deswegen gibt es Leute, die machen diese HPKP, nennt sich das, also Public Key Pins, relativ kurz. Das ist auch wieder Trust and First Use. Weil diesen Pin kriege ich ja auch erst, wenn ich das erste Mal auf der Seite war. Google hat jetzt den Vorteil. Im Chrome, die schreiben ihre Pins auch da rein. Also nicht mehr Pins, die sind dann auch vorher schon bekannt. Dadurch merken die auch, wenn jemand ein Zertifikat ausstellt, der sie vorher nicht gefragt hat. Und schicken dann böse Briefe an die CA. Das ist den meisten Menschen wie uns nicht möglich. Aber das hat auch so ein Trust and First Use Header. Weil den sieht der User Agent das erste Mal, wenn er diese Nachricht vom Server über HTTPS bekommen hat. Und dann kann er sich das wieder eine bestimmte Zeit lang merken. Wenn man da jetzt zum Beispiel nur 300 Sekunden reinschreibt oder 600, das irgendwie 10 Minuten sind, dann sagen wir, was soll das? Dann bin ich wenigstens für die Session sicher. Das heißt, solange der User auf der Anwendung oder der Webseite aktiv ist und alle 10 Minuten mindestens einmal klickt, kann ihm unten drunter keiner das Zertifikat austauschen. Aber wenn was schief geht, geht es nach Spätestens 5 Minuten oder 10 Minuten wieder. Das ist der Vorteil, wenn man da eine kleine Zahl reinschreibt. Das kann man hier auch wieder sagen, ah, das soll auch für alles Hub Domains gehen. Mit dem Flex sollte man zurückhaltend umgehen, wenn man nicht weiß, was man tut oder das vorher sehr intensiv testen. Und dann gibt es diese Pins. Und davon muss man mindestens 2 haben. Und der Hauptgrund ist halt, wenn jetzt mit meinem Hauptschlüssel was passiert, also mit dem aktuellen Keypad, was unter dem Zertifikat liegt. Und ich muss das kurzfristig tauschen, dann habe ich ein Problem, weil die User Agent da draußen wissen das ja nicht, dass ich das muss. Deswegen soll man sich so ein Reserve Schlüsselpaar an die Seite packen und leg den Hashtag schon mit rein. Weil dann kann man von diesem neuen Schlüsselpaar ein neues Zertifikat anfragen und unterzeichnen lassen von der CA. Und dann kann man das einfach austauschen. Warum braucht man das? Man braucht es so wegen Hard Lead. Also wenn so eine SSL-Librerie oder so kaputt geht und plötzlich die Private Keydaten im Internet abrufbar sind, dann will man seinen Schlüssel tauschen. Und das ist jetzt nicht fiktiv, das ist ja erst passiert. Also das ist nicht mal ein Angriffsszenario in dem Sinne, sondern da ist halt was kaputt gegangen. Und dann muss man das kurzfristig reparieren. Deswegen braucht man mindestens 2 von diesen Pins. Man kann aber beliebig viele reinpacken. Und deswegen will man je nachdem wie sicher oder wie kritisch das ist, vielleicht auch einfach nur die CA-Pin und kann sich jederzeit eine neue Zertifikat holen. Und das ist dann auch akzeptiert, weil einfach der CA vertraut wird. Man kann auch bei beliebigen Stufen dazwischen hier über diesen Pin an die Seite hängen. Und dann, wenn jetzt wieder so eine Zwischen-CA ein Test sub-CA ausstellt, die alle Zertifikate ausstehen darf, dann ist man ein bisschen sicherer vor so State-Level-Angriffen, die vielleicht eine sub-CA haben von großen CA's und sich selber Zertifikate ausstellen können. Das wird dann halt schwieriger oder unmöglich. Natürlich, das hatten wir vorhin schon bei dem TLS-1-3, gibt es wieder so Unternehmensproxies, die HTTPS-Verbindungen aufbrechen. Und dann hat man ja eine eigene Route-CA da drinnen, eine Interne. Und da wird das ignoriert, weil sonst wäre es ja direkt kaputt. Also liefert auch nur begrenzte Sicherheit der Helder. Und vor allem, wenn wir jetzt diesen Header angucken und diese Keys angucken, dann kann man sich vielleicht auch das Angriffsszenario vorstellen. Also wenn jetzt jemand den Web-Server hackt und diesen Header raus schicken kann, dann schickt er natürlich erstmal den Header vom aktuellen Zertifikat mit raus. Und dann schickt er noch ein Pin mit von seinem eigenen Key. Und irgendwann in der Zukunft in zwei, drei Monaten löschter den Key von dem richtigen Zertifikat raus und dann ist die Seite offline. Und ihr habt keine Chance, hier wieder online zu kriegen. Hat noch keiner gemacht, aber das ist dann die nächste Stufe. Also das ist total unauffällig, wenn ich diese Header nicht prüfe. Regelmäßig kriege ich davon nichts mit. Bis zu dem Tag, wo der Angreifer sagt, so, jetzt halte ich die Hand auf. Und wenn das dann domain ist, ja, man kann dann noch hinten was mit DNS und so machen, dass man das woanders hin routet. Also da wird ja nicht die ganze Infrastruktur angreifen können auf einmal. Aber je nachdem, wie lange erzeit hat, das zu tun, kann das halt auf relativ viele Server deployen. Aber natürlich kann man dann über DNS, die IP, also die DNS-Auflösung woanders hinrouten und dort ein neues System. Aber man hat irgendwie Arbeit erst mal, ist eine Weile offline. Je nachdem, wie schnell man gegenmaßlich weiterhalten kann. Hat auch noch keiner gemacht, aber das ist auch so eine Kritik an dem Header. Weil das im Prinzip, weil jedes Angriffsszenario ist und je nachdem, wie gut oder schlecht man ist, hat man eben wenig oder keine Handlungsmöglichkeiten für mehrere Tage. Ja, Frage? Nein. Aber es ist so, die ganzen Header, wenn man wieder eine Verbindung hinkriegt, wie auch immer, auch bei dem HTS, sobald der User-Age eine neue Version, also den Header wiederkriegt mit einer kleineren Zahl, dann gilt die kleine Zahl. Aber ich muss ja erst mal dahin kommen, dass da überhaupt eine Verbindung wieder aufbaut zu der Seite. Ich wiederhole die Frage nochmal für den Stream. Die erste Frage war, ich habe es sich schon vergessen, ob es ein Maximum für Max-Age gibt. Also erst mal nein, aber natürlich irgendwie in 32, 64 und so schon. So technisch Maximum gibt es ja schon. Im Standard steht aber, glaube ich, keiner drin. Das ist jetzt aber nicht wissen, das sage ich jetzt nicht im Kopf. Aber jemand im Publikum sagt, im Standard steht nichts. Aber manche Browser limitieren es. Also, aber wie gesagt, das ist halt auch nicht ganz ungefährlich. Und wegen den 90 Tagen von Let's Encrypt limitieren das jetzt einige, vielleicht immer auf zwei Monate, damit es dann im Worst Case nach einem Monat wieder geht. Weil man Tauschsteller uns sagt, wenn man gerade vorher den Header geschickt hat, ist ja noch ein Monat nach hinten immer noch Luft. Aber das trifft dann ja auch nicht alle User, sondern nur die, die zuletzt auf der Seite waren. Aber das soll einerseits schützen, aber andererseits kann man dafür falsch machen oder sozusagen einen eigenen Selbst-DOS, Denial of Service durchführen, weil man diese Header nicht richtig benutzt. Oder halt dachte, das ist eine tolle Idee, aber leider hat man es falsch implementiert. So, das waren die beiden. Dann haben wir CSP. CSP ist auch ganz toll, weil es ist erst mal unglaublich komplex. Und deswegen haben sich natürlich Leute in der Forschung gedacht, ja, gucken wir doch mal, bringt das überhaupt, was damit gemacht wird. Und das habe ich auch schon mal aufgemacht. Ich muss es nur wiederfinden. Ach ja, hier, schöner Titel. Gibt auch einen Grund dafür, weil diese White Lists sind halt auch angreifbar. Ich erzähle gleich, wie der CSP da funktioniert. Und das ist jetzt ungefähr ein Jahr alt, dann nicht ganz. Und was haben die gemacht? Die haben mal geguckt, was für CSP-Header werden denn überhaupt in der Realität eingesetzt? Und so wie die eingesetzt werden, sind die denn sicher? Sind sie nicht? 96% aller Headers, so wie sie aktuell benutzt werden oder zum Zeitpunkt der Studie, sind wertlos. Das kann man sich dann aufwärmen, sind nur 20 Minuten. Die erzählen das dann, warum, wieso, weshalb. Der Sebastian Leckis, der war ja auch mal hier in Karlsruhe, der hat ja auch mal einen Vortrag gehalten, ist jetzt bei Google und die haben das schön auseinandergenommen, analysiert, aber auch einen Vorschlag gemacht, wie man es besser machen kann. Deswegen gibt es jetzt schon den Header in Version 1.3, weil da wieder neue Flex drin sind, wie man das dann doch sicher bekommt, diese White Lists. Weil White Lists sind ja an sich schon mal eine gute Idee. Die funktionieren auch besser als Black Lists in der Security, also etwas explizit erlauben, anstelle irgendwas Unbekanntes verbieten. Das ist ein sinnloser Kampf. Sollte man immer vermeiden, Black Lists funktionieren nicht. Also ich verbiete irgendwas und weiß aber nicht, was ich zulasse. Im Gegensatz zu White Lists bedeutet, ich erlaube explizit zum Beispiel ein bestimmtes Alphabet und so ist es zum Beispiel Markdown. Da habe ich ganz explizite Steuerzeichen, die mir dann Formatierung machen. Aber die können nichts mehr als eine sehr limitierte Kramatik. Werden HTML mit CSS zusammen Yaturing kompliziert ist, also ein komplettes Programmiersystem. Ich brauche kein JavaScript heutzutage, ich brauche nur HTML5 und CSS3. Damit kann ich komplett programmieren. Es gibt schon Implementierungen von bestimmten Dingen damit. Also Linux Emulator läuft nicht. Ja, man kann auf jeden Fall unglaublich viel machen und das, wo man denkt, das ist ja nur eine Auszeichnungssprache, ist es aber nicht. Also ohne JavaScript kann man damit schon ganz extrem viele Dinge tun, auch wenn es vielleicht dann nicht 100% Touring kompliziert ist. Also der Kommentar am Publikum war gerade, jemand hat sich den Beweis angeschaut und glaubt ihm nicht, dass es irgendwo einen Fehler gibt. Aber im Prinzip ist das schon mal gut. Und hier ist jetzt beschrieben, was ist das Problem mit der Version des Headers vom letzten Jahr und deswegen gibt es jetzt ein neues Flag mit dem alles besser ist. Jetzt gucken wir mal kurz auf den Header, weil der ist unglaublich komplex. Da habe ich auch eine Folie zu, das kann man weglassen. Genau, merken wir sonst immer nicht. Das ist schon ein bisschen älter, aber da sieht man mal, wie komplex dieser Header werden kann. Es gibt da ganz viele Möglichkeiten. Man kann damit also alles Mögliche steuern, was die Anwendung anzieht. Also ich mache das mal ein bisschen größer, dann kann man es besser lesen. Es gibt irgendwie Default Settings, die greifen auf alle Elemente, die irgendwas mit Source zu tun haben. Also Dinge, die die Anwendung irgendwie lädt. Bilder, JavaScript, CSS, Bilder, Phone Dateien, Verbindung zu anderen Uris, Media Files, Objekte, Framing, das ist vorhin dieses X Framing. Hier kann ich eine Weitliste angeben, also kann mehr als einer Domäne erlauben, mich zu iframe. Und dann gibt es noch diese Report Uri. Also ich kann hier komplett steuern, wo dürfen meine Bilder herkommen? Und dann gibt es in der Regel, egal woher, jeder kann Bilder in meine Seite reinschieben und der User-Agent-Render, die dann auch, ich kann sagen, muss irgendwie von derselben Quelle kommen. Es gibt ja auch diese Base64-Encoding, das kann ich erlauben oder verbieten. Und dann kann ich halt hier die Domäne sagen, es ist halt ganz spannend für CDNs und so was, sodass ich sagen kann, ja aber bitte nur von mir selber, also Self gibt es auch immer, oder CDN. Ich sage, ich habe aber keine Bilder auf meiner Seite, dann sind halt keine erlaubt, dann kann auch keiner eins da reinkriegen. Oder ich habe kein JavaScript auf meiner Seite, dann kann ich auch sagen, nee will ich aber nicht. Hier ist jetzt noch ein bisschen mehr, dann hat man auch wieder Self, also nur von mir selber. Aber da dann nur per Datei, also wirklich per Source, dann kann ich nur sagen, okay, wieder diese Base64 oder Inline. Das Inline hat dann schon, das heißt dann schon Insecure Inline, weil wenn ich Inline-Javascript habe oder Inline-CSS habe, ist das per Default eine blöde Idee. Weil dann kann der User-Agent nicht mehr unterscheiden, hat die Anwendung das da reingelegt oder jemand anders? Über ein XSS zum Beispiel, es ist nicht entscheidbar für den User-Agent und dann muss das ausführen. Dafür gibt es aber auch eine Lösung, man kann das dann mit Nancy's und Hash sichern, also die Inline-Blöcke absichern und dann aber in dem Hedder muss man nochmal ein Hash mit schicken, ist ganz furchtbar eklig. Also deswegen am besten keine Seiten mit Inline-Javascript und Inline-CSS bauen. Also sowieso nicht, weil schwierig abzusichern. Aber wenn man es schon muss, dann kann man hier dann noch bestimmte Maßnahmen ergreifen, um das zu sichern. Und dann gibt es ja hier diese böse Evil-Funktion noch, wie in vielen Skript-Sprachen, die sollte man nach Möglichkeit auch niemals benutzen, auch wenn sie da ist. Aber wenn es nicht anders geht, dann kann man sie auch erlauben. Ja, und das sieht dann immer so ähnlich aus, dann kann man hier so Dinge zusammenklicken und dann generiert einem so ein Hedder, die können furchtbar komplex werden. Schauen wir mal auf so ein Beispiel. Wie sieht sowas aus? Genau, hier sind die Examples, also die werden jetzt auch ein bisschen größer, die Beispiele. Also so ganz einfache gibt es natürlich auch. Zum Beispiel man kann sagen, man muss immer über HTTPS geladen werden. Man kann damit bestimmte basic Dinge steuern. Man kann zum Beispiel auch eine ganz alte Anwendung, die man hat und jetzt auf HTTPS heben will. Und da sind ganz viele hardcoded HTTP-Links drin. Dann gibt es auch ein Flag, das heißt Upgrade Insecure Requests. Da macht der User-Agent alles nur noch auf HTTPS. Das ist natürlich blöd, wenn man externe Datenquellen angebunden hat, die nur per HTTPS. Und der macht das dann für alles, kann also auch wieder weh tun. Das sieht man bei vielen Media-Konzern. Da sind viele noch auf HTTPS, weil diese Content-Zulieferer oder Werbenetzwerke das noch nicht geschafft haben. Dann können die nicht switchen, wobei eine ganze Menge inzwischen schon auch per HTTPS erreichbar sind. Heise hat das ja jetzt auch mal geschafft nach langer Zeit. Und überraschenderweise auch so eine böse Seite, die Welt.de heißt, ist mir letztens aufgefallen. Die wird jetzt per HTTPS ausgeliefert, hätte ich nicht gedacht. Andere haben das noch nicht, Zeit.de kann es noch nicht. Die sind noch auf HTTPS unterwegs. Aber es ist halt nicht so trivial. Und hier sieht man dann okay, Default Source Self, also alles nur von mir selber. Und dann braucht man eigentlich Image Source Self nicht nochmal, aber in dem Fall schon. Weil dann hier zum Beispiel noch eine zweite Domain erlaubt, dass von der auch Bilder in die Seite eingebunden werden können. Insbesondere für JavaScript und CSS ist das natürlich spannend, weil das Angriffe von draußen deutlich schwerer macht. Weil dann ist es ja oft so, wenn man kein Inline-Javascript injecten kann, dass irgendwo anders dann ein böses JavaScript-File liegt. Und das wird dann einfach mitgeladen. Wenn ich die Domain aber nicht erlaubt habe, passiert das nicht. Deswegen ist das eigentlich eine ganz gute Idee. Und in dem anderen Vortrag, den ich vorhin gezeigt habe, wird erklärt, warum es nicht funktioniert. Ja, so ist das mit der Security. Genau. Also, hier sind jetzt ein paar Beispiele, wie das aussehen kann und wie das dann funktioniert. Hier gibt es noch ein paar mehr, hier gibt es noch ein Playground, da kann man das ausprobieren und so weiter. Jetzt haben wir noch ein paar Headphones, genau zwei. So, was haben wir jetzt hier noch? Also Cookies und Cost Origin Resource Sharing lassen wir jetzt mal weg. Jetzt gibt es Redirection. Das ist einfach nur eine Funktion, dass wenn man per HTTP kommt, man auf HTTPS redirectet wird. Und jetzt gibt es neue Referra-Policy und Sub-Resource Integrity. Was ist das jetzt schon wieder? Jetzt im CSP kann ich ja zumindest sagen, okay, das JavaScript von Angular will ich vom Google CDN laden. Das ist ja per se mal eine nette Idee, weil dann liegt es vielleicht schon im Cash von meinem Browser. Aber wenn jetzt jemand, was ja auch schon vorgekommen ist, die Domain verbiegt per BGP oder so, so nationwide Angriffe, oder ja, dann kriege ich vielleicht ein anderes JavaScript-File zurückgeliefert. Da kommt jetzt Sub-Resource Integrity ins Spiel, weil wenn ich so externe Dinge in meine Seite einbinde, insbesondere JavaScript, weiß ich ja nie, ob morgen noch die gleiche Datei kommt wie gestern. Und dafür ist das Ding da. Jetzt kann ich also ein Hash über diese externe Datei berechnen und den schicke ich mit an den User-Agent. Und wenn der jetzt meckt, oh, das passt nicht mehr, dann lädt das nicht. Das schließt dann solche, das ist genau für solche Angriffe gedacht. Macht mir aber natürlich die Arbeit wieder schwerer, wenn ich immer auf Latest gehe oder sowas. Oder wenn ich sage, ah, da gibt es eine neue Version, ich ende einfach meine Source in der Anwendung, mache ein neues Deployment, kaputt. Weil ich muss den Herder auch mit anpassen, sonst funktioniert es nicht. Also hier ist auch das Beispiel, Java mit jQuery, oder halt, ja, gibt ja alle möglichen Frameworks, die inzwischen über ein CDN ausgeruht sind. Und man bindet die dann über das CDN ein und hostet sie halt nicht auf seiner eigenen Seite. Das wäre halt eigentlich die richtige Variante. Aber die ist natürlich auch mit viel Aufwand verbunden, macht mehr Traffic und so weiter. Es gibt also gute Gründe, das so zu tun, ich habe es gesehen, gleich. Aber das macht dann natürlich auch mehr Arbeit, wenn ich so releases mache. Und wenn ich sehr oft releases mache und nicht darauf achte, kann das wieder weh tun. Ich bin dann zwar unglaublich sicher, aber meine Anwendung geht vielleicht nicht mehr. Das ist auch wieder ein Herder, ja. Ja, die ganzen Herder kannst du immer als Metathack im HTML-Header mit schicken, das geht immer. Ah, das ist tatsächlich nur im HTML, stimmt, das ist gar kein Herder. Aber es ist trotzdem wichtig. Stimmt, das ist in dem Fall, es ist direkt im Source Code der Seite. Aber macht im Prinzip das Gleiche wie das Public-Keep-Hining, nur halt über Quatext. Und hier kommt auch noch ein bisschen das Cross-Origin rein, wenn ich da Dinge mache. Also das wird unglaublich komplex, heute noch eine Anwendung sicher zu kriegen. Also diese zusätzlichen Sicherheitsfeatures zu benutzen, ist nicht ganz trivial. Das ist auch wieder ein Generator, natürlich wenn ich einen Framework habe, dann generiert er einfach, ruft er vor, die URL ab und generiert einen Hash, dann kann ich es auch weglassen. Ja, weil dann ist es auch, wenn da was anderes liegt, als ich dachte, dann plötzlich Valide. Oder man macht das halt nur beim Release, natürlich, dann ändert sich es zwischendrin nicht. Aber es gibt so Frameworks, die machen das automatisch, dann kann ich es auch weglassen. Das bringt dann keine Sicherheit, das sieht dann zwar schick aus, hat aber keinen Mehrwert. Der Server war es vorher geprüft hat, ja. Ja, der Kommentar ist, das bringt was, wenn der Usation in einem anderen Netzwerk als der Server ist. Aber man muss vorsichtig mit umgehen, weil vielleicht sind beide ... Der Server kann ja auch was Falsches zurückkriegen. Also ja, aber man sollte vorsichtig mit umgehen. So, dann haben wir noch, das ist jetzt aber tatsächlich wieder ein Header. Aber man kann das auch nicht so ganz trennen, deswegen ist das schön, dass das hier alles auf einer Seite war. Im Prinzip muss man das alles machen. Jetzt gibt es hier noch die Referralpolicy, die war, glaube ich, wieder ein echter Header. Da kann ich jetzt steuern, das ist ein echter Header. Hier kann ich jetzt, jetzt ist man in der Lage, als Betreiber der Anwendung oder der Webseite zu steuern, was der UserAsient mit den Referral-Informationen macht. Weil jetzt kann ich sagen, nee, don't, oder immer, alles. Und mit dem Header kann ich jetzt, hier gibt es so Strict Origin, wenn Cross Origin sind auch nicht in allen UserAsient alles gleich implementiert, da muss man also ein bisschen nachlesen. Aber man kann jetzt sagen, okay, ich schicke keinen Referrer mit, wenn sich die Origin verändert hat, so vereinfacht dargestellt. Oder schicke nur mit, dass du auf der Domain warst, aber nicht mehr die Sub-Uri, also die Sub-Fade nicht mit schicken oder keine Parameter mit schicken. Das kann man jetzt damit steuern. Das ist ganz nett aus Privacy-Sicht, natürlich. Genau, jetzt sind wir alle Header durch, jetzt kommen wir noch auf zwei, drei Tools. Also jetzt haben wir das SSL-Labs schon gesehen, das macht halt so eine Analyse von SSL-Settings oder TLS-Settings, wer die korrektere bezeichnet, heißt aber auch noch SSL-Labs, weil es gibt es schon länger, etablierter Name, Marketing, Markennamen ändert man nicht, einfach so findet keine Sau wieder. Wenn man jetzt TLS-Labs draus macht, findet das keiner. Deswegen heißt es noch SSL-Labs, auch wenn es SSL quasi tot ist. Ihr seht, Entropia kann man auch per IPv6 erreichen, ein kleines Gimmick am Rande. Wenn man da jetzt drauf geht, dann kriegt man ganz unglaublich viele Informationen einmal zum Zertifikat. Wir benutzen auch letztendlich, welche TLS-Versionen unterstützt werden, welche Algorithmen unterstützt werden und dann auch welche User Agents wahrscheinlich damit funktionieren. Das ist halt auch ganz nett, wenn man da jetzt dran rum spielt und doch noch irgendwas ganz altes Android unterstützen muss, weil die Mobile-Hersteller das Zeug nicht updaten. Kann man hier nachgucken, ob die User dann vielleicht nicht mehr auf die Seite kommen. Aber da hat man seine Statistiken für, kann man vorher schauen, ob da überhaupt jemand mit dem User Agent noch kommt. Aber das ist halt auch ein Problem, wenn ich an diesen TLS-Settings rumspiele, kommt vielleicht nicht mehr jeder auf die Seite, je nachdem, was dafür ein Endgerät hat. Dann gibt es alle möglichen Angriffe und die checken hier auch auf bestimmte Header, aber nur auf die HTS und HPKP, also die Public Keypinning Header, die anderen interessieren die jetzt wieder nicht, weil die gucken halt hauptsächlich auf die ganzen TLS- und Zertifikate-Settings. Dann gibt es eine ganz nette Seite auch, die ist auch sehr übersichtige Security-Headers, I.O. Da schauen wir auch mal kurz drauf, weil der hat auch noch was gebaut für diese Reporting-Geschichten. Genau, sieht man jetzt, es gibt hier diese ganzen Header, XSS, Referral Policy, Public Keypinning-Content Security, haben wir uns alle angeguckt. Man sieht hier auch wieder, was schickt deshalb eigentlich, welche fehlen. Und er hat hier auch ganz nette Blockpost geschrieben, die sind manchmal ein bisschen ausführlicher, als die Mozilla Entwicklerhilfe, auch ein bisschen nachvollziehbarer beschrieben. Die sind zum Teil auch schon ein bisschen älter, das macht aber nichts, die sind trotzdem gut und valide. Man muss halt nur gucken, CSP gibt es halt jetzt schon in zwei Versionen weiterentwickelt, als dieser Artikelart ist. Hier ist das auch noch mal schön beschrieben. Was macht man da, wozu braucht man das, wie kann man das testen? Genau, das ist auch noch ein guter Hinweis hier in den Chrome-Entwicklertour, sieht man auch immer schön. Wenn der Browser ein Fehler findet, dann kann man sich das hier schön anzeigen lassen. Ich zeige das gleich nochmal. Das ist das, was passiert, wenn man jetzt so eine Report-Uri mitangibt, die machst du mal größer, weil da habe ich das noch nicht drüber gesprochen. Das kann man bei einigen, das kann man beim CSP-Header machen, das kann man aber auch bei dem HST, nee, da weiß ich nicht. Beim Public Keeping kann man das machen, und zwar noch ein drittes, das habe ich jetzt vergessen. Es gibt noch OCSP-Stapling und so, es gibt inzwischen einige, wo man jetzt eine Report-Uri anhängt. Man kann auch erstmal nur Content-Security-Policy-Report-Only machen, wenn man erstmal testen will, was alles kaputt geht, wenn man es einschalten würde. Aber wenn man es aktiv hat, kann man halt auch diese Report-Uri als Flack hinten dranhängen, weil dann kriegt man mit, wenn auf der Klein-Seite Dinge passieren, die da nicht passieren sollen, weil das sehe ich sonst auf der Server-Seite nicht. Je nachdem, wie viel Traffic auf der Seite ist, sollte diese Report-Uri aber auch ein bisschen Responses aushalten, weil das schickt ja jeder Klein dann irgendwie Sachen hin, wenn was passiert. Oder wenn ich ein Update gemacht habe und dann die Hälfte der Anwendung nicht mehr geht, dann kriege ich da vielleicht ein DDoS auf diese Report-Uri, den ich mir aber selbst gebaut habe. Ja, der Kommentar ist, das hat Scott Helmi, der das gebaut hat, auch schon selber geschafft. Wobei das in der Cloud lag, es hat ihn nicht direkt getroffen, in dem Sinne, da liegt ein Cloud-Service drunter. Genau. Und der Browser, der schickt dann quasi hier so ein JSON-Snippet an diese Uri zurück. Und da steht halt drin, was passiert ist. Und das Gleiche sieht man im Prinzip auch in den Dev-Tools von den Browsern, im Chrome oder in Firefox oder in anderen Browsern. Und kann dann analysieren, was schiefgegangen ist und es reparieren. Genau. Und dafür hat er dann auch ein Service gebaut, den mache ich mal kurz auf, weil das will man vielleicht nicht alles selber bauen. Da muss man halt wieder ein bisschen aufpassen, weil das ist jetzt wieder so ein extra Service, der schickt der User-Age und Daten von der Anwendung hin, der schickt da auch den ganzen Request hin, also zumindest den Get-Request oder die URL. Der hat das aber ganz gut gebaut, weil er macht ja Security. Das heißt, er schmeißt bestimmte Dinge per Default weg, wenn die ankommen, wie die Request-Parameter. Aber natürlich kann man sie auch behalten, wenn man will. Aber er liegt halt nicht auf der eigenen Domain. Es könnten da auch interne Informationen der Anwendung hin gelangen, an diese Report UI. Sollte man schon darauf achten, welche man da angibt, weil der User-Age den Schick das sorgt. Ihr habt ja gesagt, der soll das machen. Und das per HTTPS gesichert übertragen. Aber das ist ganz nett, weil das ist auch free for use ein bisschen. Wenn man es kommerziell nutzt, sollte man auch ein bisschen Geld überweisen, weil es kostet den guten Menschen auch Geld. Aber ansonsten kann man es zum Ausprobieren auch kostenfrei nutzen. Man muss das nicht bezahlen hier. Irgendwo gibt es eigentlich hier unten ist der Button. Aber wenn man will, dass das Service noch länger lebt, kann man überlegen, ein bisschen Geld zu überweisen. Aber man kann auch das ganze Ding ohne Geld benutzen. Aber es ist halt ganz sinnvoll, wenn man anfängt, damit zu arbeiten, wenn man sich diese ganze Logging Geschichten nicht selber bauen will. Das macht ja auch ein bisschen Arbeit. Dann hat man hier eine schöne Option, um das einfach auswerten zu können. Und man kann sich dann auch so eine Kasten Domain bauen und so ein Schnickschnack. Aber wie gesagt, man muss halt überlegen, man schickt da wieder Sachen an irgendein Dritten. Der verspricht einem wieder viel. Letztendlich nutzt er auch Cloud Services drunter. Ja, muss jeder für sich selber entscheiden, ob er das macht oder nicht oder dann auch sein Disclaimer weiter da. Übrigens, wir schicken da und da noch Sachen hin. Genau. Dann sind wir jetzt im Prinzip in Time und durch. Und ich habe ja nur mal kurz alles gezeigt. Ein bisschen mehr als eine Stunde. Das ist also absolut sinnvoll, sich damit auseinanderzusetzen. Aber jetzt bitte nicht zur Tür rausgehen und alle Header auf die Seite werfen, geht garantiert schief. Aber ich glaube, das habe ich auch deutlich gemacht. Aber es kann sehr sinnvoll sein, es kann sehr hilfreich sein. Aber man sollte viel testen und ausprobieren, bevor man das irgendwie auf seine Hauptdomain wirft oder sich interne Domains wegschießt, weil man irgendwo ein dummes Subdomainfleck gesetzt hat. Und dann kriegt man das nicht so einfach wieder weg. Wer einfach mal nur so rumspielen will ... Ach, wie heißt das denn jetzt wieder? Wie heißen denn die Chrome Internets? Internets, oder? Ah ja, hier, genau, Internets. Wer mal im Browser damit ein bisschen rumspielen will, man kann, also natürlich kann man auch mit entsprechenden Tools wie Postman oder so was oder ein Proxy dazwischen sich ja so ein Header mal injecten und gucken, was auf der Domain passiert. Aber hier gibt es auch noch eine ganze Menge andere coole Features, um Sachen zu analysieren. Aber für den HSTS und den HPKP-Header, hier kann man diese Pins eintragen. Ach so, ich mache es mal ein bisschen größer. Also hier kann man eine Domain eintragen, die das jetzt vielleicht nicht hat. Und dann sieht man, was passiert. Und dann kann man hier auch wieder irgendwie was löschen, aber nicht alles. Und hier kann man zum Beispiel jetzt Entropia DE eintragen und dann sagt er, ah, man sieht mir hier Static. Static ist das, was uns hart einkompiliert ist. Das kann man auch nicht löschen. Und hier unten ist das, was die Domain mitschickt. Wir schicken den Header gar nicht mit, weil wir halt auf der Preload Liste stehen. Ansonsten würde hier unten drin stehen. Und wenn man jetzt hier bei Add das einträgt, dann kriegt man dabei Dynamic, Entropia DE. Ja, da kann man auch noch Subdomains machen und so was. Dann trägt er das da ein. Dann sieht man hier, kriegt man hier so einen Dynamic eintragen und den kann man auch wieder löschen. Aber das ist halt nur so, das will man auch nicht seinen eigenen User zeigen, weil wir trainieren hier die ganze Zeit, dass sie nicht so ein Quatsch machen, aber die Seite ist gerade da und wenn du wieder drauf willst, dann musst du das machen. Nicht so eine gute Idee, wenn wir nicht machen, aber als Entwickler ist das manchmal ganz hilfreich. Dann kann man halt hier hingehen und jetzt Entropia DE eintragen und dann löscht er das wieder raus. Jetzt ist der Dynamic Teil wieder weg. Der Statische geht natürlich nicht weg. Ich würde das ja sonst ein bisschen absurdum fühlen. Aber so zum Rumspielen mit den zwei Headern kann man das ganz nett nutzen. Und man kann hier auch diese CT, also diese Certificate Transparency-Header, die sieht man hier bei den Events. War das bei Events? Hier kann man übrigens auch gucken, wie HTT P2 mit seiner eigenen Seite funktioniert. Falls man das aktiv hat, kann man hier schön analysieren. Und hier ... Ich glaube, das ist bei Capture. Da ist das drin. Irgendwo kann man sich da auch genau die ... Also man kann sich hier drinnen ... Ich finde es jetzt gerade nicht, die tatsächlich auf der Protokoll-Ebene angucken, wenn er mit dem Server redet. Das ist halt für CT ganz spannend, weil man das auf drei Versionen schicken. Man kann es im Certificat mit schicken. Man kann es im TLS-Header mit schicken, im Handshake. Oder man kann es als HTT P-Header mit schicken. Und dann sieht man, über welchen Kanal es kommt. Aber das ist jetzt auch nicht so richtig. Gibt es noch Fragen? Gut. Sind wir jetzt genau ... Punktlandung. Sehr schön. Ich hoffe, ihr habt ein bisschen was Neues gehört. Einige zumindest. Und benutzt mal diese lustigen Tools. Vor allem Observer-Tool ist ein super Einstieg, weil da die anderen alle unten drunter hängen. Und dann kann man da auch reingucken, kann man sehen, wo man steht, wo man hin will. Und man braucht nicht alles davon. Wenn man zum Beispiel Google die Hauptdomain-Office sieht man, die machen gar nicht so viel. Wenn man auf Mail oder andere kritischere Anwendungen geht, dann machen sie auch mehr mit den Headern und Cookies und so weiter. Und die machen auch nicht alle, die haben zum Beispiel kein CSP-Header drin. Weil da gibt es den anderen Vorteil, warum es vielleicht nicht so viel bringt, vielleicht aber doch, aber es ist auf jeden Fall nicht trivial. Also dann, schönen Dank fürs Zuhören.