Ja, hallo, liebe Hörerinnen und Hörer, willkommen beim Python-Podcast in der 26. Episode heute.
Heute ist das Thema Security, ein Thema, was ich persönlich sehr, sehr spannend finde.
Dazu haben wir natürlich auch wieder Gäste eingeladen, neben dem Jochen und mir, dem Dominik,
sind heute wieder dabei der Christian, der Toini und der Philipp. Hallo, Philipp!
Hallo!
Wie geht's euch? Stellt euch doch mal kurz vor, wer ihr denn seid, und dann erzählen wir ein bisschen was über die Folge.
Tja, wer fängt an? Also, ich bin der Jochen.
Wenn ihr diesen Podcast hört,
habt ihr mich wahrscheinlich schon einmal dabei gehabt.
Ja, okay. Also ich glaube,
das brauche ich gar nicht weiter ausführen.
Aber ich glaube, am interessantesten ist wahrscheinlich Philipp.
Der ist jetzt gerade zum ersten Mal dabei.
Genau. Ja, ich bin Philipp.
Ich habe bis vor kurzem noch
an der Uni Düsseldorf
studiert und nachher auch gelehrt
zum Thema unter anderem auch Security.
Also ich habe da die Vorlesung zur
Internetsicherheit, hieß die, glaube ich.
Oder wie haben wir sie genannt? Also intern hieß die einfach Security.
Die Security-Vorlesung
gehalten. Netzwerk haben wir sie genannt.
Also Netzwerksicherheit hieß sie offiziell.
Und bin jetzt
seit zweieinhalb Jahren arbeite ich
für die Firma Boxine in Düsseldorf.
Die ist wahrscheinlich bekannt durch ihr Produkt
die Toni-Box. Also wenn man kleine Kinder hat, dann kennt
man die Toni-Box. Und genau die läuft
auch mit Python. Vielleicht kommen wir da nochmal ein bisschen dazu.
Oh cool, da haben wir
letztens am Wochenende noch jemanden getroffen, der für die Firma arbeitet.
Ah, interessant. Ja, ja, ich habe mich jetzt
letztes Wochenende, genau mit Jens, den kennst du dann wahrscheinlich
auch lange unterhalten. Genau, der Jens ist auch in meinem Team.
Jens ist auch ein anderer, einer von den
Python-Entwicklern bei BoxCinema.
Ja, cool.
Ja, die Tony-Box ist super
beliebt. Ja, dass es ein Python-Projekt geworden ist.
Also ihr kennt ja bestimmt, das sind diese kleinen
Spielzeugfiguren, die man auf eine Box
stellt und dann spielen sie ein Hörspiel. Also für alle, die
keine Kinder haben.
Genau. Ja, schön.
Also heute das Thema Security. Wir wollen das so ein bisschen
aus mehreren Perspektiven beleuchten, die wir
noch gar nicht so genau festgelegt haben.
Ist wie immer, ich hab keine Ahnung, stell dumme Fragen
und die Jungs antworten ein bisschen.
Ja, fangen wir doch direkt an. Was ist denn Sicherheit, Security, was meint das denn? Also, dass niemand irgendwie einbricht und dann hat jemand irgendwie einen kaputten Pullover an und dann riecht er in so einem Rechner mit grüner Schrift und dunklem Monitor oder wie sieht das aus?
Das triffst du wahrscheinlich schon ziemlich gut. Du möchtest Systeme schützen vor irgendwelchen Angreifern. Das ist das grundsätzliche Prinzip der Sicherheit.
Du hast dann verschiedene Ziele. Ganz traditionell hat man die Intel gedreht, dass ich sagen möchte, niemand möchte etwas ändern.
Ich habe die Vertraulichkeit, dass ich sagen möchte, niemand soll herausfinden können, welche Daten meine Benutzer haben.
Zum Beispiel bei uns beruflich bei der Tonybox. Auf die kann man ja beliebige Audio-Teilen draufspielen.
Und es soll auf keinen Fall möglich sein, dass irgendjemand anders die Audio-Teilen von einem Kunden abrufen kann.
Also das wäre Vertraulichkeit.
Und dann haben wir noch Ziele, die werden manchmal so Zuverlässigkeit genannt oder Availability.
wo es halt darum geht, dass das System verfügbar ist die ganze Zeit.
Okay, also schon irgendwas, was einen auch privat betreffen kann natürlich
und vor dem man vielleicht geschützt werden möchte.
Ja, und wie macht man das in Python?
Ja, also ich würde jetzt so spontan sagen,
eigentlich hat man ja in Python schon mal ganz gute Karten,
weil ein großer Teil der wirklich bösen Fehler,
die einem da so begegnen können,
hat man jetzt in Python eigentlich gar nicht.
Also so mit Buffer-Warflows hat man eigentlich eher nicht so wirklich viel zu tun.
Obwohl, jetzt eigentlich schon wieder,
dem müsste ich erklären, was das ist.
Oh nein, das wollte ich schon.
Wir sind direkt eingeschrieben, du hast gesagt, man kann Fehler machen.
Und das bedeutet, dass Fehler zu Sicherheitslücken führen können,
die dann Angreifer ausnutzen können.
Ist vielleicht einer der Punkte, über die wir vielleicht reden,
welche Sicherheitslücken es denn gibt.
Aber was du sagst, heißt, es gibt Fehler, die jemand gemacht hat,
also ein Entwickler, eine Entwicklerin gemacht hat,
die dazu führen, dass es schwierig wird?
Genau, das Programm macht dann irgendwas,
was der Entwickler nicht gedacht hat.
Also der Entwickler dachte sich, okay, da kommen doch immer gute Daten.
Und dann hat jemand mit einem grünen Bildschirm und einem Kapuzenpulli nachher herausgefunden,
okay, wenn ich ganz bestimmte Daten sende, dann macht das Programm etwas, was der Entwickler nicht wollte
und erlaubt mir dann Zugriff auf irgendwelche geheimen Daten
oder im schlimmsten Fall erlaubt mir sogar Code auszuführen bei irgendjemand.
Genau, das wollen wir halt verhindern.
Und da gibt es halt eine ganze Menge Schwachstellen, je nachdem, auf welcher Plattform man ist.
Also zum Beispiel auch mit Python gibt es Unterschiede natürlich,
wenn ich einen Treiber schreibe, dann kann auch der erwähnte Buffer-Overflow vielleicht schon mal passieren.
wenn ich mit Python eher eine Web-Anwendung
schreibe, dann muss ich mir da halt typische
Sicherheitsblicken anschauen. Aber das ist eigentlich immer,
dass ich irgendwelche Eingaben des
Benutzers nicht richtig
interpretiere und dann plötzlich komische Sachen mache.
Benutzer-Eingabe, Speicher, also Buffer-Overflow, vielleicht noch mal
ganz kurz, dass irgendwie der Speicher läuft
voll und dann kommt man in Bereiche rein, die
das Programm gar nicht vorgesehen hat und dann
passieren komische, magische Dinge.
Das ist dann diese Blackbox der
Mensch mit dem kaputten Pullover.
Naja, also ganz, ganz kurz
irgendwie, ja, ist auch eine relativ spezielle Art
von Sicherheitsproblemen, aber das
war irgendwann, ich glaube, das war dann Mitte der 90er,
ich weiß nicht mehr so ganz genau, gab es einen Artikel
im Frag Magazine
von Aleph One
irgendwie, Smashing the Stack for Fun
and Profit und
es betrifft vor allen Dingen die
Programmiersprache C, die ist halt,
da sind Strings Nullpointer terminiert
und, naja,
Ach so. Genau.
Also da steht nicht
einem String vorher dran, der ist jetzt so und so
lang und dann liest man halt nur bis da,
sondern man liest halt so lange, bis halt ein Nullbyte
kommt und dann hört man halt auf damit
oder halt eben auch nicht, wenn man irgendwie das
falsch macht. Ah, das heißt, wenn man am Ende sagt, da sind
gar keine Nullbytes, sondern sein eigener Code, dann liest
ja gar nicht, liest das immer noch weiter. Genau,
wenn man zum Beispiel einen festen Buffer definiert hat
und aber nicht
überprüft, ob die Eingabe von dem Benutzer halt
vielleicht länger ist, dann kann man halt über den Buffer
hinwegschreiben unter Umständen
und dann halt auch, also was man
dann macht, man schreibt dann irgendwie eine Menge
ein NOPS, was ist das?
Irgendwas A oder so
rein, hofft dann, dass
beim Rücksprung aus der Funktion irgendwie
man in diesem Bereich landet und dann rutscht
es halt durch bis zu einem Shell-Code, den man mit reingeschrieben
hat. Und dann kann man also im besten Fall
irgendwie direkt das Programm
komplett übernehmen. Und
ja, das war
lange Zeit war das ganz,
viel Server-Software hatte
diese Fehler und man konnte das halt ausnutzen.
Obwohl, ich meine, heute spielt
das vielleicht auch immer noch eine Rolle, vielleicht eher
so bei Clients, ich glaube Server,
obwohl gibt es vielleicht immer noch, ich weiß es nicht mehr so genau,
ich habe auch lange nicht mehr drauf geguckt.
Ja, aber das ist halt so eine, das ist eigentlich genau
so das, was sich Leute vielleicht
vorstellen, wenn man
davon redet,
dass jetzt irgendwie irgendwelche
Server gehackt werden oder so.
Man gibt irgendwas ein oder führt ein Programm
aus und dann hat man eine Shell auf einem anderen System,
wo man einfach Code ausführen kann oder beliebige
Kommandos. Da kann man
auch tatsächlich sozusagen diese Perspektiven
von, man muss halt
da kann man nochmal einen ganzen Schritt zurückgehen, weil
im Prinzip das Thema Sicherheit
kann man noch weiter aufmachen
wenn ich halt
Philipp hatte gesagt
Anwenderinput, das ist so ein
das muss oder kann man noch weiter
abstrahieren, weil im Prinzip
sind Viren halt auch nichts anderes als
Anwenderinput
das ganze Thema von
Security lässt sich halt darauf
zurückführen, warum muss ich überhaupt darüber reden, warum
macht ein Programm überhaupt was, was man nicht will
lässt sich halt
stark darauf zurückführen, dass
wir halt eine sogenannte Verneumann-Architektur
haben. Ja, das geht halt zurück
auf die, was weiß ich jetzt, gar nicht mehr.
Mir wurde immer vorher geworfen, Opa redet
vom Krieg, aber da war ich nicht dabei.
60er, 70er,
irgendwo da, noch älter, 40er
Verneumann-Architektur, noch älter.
Das war vor dem
Zweiten Weltkrieg wahrscheinlich sogar.
Irgendwo da.
Also als es so richtig losging, gerade erst
mit den ganzen allgemeinen Rechenmaschinen.
Und die von Neumann-Architektur hat halt ein wichtiges Konzept
und das ist halt, dass der Programmspeicher
und der Datenspeicher eins sind.
Es gab früher Rechner-Architekturen,
da waren Daten von der Eingabe
und die Daten, die den Prozessor gesteuert haben,
also das Programm, komplett getrennt.
Macht halt das große Problem,
dass du nicht einfach irgendwie Programme als Daten runterladen und ausführen kannst.
Also der Effekt, den wir dadurch haben von der Neumann-Architektur ist ja,
ich kann ins Internet gehen, kann mir Daten runterladen und sie dann als Programm ausführen.
Das Problem ist aber, der Vorteil ist gleichzeitig der Nachteil.
Das heißt, auch Daten, die vielleicht gar nicht als Programm gedacht waren, werden als Programm ausgeführt.
Und das ist sozusagen die ganze Krux daran, dass die CPU schon nicht unterscheiden kann von,
sind die Bytes bei mir gerade gedacht für, ich soll mit ihnen rechnen
oder ich soll damit meinen Instruction-Pointer befüttern.
Und das kannst du halt, da gibt es ein,
dieses Grundproblem wird never ever jemals weggehen.
Das geht nie weg.
Na gut, also, moderne CPUs haben ja durchaus einige Verteidigungen dagegen.
Also, moderne CPUs haben einen Marker, wo dann drin steht,
okay, diese Speicherseite ist ausführbar oder nicht.
Und genau das geht ja dann schon in Richtung der konkurrierenden Harvard-Architektur ein bisschen,
dass man sagt, okay, das sind die Daten, das sind die Instruktionen.
Aber natürlich gibt es immer noch Tricks.
Also selbst bei den Buffer-Overflows
gibt es halt sehr, sehr viele Möglichkeiten,
wie man genau dann doch irgendwie noch ein Programm konstruieren kann,
das dann eigentlich nur aus Daten besteht.
Also wo du sagst, okay, das sind eigentlich nur Daten,
aber die auf komischen Stellen liegen
und dann trotzdem den Programmfluss irgendwie beeinflussen.
Das ist spannend, weil ich wollte eigentlich zu dieser Frage mit den,
was machen denn die CPUs dann da falsch,
ganz zum Schluss kommen, ihr habt ja jetzt damit den Einstieg gefunden,
Das ist die unterste Ebene, auf der wir jetzt anfangen.
Ich finde das aber sehr spannend, weil was du sagtest,
dass diese unterschiedlichen Architekturen,
also ich glaube, von Neumann nennt man auch irgendwie Princeton-Architektur.
Und ich glaube, es war irgendwie, ich habe gerade nachgeguckt,
1945, als sie rausgekommen ist.
Und diese Harvard-Architektur, die daneben liegt,
die macht halt diese Getrennung von Daten und Programmspeicher.
Und du sagst jetzt, es gibt auf dem CPU,
also der CPU benutzt für alle Menschen, die vielleicht nicht so drin sind,
Opcodes, also Operation Codes.
Das heißt, die sagen, was für eine Rechenoperation
der machen soll, der Kern.
Und dann macht der genau mit den Daten,
die ihm dazu geschickt werden,
in den einzelnen, was sind das, Decks?
Nein, Registern irgendwie,
macht der dann diese Operation.
Und da kann was schief gehen.
Philipp, vielleicht kannst du das
noch ein bisschen erklären,
weil das klingt ja sehr spannend.
Ja, weil wenn ich einen ganz klassischen
Buffer-Overflow habe, was dann halt passiert ist,
wie gesagt, der Benutzer,
der Benutzer in Anführungszeichen,
aber in Wirklichkeit ist das der Angreifer,
gibt halt irgendwie eine längere Datenfolge an
und wie wir eben schon erwähnt haben,
da könnten dann zum Beispiel verschiedene Instruktionen
wie Knob-Codes drin vorkommen
und das sieht aus wie ein normaler Text,
aber das ist halt genauso designt,
dass man das auch als Ob-Codes für die CPU interpretieren kann.
Und genau das ist das Problem dann nachher,
dass der Entwickler dachte, okay, da kommt einfach nur Text rein,
aber in Wirklichkeit hat der Angreifer den Text so geschickt konstruiert,
dass er ein gültiges Programm ist.
Und es ist sozusagen, wir können für die CPU, weil das konkret zu machen ist häufig sehr schwer so im Luftlernraum, aber weswegen ich schnell zur Neumann-Architektur gegangen bin, ist, das Problem ist ein ganz grundsätzliches Architekturproblem und die Features, die wir jetzt da oben drüberlegen, wie zum Beispiel non-executable pages und so ein Kram oder was dann halt auf anderen Ebenen kommt, Address Randomization und so ein Zeug.
Das sind alles bloß kleine Trostpflaster und man macht es den Angreifern schwerer und teilweise auch um Größenordnungen schwerer, dagegen anzukommen, aber das Restrisiko kann in der Architektur halt nie weggehen, sie wird nie weggehen.
Und die Effekte, die wir aber sehen, lassen sich auf anderen Ebenen genauso wieder erklären und ein Buffer-Overflow lässt sich gut vergleichen und das ist für viele Leute wieder einfacher vorstellbar, wie mit einer SQL-Injection.
Das ist genau das Gleiche.
Die SQL-Injection ist, gib hier bitte deinen Namen ein
und dann kommt das berühmte
Mein Name ist Bobby bla bla bla
Semikolon Drop Tables.
Und auch da ist es so,
das Programm hat gedacht,
ich habe eine Eingabe
und die Datenbank
haut dann aber einmal volle Kanne daneben
und sagt, na das ist doch jetzt die nächste Query hier.
Weil wir drücken ja alles als Text aus.
Der Name ist Text
und das Programmierstatement
für die SQL-Datenbank ist auch nur
Text und wird dann aber eben
als Programm interpretiert. Und wenn
ich das eben nicht richtig
escape an der Stelle,
dann finden solche Modusübergänge statt,
wo etwas, was eigentlich als Eingabe zu verarbeiten
gewesen wäre. Und der Trick ist ja eben der
von Neumann Architektur,
die SQL,
das SQL-Statement,
was ich an den Server drücke, ist ja aus
Server-Perspektive erstmal Daten,
die als Programm zu interpretieren
sind. Und wenn da drin halt Mist stattfindet,
dann geht da alles quer durcheinander.
Und das ist im Buffer-Overflow im Prinzip nichts anderes.
Also das Glas Milch, das zu voll ist und dann tropft das auf die Erde und dann hat man alles nass und denkt sich, oh nein.
Ja, genau.
Buffer-Overflow ist sozusagen die Variante von, das Glas ist zu voll.
Und auch Python schützt einen vor sowas im Prinzip erstmal nur im Sinne von, ja, Python selber gibt sich extrem viel Mühe, selber keinen Mist zu machen.
Wenn du aber, und ich habe mit sowas halt selber auch, also ich sage immer, ich fasse C nur dann an, wenn die anderen es verrissen haben.
Ich schreibe nie C-Code neu.
Ich habe den C-Code nur in der Hand,
wenn die anderen es völlig kaputt gemacht haben
und ich gerade so noch weiß, wie ich es wieder ganz mache.
Der Psycho-PG ist zum Beispiel halt im Datenbankumfeld.
Da merkt man so, dass die Leute halt eigentlich keine C-Programmierer sind,
wenn man den Code anguckt.
Und es hat lange gehalten.
Philipp macht genau das richtige Gesicht.
Das können jetzt die Podcast-Hörer nicht hören.
Aber wir haben so einen Corona-tauglichen Video-Back-Channel.
Und da ist es halt zum Beispiel so, nicht jeder Buffer-Overflow ist gleich halt als Security-Problem ausnutzbar.
Bevor ich halt sozusagen selber Code ausführen kann, kommen noch andere Fehlerklassen oder Effekte vorher.
Typischerweise ist das dann erstmal ein Denial of Service, also zum Beispiel, dass halt das Programm crasht.
Das ist erstmal noch nicht so dramatisch, das ist natürlich auch aus dem Thema Availability als eine der vier Sicherheitsperspektiven.
Nur die Recovery ist halt einfacher typischerweise.
Bei dem Crash starte ich im schlimmsten Fall, starte ich normalerweise die Anwendung einfach neu, dann geht es weiter.
Und beim Psycho war es zum Beispiel so, dass es im Postgres gibt Encoding-Namen.
Und die meisten Encoding-Namen, die von den Leuten verwendet werden, haben ein Minuszeichen drin.
ISO 88591 und so ein Kram.
Und im Psycho-PG ist es so, dass der Encoding-Buffer tatsächlich davon ausgeht, dass da ein Minus drin ist und sie meinten, es wäre eine gute Idee, sie müssen alles normieren und die Minusse rausnehmen.
Und das ist im Postgres auch okay, der hat die ganzen Encoding-Namen auch immer noch mit ohne Minus rumliegen und ein Kunde von uns kam aber dann damals auf die Idee, es gibt in Postgres einen Alias für UTF-8, der heißt Unicode.
So, und dann hat der Psycho halt gesagt, naja, jetzt kommt hier ein Encoding-Name, also streiche ich das Minus raus,
allozie einen neuen Buffer, der genau ein Byte kürzer ist und schreibt dann Unicode ohne Minus in einen statt, was haben es,
U-N-I-C-O-D-E, in einen sechs Byte langen Buffer statt in einen sieben Byte langen Buffer.
Und weil sie aber nicht einfach nur malloc benutzt haben, weil ganz kleine Objekte zu allociieren im Speicher halt ineffizient sein kann,
hat Python einen sogenannten Small Object Allocator.
Damit kann ich eine Page, die ist typischerweise ein K oder sowas, je nachdem, System kann ja auch ein Megabyte oder größer sein, aber gehen wir mal von einem K aus oder 4K, dann packt Python halt solche 6-Byte-Objekte alle zusammen in eine Page und dann brauche ich halt statt irgendwie, wenn wir kurz rechnen, 1066 sind 20, nee, 200, 200, dann brauche ich halt statt 200 Pages, also statt 200K nur 1K.
Die werden eng an eng hintereinander gepackt und was dann passiert ist, ist, dass der Server, der das hatte, so alle Woche mal gecrashed ist und ich habe das halt versucht rauszufinden und irgendwann habe ich da mit, ich glaube, ich habe mit Guido mal reingeguckt, ich habe mit Martin von Löwis reingeguckt, allmöglichen Leuten und irgendwann haben wir festgestellt, der schreibt dann halt manchmal genau auf den letzten Eintrag in dieser Page dieses eine Byte zu viel
Und das eine bei zu viel in einer sogenannten Arena im Small Object Allocator
ist der Pointer auf die nächste Arena.
Und der landet dann halt im Nirvana.
Und dann gibt es halt ein SegFault und dann sagt das Linux halt, so geht es hier nicht.
Und das ist ein typisches Beispiel für, da hat jemand dann einen zu kleinen Buffer alloziiert.
Das ist dann ein Buffer-Overflow.
Er schreibt mehr Daten rein, als da reingehören, weil er sich einfach bloß verrechnet hat.
Und der Effekt muss noch nicht sein, dass jemand Code ausführen kann.
Aber der Effekt ist halt typischerweise, dass das Programm anfängt Müll zu machen und dann haben wir, Philipp hat da ja auch genickt, schon mal die Availability, die Verfügbarkeit von der Anwendung reduziert und das ist ein Sicherheitsproblem tatsächlich auch.
Genau, es könnte ja auch dann sein, dass das nachher auf einem Server irgendwo läuft, wo dein Postgres läuft und das kann vielleicht auch jemand, den Server möchtest du für viele Kunden bereitstellen und dann ist es auch richtig kritisch, wobei hoffentlich niemand dein Encoding im Server steuern kann, das wäre wahrscheinlich eine andere Sicherheitslücke.
Ja, aber also Denial of Service ist halt, das ist böser, als die meisten Leute so zunächst vermuten würden. Ich meine, wir hatten ja jetzt auch letztens irgendwann in Düsseldorf an der Uniklinik ja auch so einen eher gemeinen Fall. Irgendwie so diese Ransomware-Geschichten, die es da gibt. Ich weiß nicht, das war irgendeine Remote-Verwaltungssoftware. Ich weiß nicht, den Namen wieder vergessen.
Citrix. Citrix, genau.
Ja, irgendeine uralte Version davon und dann
ist irgendjemand hingegangen und hat denen ihre Daten
verschlüsselt oder so und hat sie erpresst.
Und da ist, glaube ich, dann tatsächlich auch jemand bei gestorben oder so.
Das war irgendwie sehr unschön.
Ja.
Das ist dann auch der Teil,
den grenzt man in der Security manchmal ab.
Im Englischen ist es halt... Safety.
Ja, das ist im Deutschen
haben wir das sozusagen nicht getrennt.
Ich finde das eigentlich so ein schönes
Beispiel, dass
Konzepte mit
extra Begriffen in anderen Sprachen einem nochmal
einen neuen Blick liefern, dass
Sicherheit im Englischen halt mit Security und mit Safety
übersetzt werden kann und Safety
ist halt die auf Menschenleben
und körperliche Unversehrtheit bezogene
Perspektive von Sicherheit
und Security ist halt die Frage, ob das
Fahrrad noch da ist. Aber kannst
du das denn in der modernen Gesellschaft wirklich auseinanderhalten?
Ja, das ist halt sozusagen genau
das Thema, dass man
und damit machen wir jetzt einen schönen
nächsten Bogen, dass Security extrem
kontextspezifisch ist.
Also ich stelle mir gerade die Gesichtsbemalung vor, die dazu führt, dass die Kamera den Algorithmus verändert und ein anderes Gesicht immer in die Daten erkennen lässt und dann kann ich mich tarnen mit einer gewissen Schminke und als jemand anderes ausgeben. Weil der Algorithmus dadurch denkt, ich bin jemand anderes, weil ich einen anderen Gesichtshash bekomme oder so.
Das ist der Schwamm in dem ganzen Machine Learning Umfeld, dass du diese adversarial Models hast, dass du sozusagen auf der einen Seite ein Model haben kannst, was Dinge erkennt und jemand anderes weiß aber, wie er auf Basis eines Models Outputs generiert, die dieses Model dann wieder aus dem Takt bringen.
Ja, nur für seinen Social Score oder sowas kann man den dann hochhalten, obwohl man andere Sachen tun kann.
Die Ecke von Philipp fand ich jetzt nochmal wichtig und spannend, dass halt dieses Thema, ah, hier passiert ja nichts Schlimmes. Das Interessante ist eben, durch dieses Architekturproblem trifft es halt alle und jeden. Also jedes Stückchen Code, was du schreibst und mit dem großen Problem Dual Use, du weißt halt nie, wofür wird Code halt mal eingesetzt werden.
Den schreibt man jetzt und der ist da und ganz ehrlich, Leute, die Code finden, werden ihn benutzen. Er wird irgendwo benutzt werden und er wird für Dinge benutzt werden, die man sich nicht vorgestellt hat. Wobei ich da auch immer eine Lanze dafür breche, zu sagen, naja, der, der den Code in den Kontext einführt, hat die Verantwortung, sicherzustellen, dass er da was Sinnvolles tut.
Dann mach mal ein Projekt mit NPM-Paketen oder sowas.
Genau, ja, aber das ist deren Verantwortung.
Es ist nicht die Verantwortung von jemandem,
es gibt im Open-Source-Umfeld, kann man ja auch viel da nochmal drüber reden,
über die Motivation von Leuten, die halt so Open-Source-Packages maintainen,
die dann ein riesen Schwergewicht kriegen.
Ich finde, die Leute haben keine moralische Verpflichtung,
anderen gegenüber aus ihrem Freizeitprojekt, wo sie sagen,
da steckt einfach nur meine Lust und meine persönliche Motivation drin,
anderen Garantien auszusprechen, dass
sie damit jetzt einen Space Shuttle betreiben
können.
Das darf man so nicht umdrehen
und nichtsdestotrotz
ist es natürlich
ein
Das ist alles ein etwas zusammengeschimmertes
kleines Raumschiff, was immer droht auseinander
zu fallen, was auf der einen Seite mit Kohle und auf der
anderen Seite mit einem Handpedal betrieben wird
und keiner so genau weiß, wo denn jetzt
das nächste Leck entsteht.
Ja, ich hätte auch
große Bedenken, irgendwie so medizinische
Software für medizinische Geräte zu schreiben oder
irgendwelche Software, die Flugzeuge
steuert oder so, da hätte ich irgendwie
groß, würde ich wahrscheinlich eher lieber nicht.
Wahrscheinlich schon bei Bank-Transaktionsgeschichten
schon bedenken, aber...
Allein das zeichnet dich aber eigentlich schon aus
als jemand, der qualifiziert sein könnte,
das zu tun.
Zu viele
Leute gehen nämlich ohne
diese Vorsicht heran.
Also, man hat mal
früher gesagt, die Deutschen bauen die besten Nationenkraftwerke,
weil die so scheiß viel Angst davor haben.
und halt entsprechend in die
Sicherheit investieren.
Deswegen ist Siemens mit der
Atomkraftwerke so ein Exportschlager.
Andere haben halt weniger Angst
davor und machen dann halt
auch weniger Sicherheit.
Das ist so ein bisschen ein
wer sich halt auf dem Fahrrad sicher fühlt
und keinen Helm aufsetzt,
wer sich unsicher fühlt und einen Helm aufsetzt, ist am
Ende bei einer echten Kollision halt
feiner raus.
Ja, aber ich meine, das ist einfach
Ich glaube, also das, was mich da so unsicher fühlen lässt, ist halt einfach, es ist schwer überhaupt sicherzustellen, dass da nichts passieren kann. Es ist einfach, es kann so viel schief gehen.
Es geht auch nicht. Das ist dann der schöne Übergang zu dem Thema Security als Prozess halt. Man kann halt immer, ich glaube etwas, was lange in der Informatik gelehrt wurde, ist halt das Problem sozusagen Security als abstrakte mathematische Eigenschaft eines Systems.
Das wird an vielen Stellen auch noch verfolgt und da kommen interessante Sachen raus, gerade wenn wir gucken in Richtung strenger Typsysteme und all so ein Zeug. Also ADA zum Beispiel, dieses ganze Umfeld. Und da finde ich es auch spannend, dass die tatsächlich dort Engineering haben.
Und ich hatte ADA nur mal im Studium und muss sagen, also es ist halt, was die Garantien angeht, wirklich straff. Es ist auch ziemlich schnell. Ich habe aber nie irgendwas Sinnvolles damit programmieren können.
Kannst du vielleicht nochmal ganz kurz erklären, was ADA ist?
ADA ist eine Sprache, die ist extrem formal definiert und die wird hauptsächlich im militärischen Bereich eingesetzt. Also bei uns an der Uni ist die gelehrt worden und dann gab es halt gerne mal von der Eurocopter und von anderen Leuten Besuche, wo es dann darum ging, irgendwie Steuersysteme für Kampfhubschrauber und so ein Kram zu programmieren.
Und die ist halt, die zeichnet sich dadurch aus, dass sie ein sehr umfassendes Typsystem hat. Das heißt, da wo man in anderen Sprachen halt sagt, ich hatte hier gerne einen Integer, kannst du dem Ding halt sagen, ja, ich will hier einen Integer haben, der darf aber nur von 7 bis 9, 11, 13 und 12 sein.
Und der Compiler kann dir vorher über alle Operationen deines Programms schon sagen, ob die Verkettung der Operationen in Summe noch zu zulässigen Ergebnissen führt.
Oder ob du irgendwo deine Wertebereiche sprengen würdest. Und gleichzeitig, und das ist halt wirklich cool, die können halt Echtzeit und sie sind auch auf anderen Systemen sehr, sehr schnell in der Laufzeit nachher. Und das ist halt, das ist was wert.
Gleichzeitig ist es aber so, immer wenn es um I.O. geht, nämlich da, wo halt dieses Thema, da kommen Daten von draußen rein oder müssen wieder raus, da gucken sie so ein bisschen in die Luft und sagen, naja, das macht jemand anders.
Das ist dann halt immer, also da herzugehen und zu sagen, ich hätte jetzt hier gerne mal noch schnell eine HTTP-Library und ich würde hier nochmal eine SSL und nochmal da drüben ein Repository von GitHub, sowas ist bei aller halt eher nicht so an der Tagesordnung und du brauchst halt auch eine entsprechende Engineering-Menge und Genauigkeit, all die Kombinationen, mit denen du sozusagen konfrontiert wirst, dir so genau anzugucken, das lohnt sich halt auch eigentlich nur, wenn da wirklich Menschenleben dranhängen.
Wenn du sagst, es ist okay, wenn dieses kleine Programm jetzt zwei Millionen Euro kostet, wo jemand anders sagt, komm, da hack ich dir jetzt das Shell-Skript runter und dann ist es gut. Da muss man immer aufpassen, dass es halt kontextbezogen ist. Also die kommen halt aus dieser Ecke von einer mathematisch perfekten, idealisierten Variante von so, wir schreiben jetzt das Programm und das ist dann sicher. Und wenn du in ausreichend komplexe Systeme kommst, musst du aber eigentlich eher einen prozessorientierten Ansatz machen.
Genau, da würde ich nämlich jetzt auch gerade noch kurz einhaken und sagen, naja, das Blöde ist, dass einem halt auch diese Geschichten nicht unbedingt schützen vor wirklich fatalen Fehlern, wie zum Beispiel, ich weiß nicht, ob das der Jungfernflug von irgendeiner neuen Ariane-Version war, Ariane 5, Ariadne oder Ariane, Ariane, glaube ich, 5.
Ich glaube, auch die Steuerungssoftware dafür ist auch in ALA geschrieben oder so.
Und die ist sogar bewiesen, dass die tatsächlich das tut, was in der Spezifikation steht.
Nur das Problem ist halt, sie haben irgendwie die falsche Spezifikation verwendet.
Das war Wind.
Nee, die Spezifikation war halt für die alten Motoren irgendwie.
Und dann waren die Sensordaten für den Computer halt irgendwie so, nee, das kann nicht sein.
Aber es ist ja bewiesen, das ist richtig, daher muss ich defekt sein.
dann hat sich der erste Steuerungskomputer ausgeschaltet
und dann hat sich der zweite auch noch ausgeschaltet,
der den übernommen hat und dann war halt Schluss.
Und dann ist die Rakete halt abgestürzt.
Und ja, das ist ja auch sowas.
Ich meine, klar, man kann halt beweisen manchmal,
dass Programme das tun, was sie tun sollen,
aber dann muss man ja immer noch sicher sein können,
dass die Spezifikation richtig ist.
Aber irgendwie, man kommt da in so einen infiniten Regress
und selbst das hilft einem nicht.
Das war jetzt ein Fall, wo ein Hardware-Update dazu geführt hat,
dass das Ding nicht mehr lief.
Also keine Updates fahren, never touch a running system.
Aber auch in Python hat man ja nicht völlig verloren.
Also auch wenn Python solche strengen Garantien
nicht so direkt hat, man kann natürlich Assertions
einbauen und damit kann man so ein bisschen
in die Richtung gehen, was Ada auch kann.
Wenn ich sage, ich baue hier ein Assertion ein und sage,
okay, ich erwarte, dass die Eingabe nur so lang
ist oder ich erwarte, wie du eben als Beispiel gebracht
hast, Christian, dass halt nur irgendwelche bestimmten
Zahlen davor kommen, das kann ich auch in Python
machen. Das geht, das macht den Code
ein bisschen länger, da muss man sich ein paar Gedanken
machen, aber das ist ja sicherlich auch
ein Merkmal
von qualitativen Code, dass man sich halt immer Gedanken
macht, okay, was sind meine Eingangsbedingungen,
was sind meine Bedingungen,
die ich vielleicht rausgebe, dass ich auch schaue, okay, die Daten,
die ich nochmal rausgebe, die kann ich
in ein anderes Modul in meinem Programm, die kann ich auch nochmal
validieren, dass da alles in Ordnung ist, dass das zum Beispiel
irgendeinem Schema entspricht oder sowas.
Also das ist ja auch in Python nicht unmöglich
und es gibt natürlich auch in Python noch sehr viele
andere Sachen im Rahmen eines sicheren
Prozesses, die ich durchführen kann. Also das beginnt
ja bei ganz normalem Code Review.
Da guckt halt jemand anders drauf und sagt halt vielleicht, okay, der Code sieht komisch aus. Und dann kann ich halt sowohl Tests durchführen gegen den Source-Code, also dass ich mir den gesamten Source-Code nehme und ein automatisiertes Programm drüber laufen lasse, das mir halt sagt, okay, die Stelle sieht komisch aus. Hier machst du wahrscheinlich eine SQL-Injection oder ein C, ein Buffer-Overflow, das sieht irgendwie gefährlich aus.
Und dann kann ich natürlich auch sogenannte Blackbox-Tests fahren, wo ich sage, okay, ich starte meine Anwendung einfach mal und dann nehme ich mal so ein Hackertool und das probiert einfach mal aus, kann ich hier komische Sachen eingeben und crashen in das Programm oder macht das Programm irgendwas komisches. Also auch in Python ist das nicht verloren. Da kann man auch sehr sichere Anwendungen schreiben, was meistens das gleiche ist wie eine gute Anwendung zu schreiben, weil die stört es halt nicht ab und die kann auch mit allen Benutzerangaben umgehen, noch nicht mal nur von Angreifern, sondern auch von Benutzern.
Also ich hatte das beruflich auch so, wir dachten erst, wir hätten einen Angreifer, weil unsere Anwendung abgestürzt ist, aber hat sich herausgestellt, wir hatten ein ähnliches Problem wie beim Buffer-Overflow, wir hatten ein Datenbankfeld mit einer bestimmten Länge und die Länge war aber in Bytes und dann kamen halt User an und haben ihre kleine Tony-Figur mit ganz vielen Smileys genannt und dann passte das nachher nicht und führte zu einem Crash.
und auch sowas kann man natürlich auch vorher darauf achten
und entsprechend auch testen.
Das ist ja noch ein anderer Bestandteil eines sicheren Prozesses,
der sagen kann, ich schreibe vorher Tests
und ich überlege mir entweder manuell oder sogar automatisiert,
wie sehen komische Eingaben aus.
Bei Nummern sind das meistens Null oder sehr kleine Zahlen
oder sehr große Zahlen.
Typischerweise auch Zahlen,
die vielleicht über die 32 Bytes hinausgehen,
was in Python jetzt nicht so ein Problem ist
oder über die 64 Bits hinausgehen.
Also wenn ich da eine sehr große Zahl,
wenn ich 2 hoch 64 plus 1 schreibe,
dann in Python gar kein Problem.
Aber in vielen anderen Programmiersprachen
führt das halt zu einem Absturz
oder zu komischem Verhalten.
Und damit kann ich auch in Python, glaube ich,
sehr gut Sicherheit sichern.
Also du würdest tatsächlich in solchen kritischen Fällen,
wo du dir überlegst,
ah, ich weiß nicht so genau, was dabei rauskommt,
Assertment-Statements in den Code schreiben einfach
und dann sagen Asserts should never happen oder sowas
und dann... Genau, und
fliegt dann. Genau, auch vielleicht
auf Testen. Also bei dem Beispiel, was ich eben gebracht
habe, wo die Nutzer Emojis eingeben
haben oder andere komische Unicode-Zeichen,
haben wir halt einen Test gemacht. Und dieser Test,
also wir haben sowohl einen Unit-Test,
der also ganz normal in der Anwendung
läuft, wo wir halt mal ausprobieren, was passiert,
wenn ich nur Emojis eingebe oder andere
komische Strings. Und wir haben aber auch einen
End-to-End-Test, der das
gesamte System testet. Also zum Beispiel
hatten wir auch mal einen Bug, der
durch
den Reverse-Proxy vor unserer Anwendung
verursacht wurde, dass der halt Sachen falsch
macht. Und sowas kann man dann halt
nicht so richtig testen. Natürlich könnte man auch in
Nginx sagen, ich schreibe eine Art Unit-Test
für unsere Nginx-Konfiguration, aber
da ist dann praktisch halt wirklich ein End-to-End-Test zu schreiben,
der halt
wirklich eine echte Anfrage gegen das echte System
schickt oder gegen Prot, also da kann man sogar gegen sein
Production-System testen, aber natürlich testet
man das im Normalfall zuerst gegen Development
und sendet mal komische Anfragen
und schaut, okay, geht das?
Kommen hier ordentlich Ergebnisse raus und
meldet das System vielleicht auch
hinten drum schon, dass irgendwas umgefallen ist
und das kann man halt
damit schon ganz gut testen.
Ich finde das halt auch spannend
aus der Perspektive von
User lassen sich halt
mehr Dinge einfallen, als man selber halt
vorher konstruieren kann.
Tests sind an der Stelle immer natürlich auch super,
weil man, wenn man im Hinterkopf behält,
dass Tests halt eben nicht
dafür da sind, Beweise
zu ersetzen. Also ja,
Sie sind sogar eine Annäherung eines Beweises, aber sie können halt nie alle Fälle abdecken.
Das geht halt schon in dem Moment schief, wenn du halt ein kontinuierliches Wertesystem hast an der Stelle.
Und was da halt interessanterweise zum Tragen kommt, aus einer ganz anderen Ecke von Security,
ich weiß gerade nicht mehr, welcher amerikanische Militär das war, das kommt so aus dem Counterterrorism-Zeug,
Das ist Only Variety Can Match Variety.
Also das Problem von Terrorismus ist halt, dass Terroristen extrem variierte Inputs, also Angriffe fahren.
Also da geht es ja nicht um eine reguläre Kriegsführung nach irgendwie Genfer Konvention,
sondern die machen Dinge, gerade weil sie verboten sind und weil keiner damit rechnet, an Stellen, wo keiner damit rechnet.
Und die Amerikaner haben halt irgendwann rausgefunden, wir können dem halt nicht mit herkömmlichen Maßnahmen,
indem wir alle möglichen Fälle durchdeklinieren, entgegentreten,
sondern du brauchst halt kognitive Diversität, um auf diese absurden Ideen zu kommen.
Du brauchst tatsächlich Leute, die unterschiedlich ticken.
Und ganz ehrlich, keiner von uns, wenn ich hier in die Runde gucke,
wir haben halt vier mittelalte weiße Männer.
Und die Diversität ist auf der Ebene halt auch kognitiv dadurch mit dem Bias belegt.
Keiner von uns kommt auf die Idee in seinen Tests halt, Katzen-Emojis in den Input zu tragen.
Das macht halt von uns keiner.
Und an der Stelle ist Security als Prozess
halt tatsächlich auch von einer hohen Diversität,
also braucht eine hohe Diversität,
immer mit dem kleinen Zusatz von kognitiver Diversität,
die aber auch tatsächlich überlappt
mit kultureller und persönlicher Erfahrung etc.,
um halt das erzeugt zu kriegen,
dass man halt auf genügend Ideen kommt,
die dann mal so eine Baseline herstellt von,
okay, das ist jetzt hier nicht mehr scheiße.
Naja, das ist immer, ich finde das aus einem prozesshaften Ansatz gesehen und das ist halt das, wo ich dann, wenn Jochen, der halt sagt, Hilfe, ich will keinen Space Shuttle Code schreiben, aber Leute, die halt besser differenzieren können zwischen, ja, wie gut oder schlecht ist es denn versus ist es jetzt perfekt sicher oder ist es nicht perfekt sicher, weil das kenne ich halt aus vielen auch so Corporate-Umgebungen, wenn man Diskussionen führt, für die ist halt Sicherheit ein An- oder Ausknopf.
Entweder es ist sicher oder es ist nicht sicher, weil die müssen unter irgendeinem Produkt ihre Checkliste machen von, ja, dieses Produkt ist sicher, deswegen dürfen wir es einsetzen.
Da steht halt immer auf Rot die Lampe, wenn man ehrlich ist.
Ja, also ich habe halt schon Sachen gehabt, wo wir mit Institutionen aus dem Finanzumfeld, für die wir dann Sachen betreiben außerhalb der Kernrechenzentren, weil wir dann immer mit irgendwelchen jetzt so, oh, die Finanzwelt entdeckt, dass die Leute Apps wollen.
Aber nein, ihr dürft, die App darf nicht mit unserem Kernbanking-System reden. Und dann sind wir da häufig so ein Layer dazwischen, wo wir sagen, okay, wir betreiben für euch diese ganzen APIs und machen da den Kram dazwischen, dann sind wir so diese Pufferzone. Und wenn ich dann aber einen Excel-File kriege mit 5000 Einträgen, wo die ganzen Security-Anforderungen laut dieses Finanzinstituts drin sind und ich dann in Zeile 2327 sage, ja, wenn ich jetzt die Cipher, die ihr da vorgebt, raus ins Internet lasse, dann ist es von heute auf morgen kaputt.
Weil ihr habt das letzte Mal vor drei Jahren eure Cypher-Liste aktualisiert und für eure Rechenzentren, wo kein Internet reinkommt, mag das jetzt alles okay sein, aber wenn ich damit jetzt halt raus ins Internet gehe, dann ist es halt kaputt.
Und jetzt musst du ihnen klar machen, naja, im Internet wird ständig alles angegriffen und du kannst jetzt nicht mit mir einen Vertrag schließen, wo du reinschreibst, welcher Cypher da drin stehen soll, sondern du machst mit mir bitte einen Vertrag, wo du sagst, nach bestem Wissen und Gewissen haltet ihr euch informiert und kompetent und ihr aktualisiert das, so wie es halt nötig ist.
und jada, jada, jada.
Aber das war dann halt auch plötzlich
ein Kampf, wo die davor standen und sagten,
ich muss jetzt hier das Siegel drauf machen, obwohl ich
eigentlich in der Liste geschrieben habe,
Verstöß gegen unsere Sicherheitspolicy.
Ja, stimmt.
Das ist ein großes Problem. Das ist auch so ein Problem
mit so Zertifizierungen, die man ja sonst vielleicht
macht, wenn man jetzt irgendwie ein Auto fährt oder
keine Ahnung, wo das eigentlich herkommt,
Kirmesgeräte hat, auf denen Leute
rumfahren. Dann kommt der TÜV und sagt halt,
okay, ist noch nicht durchgerostet, alles klar,
das Siegel, das geht halt
bei Software nicht so gut, weil die muss man
ja ändern und eigentlich braucht man dann eine neue Zertifizierung,
aber das, ja genau,
das wäre, ja könnte man jetzt denken, dass das
die Lösung wäre. Ich habe das schon gemacht,
ich habe schon einen Software-Test.
Ja, ich habe
2003 oder 2004
haben wir damals mit Soap eine
Common Criteria Zertifizierung gemacht
und das war so ein Challenge,
da gab es einen Sponsor, der uns das bezahlt hat
und parallel
dazu hatte damals Red Hat den
J-Boss, glaube ich,
durch eine Common Criteria gejagt
und wir hatten im Prinzip
das gleiche Schutzniveau anzubieten.
War irgendwie eine ERP 3 Plus
oder ERP 4 oder so ein Kram.
Du hast jetzt gerade irgendwie ein kryptische...
Ich kann es nicht, ich kann auch nur
die humoristische Variante irgendwie so,
die unterste ist irgendwie, das Programm existiert
irgendwie, die nächste ist dann
irgendwie, ja, das Programm existiert und es gibt
Dokumentation dazu, dann die nächste
ist irgendwie, jemand hat mal geguckt, ob die Dokumentation
zum Programm passt und dann irgendwie
Die nächste ist dann irgendwie, es existiert
ein formaler Beweis, dass das Programm korrekt ist.
Wo dann irgendwie so ein Zwischenschritt fehlt,
das ist glaube ich diese Stufe 6
oder weiß ich nicht genau.
Ja, ERP 6 ist die formale Verifikation, genau.
Und, nee, nee, wir hatten
da schon ein relativ hohes Schutzniveau und
die Common Criteria als Framework,
um über Security nachzudenken,
inhaltlich, ist toll.
Weil du kriegst halt einen Katalog
von, also du hast zum einen einen Prozess,
der dir sagt, okay, mach dir mal Gedanken
über, wer sind denn deine Assets?
Wer sind deine Angreifer? Was haben die für Motivationen? Was haben die für Ressourcen? So, und jetzt gucken wir mal, wie mappen wir das alles aufeinander von, wie sind deine Assets mit was geschützt gegenüber welchen Angriffsszenarien und die haben auch noch einen tollen Implementationskatalog, wo sie sagen, okay, also wenn du folgendes countern möchtest, könnte man zum Beispiel Logging machen.
Wenn du Logging machst, dann musst du dir über die Integrität vom Log Gedanken machen, dann musst du dir über Zeitstempel Gedanken machen, dann musst du, das ist sozusagen, das ist so ein bisschen, da kannst du wie bei so einem Spinnennetz irgendwie reingreifen, erstmal was interessiert mich und dann kommen alle Sachen hinterher, von die du noch berücksichtigen musst. Das ist viel, aber es ist eigentlich erstmal auf der Ebene fachlich gar nicht schlecht gewesen.
Das große Problem ist, die Common Criteria kommt aus der Produktsicherheit und die gehen halt davon aus, dass ein Produkt eben, siehe ein Karussell auf dem Jahrmarkt, das Ding wird einmal gebaut und existiert jetzt und jetzt ist das ab und jetzt läuft das 30 Jahre, wenn du aber sowas wie einen Open Source Application Server hast, wo du exakt ein Release einmal verifizieren darfst und dann kommt aber in 23 Stunden das nächste raus.
Und du fängst die ganze Zertifizierung
wieder von vorne an, das geht dann halt schief.
Ja, also man muss
ja die Zertifizierung erstmal, also
es kann manchmal sehr gut sein, dass man sich
über alle Sachen Gedanken macht, aber man kann
ja auch ganz viele Sachen vermissen, also ich glaube
der viel besser
oder für viele Anwendungen besser
ist es, wenn man sagt, ich mache einen Pentest
und lasse ich einen Auftrag geben, bei einem
Pentest geht halt jemand anders hin und sagt
ich checke deine Software, also
entweder checke ich die von außen oder
ich schaue mir den Source Code an, ich schaue mir das mal an, was du so in Python oder auch in anderen Programmiersprachen alles programmiert hast.
Und da sind dann erfahren Entwickler in der genau der Programmiersprache und die können dann halt schon,
vielleicht auch mit automatischen Tools, sehr schnell kritische Stellen finden.
Also damit habe ich auch gute Erfahrungen gemacht.
Das ist natürlich eine ganz andere Herangehensweise, dass man sagt, okay, ich versuche nicht alles irgendwie,
den ganzen Prozess, ich schreibe kein Papier, sondern ich lasse im Wesentlichen Leute anfangen, uns zu coden.
Und das muss man natürlich auch regelmäßig wiederholen.
Das bringt natürlich nichts, wenn man vor zehn Jahren das mal gemacht hat.
Aber das ist auch sicherlich eine Methode,
mit der man seine Anwendung gut absichern kann.
Ja, du musst da seinen Angreiferhut aufsetzen und da draufhauen,
solange du bist, auseinanderfällt er.
Da brauchen wir halt gute Angreifer auch, die so ein bisschen ein paar Tricks kennen.
Und ich glaube, wenn man jetzt nur so Tools drauf loslässt, dann weiß ich nicht.
Genau, also wenn man nur ein Tool selber drauf loslässt,
hilft es wahrscheinlich nicht.
Aber wenn man halt jemanden beauftragt, der da wirklich Experte ist,
ich glaube, das ist eine ganz gute Möglichkeit,
um auch so einen Blick zu bekommen, wie schlimm ist denn mit unserer Anwendung?
Haben wir nur eine ganz kleine Schwachstelle oder ist unsere Admin-Oberfläche ohne Benutzername und Passwort irgendwie verfügbar und man kann beliebigen Code hochladen?
Und ich glaube, das ist noch ein bisschen eine andere Herangehensweise, aber ich glaube, das ist oftmals effektiver, vor allem für so kleinere Projekte.
Wenn man natürlich eine Zertifizierung braucht, dann braucht man sie, aber ich weiß nicht, ob das immer auch wirklich zu Sicherheit führt, wenn ich nur ganz viel Papier schreibe.
Also ich würde an der Stelle halt eine Lanze verbrechen für das, was wir jetzt zu Corona-Zeiten kennengelernt haben als irgendwie Schweizer Käse-Modell.
Aber du kannst halt, also für alle, die das noch nicht gehört hatten, ist sozusagen die ganzen Maßnahmen, alle Anti-Corona-Maßnahmen sind für sich genommen natürlich durchlöchert, wie so ein Schweizer Käse.
Aber wenn ich halt fünf Scheiben Schweizer Käse hintereinander lege, ist die Filtrationsrate dann doch relativ gut.
Dass also wirklich über fünf Schichten an der gleichen Stelle überall die Löcher sind, das passiert halt normalerweise nicht.
Und deswegen würde ich halt immer, also aus meiner dann längerfristigen Erfahrung, würde ich halt sagen, es kommt immer auf den Kontext drauf an.
Man muss immer erstmal gucken, was sind hier eigentlich die Assets gerade und wenn ich gerade hier in meinem Heimkeller irgendwie die Temperaturdaten von meinen Hubs aufschreibe, denke ich mir so, ja, egal, dann darf es halt auch mal, wenn ich für mich entschieden habe, die dürfen auch ins Internet purzeln, dann ist schon okay.
Aber tatsächlich diese Layer zu haben, auf der einen Seite Produktsicherheit tatsächlich sich anzugucken mit den, was sind hier eigentlich die technischen Maßnahmen und sowas wie eine Common Criteria im Hinterkopf zu haben, ist für mich inzwischen eher das Know-how von, das setze ich ein, während ich ein System aufbaue, um sozusagen schon vorher zu wissen, okay, wo ist denn die Checkliste, wo ich dann weiß, jetzt habe ich wenigstens nichts unnütz vergessen.
Während dann halt das Thema ist halt auch jemand zum Beispiel vom Pentest, da würde ich auch sagen, einige Leute, mit denen ich mich dann austausche, sagen, nee, dann machst du halt lieber auch noch gleichzeitig sozusagen eine externe Code-Review, die sozusagen über das, was du brauchst, dann nochmal im Whitebox drüber guckst und dann kannst du nochmal von draußen draufhauen und diese ganzen Schichten ergeben dann halt.
Und gleichzeitig kannst du dann an vielen Stellen ja auch, wenn man standardisierte Protokolle wie halt HTTP immer so dazwischen hat, dann gibt es da ja auch noch die Möglichkeit, immer nochmal so Schichten einzuziehen wie eine Web-Application-Firewall, die einem so bestimmte Sachen schon mal wegfängt.
Also ich habe zum Beispiel ein paar Kunden, denen gucke ich über die Schulter und da weiß ich dann so, okay, bei dir knalle ich da jetzt eine Waffe davor, weil ansonsten traue ich mich nicht, das ins Netz rauszulassen.
Du sagst mir, es muss raus ins Netz.
Das ist das gleiche Prinzip wie ein Virenscanner.
Also da habe ich irgendwie ein Muster, das ich suche.
Genau, ja, ja, ja.
Okay, wenn ich das Muster finde, dann mache ich irgendwas,
dann unterbinde ich die Anfrage oder schmeiße das Muster raus
oder mache irgendwas.
Genau, genau.
Das ist schon ein bisschen gefährlich,
weil eine Möglichkeit ist halt schon wie bei einem Virenscanner,
dass der, also die Wald- und Wiesenattacken findet der sicherlich.
So was im Internet das Grundrauschen ist,
das findest du auf jeden Fall.
Aber wenn dann wirklich jemand deine Firma angreifen will,
dann merkst du dich da vielleicht auch in falscher
Sicherheit, weil man halt dann doch immer
also du hast recht mit dem Schweizer
Käse-Modell, das macht es vielleicht ein bisschen besser
aber gleichzeitig kann ja so ein Waff auch
wieder ein Angriffsmodell sein, weil der muss ja auch wieder alles
interpretieren und ein Problem kann halt sein
dass mein Server davor und mein Server danach
sowieso schon unterschiedliche Details
anders interpretieren, also bei HTTP
zum Beispiel Junk Encoding oder
irgendwelche komischen HTTPS-Optionen
anders interpretieren und dass dann die Waff
sogar noch ein neues Problem aufmacht
dass sie plötzlich Sachen anders interpretiert
und dann vielleicht sogar eine Schwachstelle
an sich hat. Also auch die Waffe ist ja nur Code.
Ne, genau. Deswegen ist es auch für uns zum Beispiel
keine Maßnahme, die wir halt so Blanko überall drüber
gießen, sondern das ist halt, wir haben halt
dann Kunden, wo feststellen, also
die Waffe ist für uns mehr oder weniger dann
der erste Move. Also manchmal,
wie du sagst, will irgendwer einfach in seiner
Ausschreibung sehen, da muss eine Waffe davor.
Pack ich da eine Waffe davor.
Und wenn, das
muss er ja anbieten können erstmal in dem Moment, wenn er
das fragt. Und wenn der dann irgendwie nach zwei Monaten
fragt mit, warum ist das hier alles so doof, dann sage ich,
du wolltest eine Waffe haben, dann sagt der mir, jetzt machst du wieder aus,
dann mache ich es halt wieder aus.
Wo wir es häufiger als Werkzeug
tatsächlich sehen, ist,
dass tatsächlich diese Wald- und Wiesenscans
und Angriffe gerne
mal massiv für Last sorgen.
Und das ist halt,
wir sehen immer wieder Anwendungen,
wo Leute mit SQL-Injection
versuchen,
quer über so eine Anwendung drüber gießen
und die Anwendung dadurch in
Performance-Probleme gerät.
das ist halt tatsächlich, was das Filtern wird, dann damit
zum Beispiel vorne weg. Also jetzt hier haben wir die ganze
SQL-Kram, das hat da nichts drin zu suchen,
zack, weg, raus.
Ah, okay.
Ja, aber genau, also ich habe
auch schon mal von jemandem gehört, der so
Pentests macht, dass er
meinte, so ja, da war eine Bank, die hatte irgendwie
ein System vor den
Datenbanken und das sollte eigentlich aus
dem SQL irgendwie alles rausfiltern, was
und das hat dazu geführt, dass SQL-Injection wieder möglich
wurde, weil es halt
Dinge zu viel
rausgenommen hat.
Du hast
ja aus
Komplexitätsperspektive hast du immer das Problem
der Kombinatorik.
Das heißt, wenn du n Dinge hast,
die miteinander reden, dann hast du halt
n Quadratverbindungen mindestens.
Und wenn du jetzt sagst,
okay, das ist mir zu unsicher, ich packe noch eins
davor,
dann hast du noch mehr.
Das Problem ist, glaube ich,
an der Stelle auch, wer halt
irgendwie diese Architektur entscheidet
und so und wem man da vertrauen kann. Gerade wenn
Leute jetzt keine Ahnung haben von
Sicherheit oder von Computern allgemein, aber
irgendwie Software als Manager irgendwie bestellen
wollen. Die haben ja eine unheimliche Asymmetrie
gegenüber den auch Entwicklern und so
und die müssen halt vertrauen
auf das, was denen da erzählt wird und die
stellen sich dann meistens so ein Sammelsurium an
Angebot und Nachfrage
oder Best Practice oder irgendwas, was die
halt an Informationen saugen können zusammen.
Und das ist ja auch schon so eine Art
Baukasten und das ist ja nie ganzheitlich
irgendwie gedacht, was wird ja auch immer dann teuer und so,
muss ja auch dann wieder sparen und
wenn man das dann rauslässt, dann ist ja klar,
Fehler sind ja völlig vorprogrammiert
und sich da richtig vorzuschützen
ist fast eine unmögliche Aufgabe
und die Frage wäre vielleicht, wie man solchen
Menschen auch eine Möglichkeit geben kann,
Systeme in sicherer zu denken,
also ihr habt jetzt gesagt, so Prozesse von Anfang an
so ein bisschen, das würde ja wirklich bedeuten,
dass man sich, bevor man damit anfängt,
mit einem Systemarchitekten oder sowas
intensiv auseinandersetzen muss,
welche Tech-Stacks man benutzt oder so was
oder wie der Prozess halt aussehen muss
und wo man Sicherheits, ja, was ist das, Netze einzieht oder ...
Ja, die Frage ist halt, welche Angriffsmöglichkeiten
man irgendwie zur Verfügung stellen möchte.
Da gibt es ja unzählige.
Es ist ja nicht immer nur so diese Website,
die nach außen dann da das Aushängeschild ist,
wo man dann draufhauen kann.
Ja, die Versuchung ist ja nicht groß,
sich halt sozusagen als Feature, als Draufklopf anzukaufen,
also ein riesiges System, was aktuell existiert,
was in Wirklichkeit wahnsinnig unsicher ist
und dass man sagt, okay, ich mache jetzt einfach,
ich kaufe jetzt eine Waffe oder
irgendwas anderes, mache einmal
einen Pentest oder mache eine Sache
und hoffe dann, dass das damit okay ist,
dass ich halt so Sicherheit dazukaufen kann.
Ich glaube, es ist viel,
es entsteht viel bessere Software, nicht nur sichere,
sondern auch bugfreie Software,
wenn man die gesamte Software
direkt so anlegt, dass man sagt, okay, bei der Produktion
der Software, ich mache mir vielleicht vorher Gedanken,
ich würde nicht mal sagen, viel über die
eigentlichen Zertifizierung oder
die Prozesse, sondern vielleicht mehr
wie lasse ich die entwickeln?
Wie sorge ich dafür, dass das, wie ich eben
erwähnt hatte, Code Review, also
wie sorge ich dafür, dass das halt schon
bei der Entwicklung
direkt die Software sicher ist? Weil nachher das
draufzubauen ist immer schwieriger. Also nachher
mit dem Scanner zu suchen ist, glaube ich, schwieriger als
zu sagen, okay, ich habe Entwickler,
die sich direkt darüber Gedanken machen.
Das ist ja zum Beispiel total kaputt. Also ich
hatte jetzt irgendwie mal so die Situation, dass
so ein Konzern da war, die wollten
dann Software bereitstellen und dann haben sie
gesagt, nee, aber neue Software ist irgendwie komisch,
wir wollen die alle auditieren vorher, so persönlich,
also als Security-Team und haben dann so
ein Service dann rausgebracht, dann
jetzt im November und da war dann Django
1.10.4, weil das dann die sichere Version
war, das ist also LTS war 1.11, für alle, die es noch
wissen, das ist halt schon ein altes System und da
gibt es halt dann irgendwie schon jede Menge irgendwie Exploits,
wenn man irgendwie genug nachsucht, die irgendwo drinstehen
und das wird dann von den Leuten irgendwie
geauditet und man fragt sich halt so, okay, was machen
die denn da eigentlich, so, warum tun
die das? Und das ist halt vielleicht so ein, ja,
das kriegt man, glaube ich, gar nicht so gut in die Hüfte.
Das ist halt wieder der Griff in Richtung Product Security statt
Process Security.
Also
ein prozesshafter Ansatz und wir haben jetzt ja auch
seit eineinhalb Jahren, nee, seit, doch,
seit ein bisschen mehr als eineinhalb Jahren machen wir bei uns
ISO 27000 und
der Trick ist
halt bei vielen, die prozesshaften
Security-Sachen werden häufig missverstanden,
weil die Standards, die es
dazu gibt, wie eine Keule
aussehen, obwohl sie eigentlich gar nicht so schlimm sind.
Man muss da bloß, wenn man die Standards
interpretiert, immer unterscheiden zwischen
was fordert der Standard formal
und was ist im nächsten Satz schon nur noch die
Implementationsguideline,
wo man dann eigentlich
selber Hoheit hat. Also ich habe halt
auch jemanden,
der meinte, der ISO 27000,
seitdem müssen wir sämtliche
Stromkabel einmal im Jahr
irgendwie auf die Erdung
prüfen. Also
nee, musst du nicht, ich habe auch nur
27.000, aber dann müsst ihr das doch auch mal so, nee, müssen wir
nicht. Ja, aber, aber,
ja, nee, müssen wir nicht.
Und dann dreht man so eine Schleife mit,
die ISO sagt, du musst dich halt um die für dich
relevanten Normen und Vorschriften
kümmern, das sagt die ISO 27.000,
also macht man das
und die sagt aber auch, du musst sie
bewerten und musst
dann Schlussfolgerungen für dich daraus ziehen.
Und es ist völlig
legitim im Rahmen der ISO zu sagen, ja,
wir haben zur Kenntnis genommen, dass
ortsveränderliche elektrische Verbraucher
irgendwie alle zwei Jahre auf X geprüft werden
müssen.
Machen wir nicht.
Aber jetzt kannst du doch mal erklären, was für eine Lücke das
offen lassen könnte, warum man das
testen wollen möchte.
So, naja, ISO als Prozess,
die ISO als Informationssicherheitsprozess
ist extrem umfassend
und zwingt dich dazu,
den kompletten Wertschöpfungsprozess
von einem IT-System
zu betrachten. Da gehört halt dann unter anderem auch
dazu, dass
dass du eben rechtliche Rahmenbedingungen bewertest etc.,
weil du musst am Ende immer für alle deine Assets,
und Philipp hat das halt schon, die vier Grundsicherheitsaspekte,
also bei uns sind sie aufgeschlossen, manchmal wären es drei, manchmal wären es vier,
halt nach Vertraulichkeit, Confidentiality, nach Integrität, Integrity,
nach Authentizität und nach Availability zu schütten.
Und was hat das jetzt damit zu tun, dass da so ein Stromkabel ist, in das sich …
Strom ist zum Beispiel für die Availability relativ wichtig.
Okay, also Availability, okay.
Und du misst halt dann da quasi nur die Stromleitung,
um zu testen, ob das Ding irgendwann mal ausfällt.
Es ist halt eine deutsche Norm,
die kommt aus dem, ich weiß nicht, welches ist,
die schreibt halt vor,
dass halt alle ortsveränderlichen Verbraucher
auf Fehlerstrom zu prüfen sind, alle zwei Jahre halt so.
Und wenn die ISO halt sagt,
du musst halt alle für dich gültigen Rechtsnormen berücksichtigen
und überwachen etc., dann schlägt sowas halt auch zu.
Was die Leute aber eben häufig missverstehen, ist, dass in der ISO drinsteht, du sollst es bewerten.
Und du sollst für dich daraus ableiten, ob das jetzt was Relevantes ist oder nicht.
Du kannst als Geschäftsführer oder als CISO an der Stelle immer sagen, okay, ich habe da fünf Risiken gesehen, ich akzeptiere die.
Jetzt hast du aber meine Story kaputt gemacht.
Ich wollte eigentlich die Story hören, wie man durch das Stromkabel in den Rechner des CISOs einringt.
Das Stromkabel, also das kann zum Beispiel passieren, wenn du deinen Prozessor aufstellst und sagst, naja, Stromkabel sind für uns keine sicherheitsrelevanten Dinge, deswegen kaufen wir die aus der Grabbelkiste beim Euroshop nebenan.
Das heißt, dann verkaufen die dir plötzlich en masse Dinge, wo sie wissen, in einem halben Jahr geht da drinnen irgendwas kaputt und dann geht bei dir im Rechenzentrum mit einem Mal das Licht aus und dann ist deine Verfügbarkeit hin.
Und weil dein Redundanzkonzept natürlich davon ausging, dass dir niemand so ein Ding untergejubelt hat mit der Absicht, dass da ein kleiner Sollbruchkondensator oder irgendwas drin ist, der dann halt nach so und so viel schönen Laufzeit einfach eine Schmelzsicherung durchgehen lässt.
Also das ist glaube ich auch erstmal nur relevant für so Atomkraftwerke oder sowas, die halt dann vernünftige Kühlung brauchen.
Nein, das kommt auf deine Angreifer und die Motivation der Angreifer drauf an.
Also die Story da drumherum wäre zum Beispiel, jemand zu sagen, wir betreiben Dienste sehr, sehr lange, teilweise 10, 15 Jahre und länger.
Das heißt, wenn ich, und auch teilweise mit politischem Impact, also wir haben ein paar Systeme, die sind unter anderem zu uns gewandert, extra aus Amerika raus, von Non-Profits, die unter anderem im Nahen Osten halt aktiv sind.
Und die haben ein massives Sicherheitsbedürfnis um das Leben derer, deren Daten in dem Ding drin stehen, weil da halt Decknamen und so ein Zeug auftauchen.
Und die, wenn du dann halt sagst, naja, wenn da jemand ein richtiges Longgame spielt und sagt, ich hab hier drei Jahre Zeit, das ist nicht das Problem.
Ich will aber, dass diese NGO mal so richtig gegen die Wand fährt, dann farbe ich jetzt die Lücke und sage, aha, ich hab rausgefunden, deren Hoster kauft immer irgendwie aus der Grabbelkiste die Stromkabel.
das dauert jetzt, naja, der tauscht nur so und so oft
die Stromkabel aus, aber wenn
ich es schaffe, irgendwie ein Drittel
seiner Stromkabel durch meine mit dieser Schmelzsicherung
zu ersetzen, dann bin ich in drei Jahren
soweit, dass dann irgendwie bei dem das RZ
implodiert.
Das ist sozusagen
die, und da muss man immer
aufpassen,
da kommt dieser, welcher XKCD ist
das mit der hohen Verschlüsselung und dem
der 5-Dollar-Entschlüsselungsmaschine?
XKCD, bitte
nochmal einmal.
XKCD, Comic.
Wo die Idee ist,
dass du eine ganz, ganz teure Verschlüsselung
kaufen kannst, mit super zertifiziert
und dann kommt aber jemand
zu deinem Admin mit einem
5 Dollar Baseballschläger
und bedroht ihn dann und sagt, okay, gib mir das Passwort.
Wenn das für dich gibt, dann
hau ich dich mit dem Schläger und dann bringt
dir die beste Zertifizierung und die beste Sicherheit
nichts. Ja, tatsächlich, ja.
Und man sagt halt auch an der Stelle, weil häufig,
gerade dieses Thema Advanced
Persistent Threat, also
die typischerweise staatlich
finanzierte Organisationen
oder Teams, die irgendwo reingehen sollen,
man sagt halt auch so schön,
gegen den Mossad
schützt du dich
nicht, weil
der Mossad interessiert nicht,
was du für Security irgendwo in deinem RZ hast.
Der kommt zu dir nach Hause und nimmt
dich mit und dann reden
wir nochmal.
Und deswegen ist, wenn man das mal schluckt und sagt, okay, ich bin hier nicht der, der sich gegen den Mossad schützen muss, weil ich habe eh keine Chance, dann brauche ich aber auch nicht so tun, als wenn ich sozusagen alles auf dem Niveau machen müsste.
Oder du brauchst einen eigenen Geheimdienst.
Bitte?
Oder du brauchst einen eigenen Geheimdienst.
Ja, genau.
Aber das Fiese am Internet ist ja,
dass du immer mit den besten Angreifern kommunizierst.
Das heißt, vielleicht nicht mit dem Mossad,
aber vielleicht hast du irgendwelche russische Hacker,
die durchaus was draufhaben.
Und die installieren dann halt,
wie hier in der Uniklinik Düsseldorf,
deine Ransomware.
Und die sind auch fast auf dem Level
von so einem Advanced Persistent Threat.
Die haben vielleicht jetzt nicht so...
Also, die machen schon ein bisschen Streufeuer,
aber die haben durchaus das technische Know-how
und auch die Zeit.
Und die machen sich auch die Mühe, das an deine Architektur anzupassen.
Also vielleicht noch mal kurz, Uniklinik Düsseldorf, da gab es einen Vorfall, da sind die Server rausgefallen.
Und da das Netzwerk intern nicht geordnet war, konnte man durch den einen befallenen Rechner irgendwie mehrere OP-Säle ausknipsen, wenn ich das richtig verstanden habe.
Ja, ich weiß nicht genau, was da passiert ist, aber war ein bisschen nicht verfolgt, muss ich zugeben.
War aber auch, glaube ich, nicht der erste Fall in Deutschland und ich glaube, das hat es auch ein paar Mal so richtig erwischt.
Nee, natürlich. Also das ist halt ja jetzt erstmal, die Mossad-Beispiele kommen immer zu dem Thema, wenn man anfängt, die Physical Security halt extrem stark zu übertreiben. Und das ist aber dummerweise auch das, wo Leute gerne übertreiben, weil das können sie sich bildlich vorstellen.
Dann kommt halt immer noch ein, ja warum ist hier vor dem RZ keine Panzersperre und alle nur, ja, denkt dran, Panzersperre hilft dir nichts, weil in Deutschland hat die Feuerwehr, guck mal da draußen, siehst du diesen kleinen unauffälligen grauen Kasten? Da ist der Generalschlüssel für das ganze Haus drin.
Ja, wie? Na, das ist der Feuerwehrschlüsselkasten, da gibt es einen Feuerwehrschlüssel, den hat die Feuerwehr, die kann das Ding aufschließen, die kommt hier rein.
Also spar dir mal bitte deine Panzersperre.
Also deswegen, das ist immer so dieses für mich bloß abzugrenzen von, wenn du das Niveau hast, musst du dir nochmal um ganz andere Sachen Gedanken machen.
Und wenn man das aber mal so übertrieben hat, dann wird den Leuten schnell klar, dass Security halt eine Abwägung ist und eine kontextspezifische Abwägung.
Und immer nur auf 100% zu schalten, geht halt nicht.
Und damit macht man auch mehr kaputt.
Ich würde halt nochmal anknüpfen an den Punkt von
dieser Prozessempfehlung. Ich würde halt
immer versuchen, an allen Enden
weniger ist mehr zu machen.
Weniger Code, den du schreibst,
ist typischerweise weniger Architektur, über die
du nachdenken musst, ist weniger. Und damit
auch ein Team, was gerade erst anfängt, würde ich eben
nicht sagen, ihr fangt jetzt mal an, euch über Security
Gedanken zu machen. Auch bei uns
in der ISO ist es halt, in unserer
Umsetzung der ISO 27000 ist es halt auch
so, dass wir sagen, du willst irgendwie
neues Feature für die Plattform etc. entwickeln? Ja, mach halt.
Ja, mach halt.
Ja, und du kannst gern auch irgendwie deine
drei, vier Testmaschinen auf der Plattform halt
schon mal auf diese Branch umstellen.
Habe ich kein Problem mit. Aber,
bevor das dann halt in großen Einsatz kommt,
muss das halt mal durch eine
Vier-Augen-Review durch. Und dann musst du mal
irgendjemand anders erklärt haben, was du dir gedacht hast.
Und dann gibt es dort eine Checkliste
und die fragt, jetzt erklär mir mal, was du dir
für Security für Gedanken gemacht hast.
Und das ist im Prinzip, das ist bei uns
der komplette formale Prozess
für die Entwicklungssicherheit.
Also übertrieben jetzt ein bisschen,
aber im Prinzip ist sozusagen bei uns nur ein
ja komm, entwickle halt, da drüben
sind die zehn Guidelines, was man in welchen Situationen
so alles mal berücksichtigen könnte.
Und aber das Einzige, wozu wir dich zwingen, ist,
du musst in dem Pull-Request, wo dein
Feature in die General Availability geht,
musst du mir oder deinem
PR-Reviewer glaubhaft vermitteln,
dass du dir jetzt wirklich adäquat zu dem
Ding Gedanken gemacht hast.
Schreibt man das dann als Text in den
Pull-Request? Als Text in den Pull-Request rein.
Da gibt es zwei Fragen. Das eine ist, was sind hier die Sicherheitsanforderungen? Und B, wie habt ihr die erfüllt? Wo ist hier der Nachweis, dass die erfüllt wurden? Wie seid ihr zu der Frage gekommen von, was sind hier die relevanten Sicherheitsanforderungen? Und wie weist ihr nach, dass ihr das jetzt halt ordentlich umgesetzt habt?
Das hört sich so ein bisschen an, als sollte man die Angst weglassen und tatsächlich nur, also die Worst-Case-Szenarien, also was ist das Schlimmste, was passieren kann? Also bei dir wären zum Beispiel jetzt Daten weg gewesen, das wäre nicht so gut gewesen, weil die so sehr privat sein müssen. Und an anderer Stelle ist es vielleicht so, ja okay, wenn man die Backups noch hat, dann ist es halt nicht so schlimm. Und das ist halt dann vielleicht der Worst-Case und da muss man sich halt Gedanken darüber machen, dass der nicht eintreten kann und der Rest ist dann egal.
Auch bei uns ist es so, unser Auditor zum Beispiel sagt halt auch immer, ein Unternehmen, was hochsicher ist und aber am Markt kein Produkt platzieren kann, hilft halt nicht. Es geht halt nicht. Und dieses Angstthema ist da schon relevant, weil halt Angst ist, häufig wird Security, gerade wenn es eine eigene Abteilung ist, immer wahrgenommen als, das sind halt die, die halt nachher unterschrieben haben sollen mit, hier ist alles sicher und deswegen sagen sie per Default einfach nein.
Und für uns ist der Review-Prozess aber zum Beispiel auch umgedreht. Der Review-Prozess in einem PR bei uns ist halt immer nur ein, ja, man darf nicht alleine Zeug nach draußen prügeln, Sternchen, Fußnote, doch, es gibt Situationen, in denen man das darf, aber dann muss man noch mehr Dinge beachten, weil es gibt halt bei uns auch so Gefahr- und Verzugssituationen, dann muss ich handlungsfähig sein.
aber der Pull-Request ist halt,
wenn der gemerged wird, ist das halt nicht die Aussage
von dem Reviewer, dass er
seinen Erstgeborenen irgendwie
mit Blut unterschrieben dem Teufel
überantwortet, dass er
sagt, hier ist alles sicher,
sondern der Vier-Augen-Prozess ist
dafür da, dass ein zweiter Mensch
dem ersten nochmal in die Augen guckt
und sagt, also wenn
du jetzt nicht noch sagst, ich soll nach
irgendwas schauen, dann merge ich den Kram
jetzt. Also das ist aber dein Code,
den ich jetzt gleich merge.
Und das ist ganz spannend, weil das ist ein kognitiver Prozess, der halt einer Person, einem anderen Menschen, und da gehört Empathie eben mit dazu, gegenüberstellt und sagt, ich lasse das hier raus. Du hast jetzt gerade gesagt, du sagst mir, das ist das Beste an Arbeit, was du abzuliefern hast und ich gucke mit dir nochmal gemeinsam drüber, aber ich werde es nicht aufhalten.
Ich bin hier nur der, der deinem Gewissen nochmal auf die Sprünge hilft, zu sagen, na, hast du nicht doch abgekürzt? Bist du dir wirklich sicher? Ich lasse das jetzt raus. Und das macht einen ganz massiven Unterschied, weil dann, was passiert? Die Änderungseinheiten werden kleiner, klassisches agiles Thema, weil die Leute nicht mehr sagen, oh Gott, oh Gott, oh Gott, der Review-Prozess ist so aufwendig, dann muss er sich aber auch lohnen, sondern wir drehen es halt um und sagen, nee, der Review-Prozess ist erstmal freundlich und der Default ist, wir gucken da zusammen drüber.
und alle machen ihre Arbeit und reden drüber
und klären das und dann lassen wir es auch
raus und dann ist der in 5 Minuten erledigt.
Also wenn ich halt zum Beispiel nur
weiß ich, ein Pull-Request bei uns kann sein,
Paket-Update vom Nginx, weil
war ein CVE drin, kommt die nächste meiner Version.
Ein CVE ist ein Vulnerable, was?
Ja genau, also
war eine Vulnerability, die bekannt war,
die haben einen Patch bereitgestellt, wir spielen den Patch ein.
Dann ist der Diff bei uns auf der Plattform
typischerweise so zwei Zeilen lang,
also irgendwie Version vom Nginx
hochgedreht und den Hash halt angepasst.
und die Review dazu sieht dann so aus,
ja, ne, machen wir, oder?
Ja, was war da noch drin in der
Änderung? Ja, nix, war nur der CVE.
Und beim NGINX? Ja, auch nur
der CVE. Ja, jut, okay, was waren
hier die Anforderungen? Anforderung war, wir
müssen Updates machen, weil wir die Sicherheit
aufrechterhalten sollen. Nachweis,
naja, das ist jetzt die alte Version, war die, die neue ist
die, zack, fertig, raus damit, Ende.
That's it.
Das ist halt den Leuten
in den Prozessen das so an die Hand zu geben,
dass sie nicht jedes Mal vor so einer Checkliste stehen von,
du musst jetzt aber umhalten, damit dir nachher keiner den Kopf abbeißt.
Weil das ist ja dann alles immer nur noch Ass-Covering,
dass niemandem die Schuld zugeschoben werden kann.
Und das ist ja nicht der Prozess, um den es geht,
sondern der Prozess ist, dass Leute produktiv arbeiten können.
Und während dieser Arbeit, der Vektor der Änderung immer heißt,
mit jeder Änderung machen wir es erst mal potenziell sicherer und nicht unsicherer.
Und wenn man dann sagt, okay, wenn ich das für alle Änderungen sicherstellen kann,
dass alle Änderungen die richtigen Vektor haben,
ja, dann mache ich doch einfach mehr Änderungen
und werde halt immer sicherer.
Ja.
Ja, das ist interessant. Also was mir da gerade noch als Idee kommt,
es gibt da eigentlich ein Problem bei dieser Sache
mit den quasi Pull-Requests.
Wenn das jetzt nicht in so einer Firma ist, wo alle Leute da Ahnung haben
von dem, was sie tun, sondern wieder
den nicht ganz optimalen Fall angenommen,
dann kann sich jemand hinstellen,
kann sagen, er ist jetzt hier der Türsteher und der guckt sich das alles an.
Und
dann hat er
eine Existenzberechtigung, obwohl er eigentlich sonst gar nichts
tun muss. Und das kann dann
dieser Informationsasymmetrie
dann ausnutzen.
Für mich regelt das der Wettbewerb.
Eine Firma, die so drauf ist, wird halt
Schwierigkeiten haben, wirklich
innovativ nach vorne zu laufen.
Was ich halt noch spannend finde, ist, dass Python
natürlich, um mal die Schleife jetzt noch zu ziehen,
auch als
Sprache natürlich ein gutes Standing hat.
Ich hatte vorhin noch mal irgendwie durchgeguckt
und wenn man halt guckt,
wenn ich,
wir könnten jetzt sozusagen, also der
völlige Tiefschlag ist natürlich, wenn ich es gegen
PHP vergleiche.
Da habe ich halt das Problem, dass allein die
Laufzeitumgebung von PHP und die Sprache selber
ich hatte vorhin
geguckt, über die letzten 20 Jahre
über 600
CVEs eingesammelt haben.
Und die machen im Prinzip
in einigen Jahren das
Fünffache von dem, was Python über die
letzten 20 Jahre
insgesamt hat.
Also bei Python kamen irgendwie 20
CVS oder sowas raus über die letzten 20 Jahre.
Viel mehr kommt da einfach
nicht. Und
das ist halt auch schon mal was, wo man immer sagen kann,
okay, das ist was. Auf der einen
Seite die Sprache selber hat viele
Probleme nicht, sowas wie ein
Buffer-Overflow zum Beispiel, kannst du mit Python
erstmal so nicht erzeugen. Und es ist auch in der Community
ja so verankert, dass extrem viele
Bibliotheken, viele Frameworks
das ja auch als Thema für sich erklärt haben und
eben sagen, wir basteln
nicht nur um Security-Probleme rum, sondern versuchen
sie dann ordentlich zu fixen. Und es gab
auch in Python selber, also die Sachen, die es
gab, wenn ich halt schaue, das war mal
irgendwann ein libxml-Thema,
weil du halt zum Beispiel
libxml über
das externes Auflösen von Entities dann
irgendwie Code ausführen konntest und so ein Kram.
Aber
die wurden halt in der Community
immer sehr differenziert und schnell
diskutiert und auch
adäquat behoben.
Da
habe ich einfach eine völlig andere Basis, von der
ich ausgehe, als wenn ich praktisch
bei jeder Codezeile, die ich schreibe, da denke ich
dann eher so an C, tatsächlich
meinen Doktor-Kittel angezogen haben muss, um
ja, nicht daneben zu tappen.
Ja, dann hat, glaube ich, sowas wie Rust auch
deswegen gekommen, oder? Weil das genau das dann wieder
anders macht und
in den Griff kriegt, ja.
Ja, ja, also Rust ist auf jeden Fall,
also ich meine, es kommt halt
darauf an, was man jetzt,
ich glaube, eben vor Buffer-Overflow,
so muss man gar nicht so viel Angst haben, aber
wenn man jetzt Server betreibt,
die halt super viele Requests bearbeiten
oder so.
Was hat letztens in einem
Podcast irgendwie der
Entwickler von Flastia
Armin Ronacher gesagt? Er meinte so, Rust
ist halt für ihn schon
allein deswegen so viel netter, weil
Python hätte er ja auch irgendwie
sehr gerne gemacht, aber das liegt halt wie Sau.
Das ist halt, da kann man
nicht viel dran machen. Und das ist
natürlich schon irgendwie
so.
Das würde ich gerne verstehen, weil da geht mir
Philipp dreht den Kopf und ich
habe auch so ein kleines Messer, was mir in der Tasche aufgeht.
Ja, ja, klar. Also es ist
muss, aber ich kann
schon in gewisser Weise verstehen, was er
meint. Also ich meine, bei Rust kannst du dir halt
sicher sein, dass da nichts liegt,
wenn du es halt richtig machst.
Was meinst du denn damit da liegt was rum?
Naja, zum Beispiel,
dass halt
der Hauptspeicher immer weiter anwächst, ohne
dass du das eigentlich wolltest, ja,
sozusagen, ohne dass du wirklich den Hauptspeicher brauchst,
sondern dass halt Sachen nicht wieder
weggeräumt werden, die halt irgendwann mal angefallen sind.
Klar, also Python
nimmt dir das Memory-Management halt komplett
weg und
das ist tatsächlich Fluch
und Segen zugleich, logischerweise.
Also jede technische Entscheidung der Hinsicht hat
immer Trade-Offs und ein Aspekt
bei Python ist nun mal, dass Python
Speicher, den es mal gebraucht hat,
auch wenn es den Akut gerade nicht braucht,
nicht einfach mal so wiederhergibt.
Also wenn dein Prozess
mal irgendwie, keine Ahnung, ein Gig oder zwei Gig groß
ist, dann kann
es gut sein, dass der das jetzt für die nächste Zeit
mal behält, auch wenn du alle Objekte gelöscht hast
und wenn die Garbage Collection durch war,
weil es ist halt auch ein Trade-Off
zu sagen, naja, ständig
Mellocs groß und klein und
groß und klein zu machen, hat auch
Nachteile. Es hat Nachteile in der Hauptspeicher
Fragmentierung, das ist an sich ein Performance
Thema, jada jada jada jada
und Python als Universalsprache
in der Hinsicht, wo eben Memory Management als
ich kümmere mich drum, draufsteht,
verstehe ich, dass es in diese
Richtung neigt, eben eher diesen
universalen Ansatz da zu verfolgen. Und Rust
tritt nun mal an mit, du hast deinen
Speicher im Griff, dann müssen sie das auch abliefern.
Das ist klar.
Also nochmal ganz kurz, vielleicht, was
ein Melloc ist, also du alloziierst
irgendeinen Speicher, oder?
Genau, also wenn du
vom Betriebssystem halt Speicher haben möchtest,
dann ist es ja heutzutage
eh schon nur noch virtueller Speicher. Also
Also dass das in deinem Rechner irgendwie 8 Gig, 16 Gig oder halt mal ein halbes Tera oder ein Tera RAM drin ist, das weiß ja kein Programm.
Das guckt auch kein Programm so wirklich nach heutzutage, sondern ein Programm geht her und sagt, ey, du, könnte ich mal irgendwie Speicher im Wert von 3 Terabyte haben?
Und dann sagt normalerweise der Linux-Kern heutzutage, klar, kein Thema, hier hast du.
Und erst in dem Moment, wo es das dann auch anfängt zu beschreiben, sagt der Kern, ach, du willst es auch noch benutzen?
Na dann, dann teilt er ihm tatsächlich irgendwie diese Sachen zu.
Und deswegen gibt es einige Programme, MongoDB ist halt auch so ein Ding,
die alloziieren zum Beispiel immer bloß in Vielfachen von 2 oder in 2 Potenzen oder so ein Kram.
Also wenn der halt hergeht und sagt, ich brauche hier mal RAM,
dann sagt er als erstes, ich brauche 64 MB,
und dann irgendwie, ja jetzt hätte ich auch lieber 118 MB.
Okay, also jetzt hätte ich gerne 1 GB.
Und das kann manchmal schon so ein bisschen unangenehm sein,
aber der Vorteil ist halt, wenn der Speicher dann auch am Stück ausgeliefert wird,
dann hat das bestimmte andere charmante Aspekte,
weil dann bestimmte Overhead-Strukturen im Kernel dann halt reduziert werden können.
Der kann sogenannte Huge-Pages machen, das heißt, du musst dann halt nicht,
wenn du einen Gigabyte alloziierst, muss der Kernel halt nicht eine Million mal
eine 1-Kilobyte-Page irgendwo in seiner Tabelle abmarkern,
weil auch das kann plötzlich schon mal 2, 3, 4, 500 Millisekunden dauern,
sondern der sagt dann einfach nur noch, hier hast du das Gigabyte.
Und das sind so Sachen, wo Python dann eben auch häufig optimiert.
Und Python ist extrem erfolgreich, was diese Optimierung angeht.
Ein Beispiel dafür sind zum Beispiel Listen.
Listen haben eine, es gibt eine Operation bei Listen,
die ist unoffensichtlich O von 1,
nämlich ein, genau, ein Append an Listen bei Python ist, wie war denn das, ne, sind Listen nicht immer ein O von 1 Append?
Ja, sollte, wer weiß es, ich weiß es, da war, ne, es gab irgendeinen spezifischen Fall, also die Story drumherum grob ist die,
dass die Speicherallokation für Listen in Python auch immer nur verdoppelt.
Der alloziiert einen Buffer für das Array, um die Indizes zu verwalten
und alloziiert aber, wenn er dann sozusagen es größer machen muss,
nicht einfach sozusagen, dann muss er ja sozusagen das Ganze,
achso genau, das Problem ist, wenn du es dann größer machen willst,
musst du den Bestandsspeicher plus 1 nochmal neu alloziieren,
alles umkopieren und dann halt das neue reinschreiben.
Was Python aber macht ist, Python alloziiert immer dann das Doppelte von dem, was es vorher hatte,
kopiert das einmal um, dann sind die nächsten n gratis,
dann musst du wieder einmal verdoppeln, einmal kopieren und dann hast du wieder 2n gratis.
Und das sind so typische Sachen, die man in solchen Situationen halt hat,
was so Laufzeitumgebungen für einen automatisieren und machen
und weswegen sich dann hinten so ein bisschen komische Speichereffekte ergeben.
Und da habe ich lange, lange Zeit meines Lebens auch immer mit meinem Kopf kratzend davor gestanden
und konnte Leuten nicht erklären, warum es das jetzt gerade tut.
Und da muss man sich halt irgendwann sagen, kann man nicht erklären.
Warum es genau das jetzt gerade tut, kann ich dir nicht erklären.
Ich bin mir relativ sicher, dass es kein Leak ist, wenn du halt dann irgendwie mal sowas beobachtest
über eine Woche oder einen Monat, wenn du einen langlaufenden Prozess hast
und die Saisonalitäten findest und du was merkst wie, ah, okay,
frühmorgens haben die Leute ihren Kaffee getrunken, jetzt lesen sie alle irgendwie das,
auf deiner Webseite ist, dann geht ihr Speicherbedarf
irgendwie hoch, dann kommen abends
irgendwann die Cronjobs, dann geht er nochmal ein bisschen hoch,
dann passiert lange nichts und dann ist plötzlich,
gibt er mal wieder ein bisschen Speicher frei und dann ist es irgendwie gut.
Und wenn du dann
aber siehst, okay, über einen Monat ist das immer das Gleiche,
dann mag das zwar sein, dass er zu jedem einzelnen
Zeitpunkt mal einen Speicher hat, den er
jetzt gerade akut nicht braucht,
aber es liegt nicht.
Ja, ich weiß auch nicht,
was er damit genau gemeint hat.
Nee, ich verstehe das, dass er sagt, ich kann
zum Beispiel, in Python ist es schwierig,
kontrollierbar schlanke Prozesse zu bauen.
Das geht nicht so ohne
weiteres. Also das geht schnell, dass dein,
wenn du zum Beispiel
eine Datenverarbeitungspipeline hast mit
neun oder zehn Schritten und jeder
Schritt davon braucht irgendwie
einen Gigabyte RAM, dann kann das
schon sein, dass dein Python nachher zehn Gig frisst.
Weil er halt eben
den Speicher von vorher noch nicht freigegeben
hatte, der jetzt aber auch gerade nicht gepasst hat, um das
nächste Ding zu bearbeiten und
dann so. Das ist halt
das kriegst du unter Python halt nicht gut kontrolliert.
Ja, vor allem, weil alles so dynamisch ist,
weil ich also im Zweifel auch wirklich den Stack hochwandern
kann und schauen kann, was da rumliegt oder
ein Integer-Objekt als beliebiges Objekt sehen
kann, was halt in Rust ohne weiteres nicht möglich ist
und auch in anderen Poemischsprachen nicht geht.
Aber auch
ohne Speicherverwaltung kann ich ja in Python
durchaus noch andere Sicherheitslücken machen,
die also gar nichts mit dem Speicher zu tun haben,
mit dem, was wir jetzt die meiste Zeit
besprochen haben, sondern halt zum Beispiel, dass ich sage,
ich verwende den Subprozess
und öffne den Subprozess und
übergebe einen String
und habe diesen String halt
konstruiert aus Benutzerdaten und
jetzt habe ich plötzlich eine Command Injection,
dass man beliebige Shell-Commandos ausführen kann.
Das kann man
in jeder Programmiersprache
und in jeder Programmiersprache
die Shell-Commandos ausführen kann. Natürlich kannst du
dich auf den Standpunkt stellen, okay, man hat
das gefälligst nicht zu machen oder man hat
gefälligst immer Shell gleich freuds zu setzen
oder das ist ja der Standard, also dass man eine Liste
übergibt, aber
das sind die, also es gibt noch
zahlreiche andere Schwachstellen, glaube ich, die
in höheren, auf höherem
Level noch passieren können, die gar nichts mit dem Speicher direkt
zu tun haben.
Ja, absolut, genau, was habt
ihr, habt ihr schon mal böse Sachen gesehen,
die in Python schiefgegangen sind?
Ich weiß nicht, ich überlege
gerade, ob ich irgendwas mal
wirklich Schlimmes gesehen habe.
Django Rackaxe. Der Shellout,
den Philipp da nennt, das ist halt ganz klassisch.
Ja, das ist schon schlimm. Das ist ganz klassisch.
Auch sehr beliebt ist, wenn Leute
meinen, ich muss hier Flexibilität reinbringen
und jagen halt irgendwie User-Input einfach durch
einen E-Val durch. Das ist sozusagen
die interne Variante des Shell-Outs.
Was ist denn ein E-Val?
E-Val, ja, okay, Entschuldigung.
Ja, Funktion. E-Val ist Evil.
Aber das ist im Prinzip die
Oh ja, doch, Pickle.
Ei, ei, ei.
Ja, Pickle, nur trusted.
Da kann man sich
auch schon mit dem Fuß schießen.
Mit E-Val hat man sogar einen ganz, ganz schlimmen Bug.
Und zwar hat eine Anwendung auf die Idee gekommen,
dass man doch das cachen könnte.
Und man könnte doch den Code nehmen
und dann kann man sich so ein kurzes...
Also man nimmt irgendwelche Benutzerdaten,
die oftmals abgerufen werden.
Dann schreibt man dynamisch Python-Code,
der das ausführt.
Und dann kann man das cachen.
Und dann war aber das Problem,
dass sogar die noch eine Datenbank-Schwarstelle hatten,
dass man sehen konnte, was in der Datenbank lag
und da lagen deren Cache-Objekte.
Und dann lagen da plötzlich Benutzer-Passwörter
oder sonst irgendwelche Sachen.
Also da kann man halt, wenn man
Schwachstellen verkettet, kann man das
auf sehr krumme,
sehr fiese
Sachen, die man mit einer einzelnen Schwachstelle gar nicht machen
könnte. Also das war jetzt nicht
der Fehler von denen, dass sie, also es war
ein Fehler, dass man den Cache
plötzlich sehen kann. Und es war ein anderer Fehler,
dass sie überhaupt Eval verwendet haben.
Aber erst durch die Kombination ist es halt eigentlich eine
Schwachstelle gewesen.
Auch so ein klassisches Ding ist auch Directory Traversal.
Dass halt irgendwie
von außen sagen kannst, ich will XYZ
haben und dann wird halt nicht ordentlich
geguckt, ob du durch Punkt-Punkt-Slash
Kombinationen plötzlich dir dann irgendwie
ETC-Pass-Videos und so ein Kram halt auslesen lassen kannst
und das sind immer auch, das ist
tatsächlich, glaube ich, am wichtigsten
und deswegen ist dieses, das ist wieder
Variety matches Variety, deswegen
sagen wir, wir wollen so schnell so viele
Verbesserungen in der Security wie
möglich durch unsere Entwicklungspipeline jagen können,
weil
die eigentlichen Vektoren ist nachher, dass
du hast immer eine Vielzahl von
Vielzahl von potenziellen Schwachstellen,
die für sich genommen alle gar nicht so schlimm
sind. Und wenn du aber immer
nur auf der Suche nach dem einen großen Ding
bist, um alles zu reparieren,
dann vergisst man schnell, dass es halt eher um diese
Verkettung geht, wie Philipp sagt.
Da gibt es viele Kleinigkeiten, die das halt machen.
Also eben Directory Traversal, irgendwie Daten abzusaugen,
die dir dann einfach nur noch den Pointer geben für
ah, guck mal, da könntest du da drüben nochmal gucken.
Ein Klassiker, den ich mag,
sind Exceptions.
Exceptions sind für mich die sensibelsten
Daten, die dein System zur Laufzeit
eigentlich von sich gibt.
Weil das Problem ist ja folgendes.
Dein System ist in einem nicht bekannten Zustand
mit Daten, die du nicht kennst
und weißt nicht mehr, was es tun soll.
Und die Daten können halt alles sein.
Das können die Kreditkartendaten sein,
das können die was auch immer.
Und dann steht da irgendwie Value Error.
Hast du nicht gesehen?
Und du kannst den User nicht davon abhalten,
Daten ins falsche Feld zu schreiben.
Dann schreibt er seine Kreditkartendaten
halt das erste Mal irgendwie bei seinem Nachnamen aus Versehen
rein. Und deswegen diese
Bewertung von, was ist eigentlich sicher und was
ist unsicher, ist total schwer.
Das Paradigma sollte auch
eher sein, lieber ein bisschen
zu sensibel zu sein und sozusagen
dein Schutzniveau einmal grob
festzulegen und zu sagen, okay,
wir gehen ja mit Kreditkartendaten um.
Du musst davon ausgehen, dass irgendein
doofer User, nein, die User sind nicht doof.
Das Problem, es ist ein Usability-Problem.
Das Usability-Problem ist, dass wir halt ein Gehirn
haben, was bekloppt ist.
Da kommt dieses ganze Thema Cognitive Processing rein von, unser Gehirn will Energie sparen und deswegen reagiert es auf irgendeine Form von Challenge immer mit der billigstmöglichen Antwort, also Pattern Matching. Und das Pattern Matching von unserem Gehirn ist auch nicht Best Match, sondern First Match. Das heißt, du hast eine Seite vor dir, hast aus deinem Passwortmanager deine Kreditkartennummer kopiert, dein Kind will was von dir, ja bitte, ich muss nur noch, klick, klick, klick und dann hast du halt deine Kreditkartennummer in das falsche Feld eingetragen.
So, und das ist halt, wie man bei Microsoft damals, alle zwei Millionen Mal, ja, das ist bei uns halt nächsten Dienstag. Und sowas, und deswegen sagen wir auch, wenn wir Anwendungen dann mit Schutzniveaus belegen und sagen, was macht man hier, dann gucken wir eigentlich nur noch nach dem Worst Case und sagen so, jetzt müssen wir davon ausgehen, dass das ganze Ding mit dem Niveau geschützt werden muss.
Weiter differenzieren macht überhaupt keinen Sinn mehr, weil du kommst dann von Hölzchen zu Stöckchen und irgendwer greift eh daneben.
Und deswegen bin ich immer sensibel drum, wenn es darum geht, so Exceptions an externe Systeme weiterzuleiten,
weil im Prinzip übergibst du jemandem Externes alle deine Daten, weil du ja gar nicht weißt, was in der Exception drin ist.
Wenn du es gewusst hättest, hättest du halt schon irgendwas geschrieben, damit die nicht auftritt.
Wie bekommst du dann mit, wenn eine Exception passiert? Also an irgendein System muss das ja weitergeleitet werden.
Ja, internes System. Also ich meine, wir, also, ich habe mich hier heute jetzt noch nicht wieder vorgestellt, ich bin ja so ein bisschen Stammgast schon. Philipp und ich, wir kennen uns noch nicht, ja. Wir betreiben halt Systeme auf eigenen, wir sind ein eigener sozusagen Cloud-Anbieter in der Hinsicht und haben die Infrastruktur und wir machen das auch so, dass wir halt zwischen den unterschiedlichen Locations, die wir haben, halt entweder verschlüsselt Sachen weiterreichen oder eben lieber Dienste dezentral überall lokal nochmal vorhalten und dann musst du halt selber noch eine Greylock-Instanz da haben.
Und wenn man das heutzutage alles vernünftig ein bisschen automatisiert, dann lässt er halt noch eine Greylock-Instanz raus und kann sie dann da einfüttern.
Was ist Greylock, Christian?
Das ist ein Log-Aggregationssystem.
Also den kannst du mit Log-Daten befüttern und ihn dann nachher Parser drüber jagen lassen und dir automatisch Alerts schicken.
Das ist auch so ein Ding, da spielen wir gerade zum Beispiel mit rum für so Threat-Themen.
Der kann aus Log-Daten IP-Adressen rauspopeln.
und der technische Begriff für Parsen, und hatte halt dann wieder eine Anbindung an, daran abzugleichen, ob diese IPs assoziiert werden mit irgendeiner Form von, da kommen ständig Angriffe her.
Und dann kann ich die Auswertung dann wieder zurückfüttern auf meine Firewall vorne und kann sagen, so, und immer wenn irgendwie eine IP, die den Threat Indicator hat, irgendwie öfter als so und so oft pro Stunde vorkommt, dann wird die jetzt erstmal für drei Tage lahmgelegt.
Ah, das ist aber gefährlich. Es kann ja sein, dass jetzt irgendjemand auf die Idee kommt und sagt, okay, du hast einen ganz, ganz wichtigen Kunden, mit dem du immer kommunizierst und derjenige schafft es, irgendwie in das Netz reinzukommen von dieser IP und dann löst er diese Anfrage aus. Ich glaube, da gab es auch schon mal Virenscanner, die, sobald ein Paket kam, dann die gesamte IP geblockt haben und dann konnte man die lustig anschreiben von 8888, einem typischen DNS-Server und die haben gesagt, oh, das Paket sieht nach Virus aus, sofort blocken wir alles von diesem Rechner und dann geht nichts mehr.
Ja, genau. Da muss man immer mit vorsichtig sein und nichtsdestotrotz so ein bisschen mit so Sachen experimentieren, weil halt gerne mal rumzugucken, wie sie aussehen und dann willst du halt immer noch die Möglichkeit haben, nochmal durchgreifen zu können in dem Moment, klar.
Ja, aber ich meine, das ist, macht das auch solche Sachen wie, weil ich kenne das eigentlich eher so als, es gibt immer, entweder verwenden Leute diesen Kibana-Stack oft.
Kibana hört sich nach Kibakirsch-Banane an.
Ja, es schmeckt nicht so gut wie Kirsche oder Banane, leider. Aber klingt auch lustig, ja, nee, das ist so irgendwie Elasticsearch und also diese Richtung.
aber da werfen Leute auch Logdaten rein
oder halt eben Greylock oder
manche machen das auch mit Postgres oder
aber ich meine jetzt für Python
speziell, da gibt es dann irgendwie so
Sentry oder Bugsnack
oder so, wo die Tracebacks halt gesammelt
werden. Kann man sowas eigentlich auch
gut selber hosten, weil das habe ich jetzt tatsächlich
verwendet, aber ich kenne es auch immer nur, dass man
da externe Services verwendet.
Kein Problem, Sentry kann man ohne Problem, ist auch ein
Source-Projekt, kann man ganz normal selber hosten.
Kommt ja auch selber aus der Python-Ecke,
Ist, glaube ich, auch Django unten drunter oder so.
Ich bin mir gar nicht mehr sicher.
Ja, war es mal.
Aber stimmt, ist auch, genau.
Vielleicht nicht mehr.
Century ist ja relativ groß geworden tatsächlich, Armin und so.
Und die kannst du selber hosten tatsächlich an der Stelle.
Das würde ich dann auch immer empfehlen.
Wichtig ist sozusagen der Unterschied von der Log Aggregation
versus Exception Logging.
Exception Logging hat die große Aufgabe,
wenn du viel vom Gleichen
entgegenkriegst, weil irgendwie der eine
backt gerade 50.000 Mal im letzten
Tag auf, dann willst du, dass der dir die
schon normalisiert und sagt, hier, das Problem
gab es jetzt in 50.000 Instanzen,
hier sind die Parameter, die ich gesehen habe.
Logging macht natürlich immer nur,
hier ist der Hydrant, hier kommt
alles raus.
Ja, interessant.
Da gibt es also viele verschiedene Typen von
Angriffen, die man irgendwie mit verschiedenen
Typen von Verteidigungsmaßnahmen beantworten
möchte, können muss,
probieren kann.
Sollen wir uns mal
unbeliebt machen? Oder ich mach mich unbeliebt.
Wir, ein Scanner oder sowas.
Ich meine, was Leute immer so machen, wenn sie zu Hause,
ich meine, vielleicht,
sehr beliebt,
aber irgendwie glaube ich zum Beispiel,
das bringt alles nix.
Vor allem müssen die ganz viel
mit Speicher machen und ganz viel
Level erarbeiten. Genau, das, was man eigentlich nicht haben will.
Also wo ich es noch sehe,
wo ich noch mitspiele, ist, wo wir es
gern haben, wo es angefragt wird
und dem nicht harsch
widersprechen, ist,
wenn du sozusagen tatsächlich
sowas hast wie, deine Anwendung nimmt Daten
per Mail oder Upload entgegen und du weißt,
die werden dann nachher auf eher schlecht
gepflegten Rechnern wieder weiterverarbeitet.
Also wir haben so ein Kram, wo dann
irgendwie, keine Ahnung, Wordfiles reinkommen und die sollen
dann von irgendeiner dritten Partei auf ihrem
Windows-Rechner verarbeitet werden.
Dann habe ich halt mal einen
Klamm-AV da mit drauf sitzen, der halt
diese eine Datei scannt, aber das ist
dann kein Ding, was das System scannt,
sondern es ist bloß ein Programm.
Hier scannt die eine Datei, du sagst, ja, okay,
dann geben wir die weiter und wenn nicht, dann
sperren wir sie halt zur Seite. Das ist
eine Form von Virenscanner, da spiele ich punktuell
halt noch mit. Das kann man
schon mal machen. Was ich halt nicht leiden
kann, sind diese Security-Suites,
die dann irgendwie einen Rechner irgendwie übernehmen
und irgendwie mehr Schaden machen als
also gut, ich meine, da braucht man bloß
Fefe lesen, da kriegst du es halt alle zwei Wochen wieder
serviert, Schlangenöl und so.
ein gutes Konzept
was ich eben noch
kurz erwähnt hatte, was ich mir ja noch irgendwann
drüber gestolpert bin, was bei Django eine
DOS-Attacke möglich war, und zwar
bei Regex, die benutzt worden ist
um bestimmte Formularfelder auszulesen
das heißt man konnte einfach, indem man
in Formulare, ich glaube E-Mail oder so
einen cleveren Regex reingeschrieben hat
irgendwie eine
exponentiell wachsende oder Endlosschleife
produzieren und dann damit die Seite
man kann Regex
zu bauen, die sehr, sehr langsam werden dann.
Genau.
Dann hat man einfach ganz viele Requester dran geschickt und dann hat man halt die Seite
in die Knie ziehen können. Das haben die irgendwann gefixt.
Ich glaube auch relativ spät, erst bei einer Zweier-Version,
wenn ich das richtig bekommen habe.
Sehr interessant, solche Sachen. Also das
denkt man immer, jemand, der keine Ahnung hat, nicht dran,
dass in so einfachen
Bibliotheken wie RegEx da was Tolles hinterstehen
kann. Ich glaube, was ist das? Perl RegEx oder wie
nennt man das? Diese Perl Compatible
RegEx, also PCIe, aber ich
weiß nicht, ob das...
Das ist nicht in Python. Die Python-Regex-Engine
ist eine eigene.
Also moderne Regex-Engines können schon
nicht alle Fälle, aber viele Fälle
da besser erkennen und haben dann
auch bessere Garantien, also nicht erkennen,
aber haben Garantien, dass das halt nicht
in diesen exponentiellen Fall läuft. Natürlich nicht immer.
Und natürlich kann ich immer ein Regex produzieren,
der einfach so lange dauert, weil ich einfach
sage, okay, hier kommt irgendwas Beliebiges
und das darf beliebig oft vorkommen.
Und wenn ich da einen langen String habe, dann ist es halt total,
dann gibt es
natürlich exponentiell viele Möglichkeiten,
wie ich das Matching
nehmen kann. Und wenn ich den String so konstruiere, dass das Matching
nie passiert, dann dauert
es halt ewig. Also unendlich
nicht, aber schon mal länger ist das Universum.
So, ich mach ja mal
kurz, wir müssen die Chapter-Mark hier ziehen.
Ich muss jetzt raus.
Ihr könnt mich rausschneiden.
Ich kann jetzt raus, du kannst einfach Tschüss sagen.
Ja, wir haben eine Sekunde Pause gehabt,
das könnt ihr rausschneiden.
Alles klar.
Tschüss, vielen Dank, dass du da warst.
Bis zur Fortsetzung demnächst mal wieder.
Viel Spaß, bis dann. Ciao.
Ja.
Haben wir denn zu dem
Security-Thema noch irgendwie,
ich weiß nicht genau, irgendwelche Dinge,
die wir unbedingt erzählen
wollten, oder?
Ja, also,
mir fallen noch einige Sachen ein, aber frage ich erst mal euch weiter.
Was geht's denn, Philipp fragen wir nochmal. Was wolltest du denn noch
erzählen zu Security?
Es gibt, also,
was vielleicht wichtig ist,
dass man eine Funktion
nimmt, oder eine Standardmöglichkeit
nimmt, um sich gegen die Sicherheit
Schwachstädte zu verteidigen. Also wir haben eben schon
Path Traverses angesprochen, da könnt ihr mal denken,
okay, also bei Path Traverses ist das Problem,
dass ich irgendwas in den Pfad einschleuse,
typischerweise halt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
typischerweise halt ... um halt aus dem Pfad der Anwendung rauszukommen
und dann statt eine lokale Datei der Anwendung zu lesen,
bekomme ich halt eine Datei irgendwo aus dem System.
Weiß nicht, die Passwortdatei oder die Datenbankdatei oder irgendwas anderes.
Und eine Möglichkeit, um sich dagegen zu verteidigen, ist natürlich zu sagen,
ich nehme immer alle Punkte raus oder so oder alle Slashes raus.
Und dann kommt man halt auf andere Systeme, zum Beispiel unter Windows,
da ist ja ein Doppelpunkt wichtig.
Und dann muss man auch an den denken und dann ist der Backslash wichtig.
Und es ist halt sehr schwierig, sowas richtig zu schreiben.
Da gibt es immer wieder Leute, die es versuchen.
Die sagen, ja, ich weiß es trotzdem.
Und bei einigen Systemen geht das auch.
Also man kann zum Beispiel bei SQL Injection kann man relativ einfach vermeiden,
weil das halt eigentlich nur ein einfaches Anführungszeichen ist.
Aber es ist halt immer gut, dann für eine fertige Funktion oder eine fertige Struktur zu nehmen,
die genau dafür programmiert ist.
Und die dann auch, zwar die sicher ist, aber die ist halt sicher oder hoffentlich sicher,
weil es halt nur eine ist. In Python
zum Beispiel, um Path-Traverse zu verhindern,
kann man halt os.path.basename
oder aus der Path-Lib was nehmen,
statt halt selber zu versuchen,
diesen String zu bearbeiten.
Also nicht selber machen, Security war das der...
Ja, genau. Es sei denn, man weiß,
was man tut. Also an einigen
Stellen kann das richtig sein. Und ich glaube,
ein anderes häufiges Problem ist auch, dass man sagt,
ich versuche, die Eingaben
zu früh
abzufangen. Also dass ich sage, okay,
ich habe eine ganz komplizierte Anwendung und immer,
wenn mir jemand was mit einem Anführungszeichen schickt, dann sage ich, geht nicht, ist Fehler oder ich schmeiße das Anführungszeichen raus und das ist natürlich klappt vielleicht, aber dann muss ich halt überall dran denken und es gibt halt verschiedene Kontexte, also wenn ich einen Pfad habe, dann ist halt ein Slash oder ein Backslash ein Problem, wenn ich aber HTML habe, dann ist das kleiner Zeichen oder das doppelte Anführungszeichen ein Problem und so weiter und so fort, das heißt, es ist wichtig, dass man darauf achtet, dass man das in jedem Kontext richtig macht und es ist schwierig zu sagen,
oder es ist ein häufiger Anfänger vielleicht zu sagen,
okay, ich gehe davon aus, dass meine Daten
irgendwie korrekt sind. Das ist dann doch immer
sehr schwierig, weil man halt ein komplexes
System hat, vielleicht sogar mit mehreren
Microservices, die die Daten aus verschiedenen
Quellen
anliefern. Aber wenn man darauf vertraut, dass
die Datenbank irgendwie gute Daten enthält, das ist
immer sehr, sehr gefährlich.
Ja, ist interessant, welche Assertions man
daraus gibt oder welche Dinge man daraus macht, wenn
das nicht dem erwarteten Standard entspricht oder so.
ein paar Stolper fallen. Dass man einfach interpretiert,
was da kommt, ist wahrscheinlich
eine mittelgültige Idee. Genau, man muss immer misstrauisch sein gegenüber allen Daten.
Also auch der eigene Datenbank, auch die kann
Schrott enthalten.
Okay, guter Tipp.
Ja.
Ja, ansonsten, genau, ein Thema, wo ich immer
denke, das kann doch nicht so schwer sein, aber
ich tue mich irgendwie schwer damit,
ist halt, wie authentifiziert man sich eigentlich
richtig irgendwie
zum Beispiel per
einer API per HTTP oder so
oder die Web-Authentifizierung
ist irgendwie nicht so einfach.
Und dann, ja.
Es gibt ein paar interessante Artikel dazu, die wir
letztens gelesen hatten, warum
JBT kaputt ist.
Ja, JBT sieht nicht gut aus, ja.
Und dass ja viele Leute nutzen und sagen, das ist der Standard,
den es da gibt. Und ich habe aber
auch jetzt auch noch nicht so viel gefunden, was man da anders
machen kann. Es gibt irgendwie Paseto oder
PyPaseto, aber da gibt es noch nichts wirklich Nutzbares. Das muss man
irgendwie auch alles wieder selber machen
vielleicht und das ist da vielleicht wieder nicht so
eine gute Idee und da ist es gar nicht so
einfach, sich vernünftig per Token zu authentifizieren.
Ja, tatsächlich. Also das, was ich jetzt auch
ist halt, ja, HTTP-only-Cookies.
Ja.
Vielleicht. Also Sessions dann?
Ja, Sessions, Session-Cookies.
Ist halt manchmal ein bisschen
schwierig, aber
ja, also das ist immer wieder,
wo ich mir denke, das müsste doch eigentlich jetzt einfach sein,
aber irgendwie ist es das nicht.
Ja.
Tja. Oh, oder hast du
mal so von Indie
aufgehört? Also ich meine, das ist halt so eine
etwas abgespeckte O-Aus-Variante.
Nee, gar nicht.
Okay, ja. Was ist das?
Das ist sozusagen,
dass man halt
selber,
also
naja, also das ist auch von dem
von den gleichen, also das hat,
oh Gott, jetzt muss ich wiederkommen, ich vom Hölzchen aufs
Stöckchen, das hat was mit dem Indie-Web zu tun,
das ist so eine Bewegung, um, dass man halt
die Dinge selber machen kann, die,
wo man normalerweise immer irgendwelche Unternehmen
braucht, die das halt machen.
Und es geht zum Beispiel darum, dass man
sich mit seiner eigenen Webseite einloggen können will.
Also nicht Username, Passwort,
sondern man gibt halt ein URL an
und dann gibt es halt sozusagen
einen Hook, wo dann irgendwie man
sagen kann, wie man
jetzt, wie man sagt,
dass man jetzt authentifiziert ist und dann zum Beispiel kann man
sich dann halt irgendwie
eine Push-Notification schicken lassen
aufs Handy. Und dann sagt man
halt, ja, okay, das war jetzt richtig. Oder man
kriegst du einfach eine E-Mail geschickt oder so und drückst dann auf
einen Link und dann...
Genau, genau, genau. Solche Sachen.
Und man ist ja sehr frei in der Art, wie man das halt
dann, wie man diese Authentifizierung
gestalten kann und das klingt eigentlich
schon sehr nett, aber...
Das ist ja sicherlich immer die
einfachste Lösung, wenn du sagst, ich möchte selber keinen
Benutzernamen, kein Passwort speichern,
weil einerseits sind mir die Daten zu sensitiv und ich muss
genau gucken, wie ich das richtig speichere,
ist zu sagen, okay, ich mache einfach, ich speichere überhaupt keine
Benutzernamen, Passwörter und ich verwende irgendein Single-Sign-On-System.
Du hast ja schon OROS angesprochen oder OpenID Connect ist ja der alternative Standard,
dass man sagt, okay, jemand anders müsste sich darum kümmern.
Und dann habe ich zwar diesen anderen Dienst, der irgendwo vielleicht auch in meinem Netzwerk ist
oder vielleicht sage ich, okay, ich erlaube Login mit Facebook, mit Google, mit Twitter und so weiter, mit GitHub.
Dann müssen die sich ja darum kümmern und dann bin ich da raus aus der Sache.
Ich muss kein Passwort speichern.
Und für den Benutzer ist das ja eigentlich auch nicht schlecht, weil der Benutzer muss kein Passwort wählen.
Weil wenn der Benutzer ein Passwort wählt, das ist ja auch...
Nicht so gut.
Aber das hat auch ein paar Falschstücke wieder.
Also zum Beispiel, wir hatten jetzt das System,
dass wir auch so ein OpenID-Connect-Schnittstelle bauen mussten,
aber wir haben das dann über Django All aus versucht zu implementieren,
der ja viele davon schon bereitstellt, irgendwie als Pakete.
Und dann mussten wir aber so einen eigenen Provider dafür bauen,
weil der, den wir da hatten,
der hat nicht genau das gemacht, was wir wollen.
Und ich bin mir nicht sicher,
ob das, was wir da gebaut haben, alles so gut richtig funktioniert.
Das wird sich dann irgendwie im Laufe der Zeit zeigen.
Das müssen wir richtig testen. Mal gucken, ne?
Beim ersten Pentest, hoffentlich.
Ja, ja, ja. Oder beim ersten
Pentest, der ungefragt ist.
Ja, aber
was ich vor allen Dingen blöd
finde bei diesen ganzen OpenIDO
aus Geschichten auch, ist halt, dass man
dann halt alles an so bestimmte
User-Accounts hängt.
Weiß ich nicht, ob das jetzt GitHub, Twitter oder
schlimmer noch vielleicht Facebook ist oder so.
Dann passiert irgendwas Blödes und dann verliert man halt den
Account und dann verliert man gleichzeitig den Zugang zu ganz
vielen anderen Sachen. Das ist ja auch
irgendwie nicht so schön.
Ja gut, aber dadurch braucht
der Benutzer halt nur noch ein Kennwort und
Facebook kann halt sehr, sehr viel bessere Sachen,
bessere Authentifizierung durchführen, als du es machen
könntest. Also die schauen halt auf deine IP-Adresse,
auf deinen Browser, die haben noch ein
Session-Token, die haben vielleicht auch eine
Mehrfach-Authentifizierung,
dass du noch irgendwie auf dem Handy
was bestätigen musst und
da gibt es dann eine Partei,
das musst du nicht alles selber implementieren.
Wenn du es selber implementierst, hast du...
Ja, also es gibt wirklich dann einige
Firmen, die das dann wohl doch
ernster nehmen, als man manchmal so denkt. Ich war zum Beispiel
in Mainz irgendwo in den Ausland geflogen, als man das noch
durfte irgendwie und habe eine
relativ hohe Überweisung angefordert
oder durchgeführt. Und auf einmal bekam
ich dann so einen Anrufer von einem Telefon von der Bank, die meinte so
ja, hallo,
wollen Sie das wirklich tun?
Oder waren Sie das?
Ja, das war ich. Ja, dann ist ja alles gut.
Ja, aber das war schon mal nett, dass sie nochmal
nachgefragt haben, anstatt dass sie einfach eine hohe Summe
irgendwo hin überweisen oder von irgendwo.
Das war schon, kann ich so
unrichtig, dass dann vielleicht
ein Mensch da nochmal nachguckt, also dass dann solche
Alerts irgendwie in das System rausgehen, die dann nochmal gucken,
wenn irgendwas ist. Genau, das
kann deine Anwendung ja nicht leisten, das möchtest du ja
normalerweise nicht machen. Du möchtest natürlich anfangen,
SMS zu verschicken oder was auch immer
oder solche Überprüfungen
zu machen und ich glaube, das ist einfacher, wenn man sowas
zentralisiert und wenn du
ein Passwort, also
viele Leute verwenden halt einen Passwortmanager, aber auch
die, glaube ich, die große Masse an Leuten
verwendet immer noch in 2020 keinen Passwortmanager,
sondern haben ein Standardpasswort, was sie dabei
verwenden. Und wenn dann halt irgendein Katzenforum
gehackt wird, dann bist du plötzlich dran und dann
rufen deine Kunden an, warum wurde hier meine Bankseite
oder was auch immer, welche Seite du anbietest,
warum wurde die gehackt? Und dann sagst du,
ja, du hast das gleiche Passwort in deinem Katzenforum
verwendet. Und die haben halt, wir haben
die besten Sicherheitsstände, aber das Katzenforum, das ist
halt nur irgendeine Kiste, die irgendwo
läuft. Und die ist halt eh,
da reichen sich die Hacker,
die wird in der Türklinke,
drücken sich die Hand, weil da halt so viele Hacker drauf
sind, dass die sich gegenseitig schon stören
mit ihren ganzen Exploits auf dem Katzenforum
und das ist halt ein Problem, was
du mit dem Sing-It-Sign-On direkt an andere
Leute verschiebst. Dann muss sich Facebook oder
Google oder wer auch immer oder dein eigener
Sing-It-Sign-On-Service muss sich dann
darum kümmern.
Ja.
Ja, ja. Ja, wir haben uns ein paar Sachen, glaube ich, vergessen.
Also was wäre mit Security jetzt so ganz groß?
Müsste man ja eigentlich noch über Social Engineering
reden und ganz andere Geschichten.
Also ein paar USB-Sticks auf den Parkplatz fallen lassen
oder sowas und ob man
Corporate sicher bekommt und wie das halt ist
so mit, wie man die Leute auditen
kann und da gibt es ja so Experimente zu.
Also zum Beispiel
einige Konzerne verschicken ja dann
so Test-E-Mails oder Trainings-E-Mails
regelmäßig, um zu gucken,
klicken die Leute auf alles,
was da so ins Mailfach
flattert und die Antwort ist schon, ja,
das tun sie. Und dann kann man die halt
ein bisschen erziehen oder sowas, sodass man die
Quote davon reduziert und das ist eine ganz spannende.
Ja, aber
da würde ich jetzt auch so ganz spontan
würde ich sagen, naja gut, aber ich meine, dafür sind
doch die Sachen dafür da, dass man da drauf klickt.
Also ich meine, das ist ja,
das kann es ja eigentlich nicht sein, dass man
irgendwie die Leute dazu erzieht,
irgendwie sich an komische Regeln zu halten,
damit die Software bleiben darf.
Das ist ja irgendwie... Ja gut, da gibt es ja ein ganz
wichtiges Sicherheitskonzept, was wir noch gar nicht so richtig...
Doch, wir haben es Schweizer Käse genannt
oder Defense in Depth, dass ich sage, okay,
ich sorge dafür, dass auch wenn
also dem Chef der Firma, der
schon 60 ist und der
noch ein bisschen mit der Schreibmaschine arbeitet
und der auf alles klickt, was bunt
blinkt, dem gebe ich vielleicht keinen
Ruhezugriff, auch wenn der sagt, ich bin der Chef, ich möchte
auf die ganze Firma überall Zugriff haben.
Da sage ich, okay, du kriegst deinen eigenen Rechner
und von deinem Rechner darfst du nirgendwo rein
und darfst vielleicht noch...
Dazu beruht dann der Admin, der bei dir vor der Tür steht und
das dann mit dir gemeiner macht.
Ja.
Ja, aber du kannst halt dafür sorgen,
dass du halt Netze separierst oder
im Zeiten des Homeoffice, dass du halt Systeme separierst
und sagst, okay, jedes System muss
eigentlich
davon ausgehen, dass alle anderen Systeme gehackt sind,
also auch im internen Netzwerk, also ich
muss davon ausgehen, ich kann keinem
nur aufgrund der IP-Adresse vertrauen, nur weil
er mit mir kommunizieren kann, sondern das System
muss halt ordentliche Single-Sign-On-Tokens überprüfen
oder was auch sehr beliebt ist
für Service-to-Service-Kommunikation, sind
halt Client-Side-TLS-Zertifikate,
dass ich sage, ich verwende das TLS
nicht, wie man es normalerweise verwendet, dass ich
einen Server habe, sondern ich habe auch einen Client,
du hast ja eben schon den YubiKey angesprochen, den man genauso
einsetzen kann, wenn da ein Mensch ist,
aber auch zwischen Systemen ist das glaube ich so der
goldenen Stand, dass man sagt, okay, ich habe
einen Client-Site TLS-Zertifikat, ich habe einen Server-Site
TLS-Zertifikat. Vielleicht nochmal ganz kurz da,
einmal kurz das Low-Level, also TLS ist irgendwie
Transport-Layers, sehr cute.
Genau, auch bekannt als SSL. SSL ist der
Vorgang. Und das macht sowas sicher, wie
eine Verbindung zu einem anderen Rechner, dass die irgendwie
verschlüsselt übertragen, dass man sich nicht in die Mitte setzen kann,
um das abzuhören irgendwie. Ja, nicht eine Verbindung zu
einem anderen Rechner, sondern, also
auch, aber
von einer Anwendung zu einer anderen Anwendung.
Also auch auf dem lokalen Rechner. Ja, okay.
Ja, genau.
Ja, okay. Ja, das sind halt irgendwie so
genestete Sicherheitslevel, die irgendwie so
ineinander stecken und das ist dann, wo ist dann irgendwann alles
relativ komplex dann mit den ganzen...
Ja, ja, du brauchst halt allein, also
für sowas wie eben so eine stinknormale,
ich weiß nicht, so eine Anwendung, wie du besuchst,
bist auf deiner Bankseite und
machst da irgendeine Transaktion, müssen halt viele
Dinge gewährleistet sein.
Also der TLS-Teil macht halt die
Vertraulichkeit,
beziehungsweise Integrität, ich weiß jetzt gar nicht genau,
aber was du halt auch noch...
Beides, genau.
Was du halt auch noch brauchst, ist halt
Authentifizierung, also du musst dich halt irgendwie
gegenüber der Bank ausweisen, damit
die Bank weiß,
wer du bist und überprüfen kann
und das ist dann der dritte Teil, ob du auch autorisiert
bist, das zu tun, was du da tun willst, das ist halt
nochmal getrennt davon, weil es kann ja sein,
du hast dich zwar eingeloggt, aber du darfst irgendetwas
nicht machen und Autorisierung
ist ja auch nochmal so ein Riesenthema,
wie kriegt man das eigentlich ordentlich
hin und
Der coole Trick bei TLS ist halt,
dass du sagen kannst, also
Also du kannst erstmal sowieso asymmetrisch arbeiten, das heißt der private Schlüssel verlässt nie die Box.
Du hast also einen Client, also einen Service, der einen anderen Dienst was sendet
und der hat einen privaten Schlüssel und der andere Dienst kennt nur den öffentlichen Schlüssel.
Und das kannst du noch weiter treiben, indem du halt sagst,
der andere Dienst muss noch nicht mal den öffentlichen Schlüssel kennen,
sondern es gibt noch eine dritte Partei, die das irgendwie signiert.
Und das verwendest du ja, wenn du auf eine normale Webseite gehst,
normale HTTPS-Seite, dann ist die halt
oben grün, weil halt
dieses Zertifikat von jemandem signiert wurde
und das kannst du
aber auch kleinseitig verwenden, dass du sagst, okay,
der, ich zertifiziere
nicht nur, dass derjenige, der die Anfrage
entgegennimmt, richtig ist, sondern auch der, der
die Anfrage sendet. Das ist ja tatsächlich wieder
interessant, weil das nämlich das nächste Thema ist, was irgendwie eigentlich
zu Security natürlich dazugehört und das wäre
Kryptografie oder Verschlüsselung, ohne dass man ja
wahrscheinlich nicht auskommt und da gab es ja irgendwie
Algorithmen, mit denen man bestimmte Dinge
verschlüsselt oder
hasht oder wie auch immer und die man dann
mehr oder weniger schnell
entschlüsseln konnte oder sowas. Oder man konnte sogar
so Angriffe fahren wie, ich glaube Rainbow Table
nennt sich das oder sowas, dass man halt Passwort-Hashes
einfach in eine Tabelle schmeißt und guckt, wie ist denn
das Ergebnis von dem Hash, also was ist denn da der umgekehrte
Wert von oder so. Und ja, wenn man
solche Sachen halt irgendwie
vermeiden möchte, dann müsste man glaube ich
schon gucken, welchen Algorithmus man zum Schlüsseln,
Entschlüsseln seiner Schlüssel nimmt.
Achtung, das ist zwei verschiedene Sachen.
Verschlüsseln und, also mein Passwort möchte ich
eigentlich nicht verschlüsseln, weil dann
muss ich ja den Schlüssel irgendwo auf dem Server speichern.
Ja. Also das Passwort
eines Nutzers möchte ich nicht.
Also SSH-Keys oder sowas, das mache ich mit Schlüssel.
Die dann
bestimmten Algorithmus benutzen irgendwie.
Okay, ja.
Das man halt da, also das müsst ihr vielleicht
nochmal erklären, also wie man halt da von einem
einen, ich sag mal,
nicht so guten Algorithmus den Schlüssel
berechnen kann aus einem Public Key oder sowas, ja, bei
asymmetrischer Verschlüsselung.
den Schlüssel selber musst du eigentlich nicht berechnen.
Du kannst ein Zertifikat berechnen,
das ist der Schlüssel nochmal in Kurs, aber du
könntest eigentlich auch immer den Schlüssel an sich verwenden,
den öffentlichen Schlüssel zumindest.
Nur weil der öffentliche Schlüssel ist halt bei dieser
Kryptografie sehr lang, das muss halt eine sehr lange Zahl sein
und die kannst du halt eindampfen auf
eine kürzere Zahl, die man aus verschiedenen Gründen
dann verwendet, die auch immer gleich ist, egal wie lang
der Schlüssel ist und das ist das Hash-Verfahren.
Das verwenden wir auch bei Passwörtern und auch an
vielen anderen Stellen, kann ich auch verwenden, um
zum Beispiel zu überprüfen, wenn ich Software runterlade,
dass die in Ordnung ist. Haben wir eben schon mal
angesprochen, dass wenn ich
das mit Python mache,
dann habe ich zum Beispiel bei pip-env
oder bei pip habe ich ein pip-file
oder ein pip-file.log und in dem pip-file.log
stehen halt die ganzen Hashes drin.
Und was ein Hash macht, ist halt genau eine lange
Eingabe zu nehmen, egal welche Länge
und sie auf eine Zahl zu reduzieren,
die eine
relativ kurze Länge hat und die auch immer die gleiche
Länge hat. Das sind dann halt nachher so 32
Buchstaben oder sowas.
Und das
ist halt kryptografische
Magie und
es gibt halt Mathematiker,
also
haben sich darum gekümmert, dass es nicht
möglich ist, das rückwärts zu rechnen. Das heißt, wenn ich
ein Hash habe, kann ich nicht
das Original berechnen und ich kann
gegeben einen Hash, kann ich nicht
überhaupt ein Original
finden. Das heißt, wenn du mir dein Hash gibst,
dann kann ich eigentlich sicher sein, dass
die Originaldatei genau
unverändert ist. Und genau dafür
kann ich die halt einsetzen.
das Rückrechnen ist dann bei unsicheren
Hashverfahren dann vielleicht dann doch möglich
oder sowas oder dauert dann lange
man kann halt Kollisionen finden
und dann kann man eben beispielsweise
Dokumente dadurch fälschen, dass man
wenn man hinten Leerzeichen anfügt
oder wegnimmt, kann man ja beliebig viele Kombinationen erzeugen
wenn man weiß, wie man die Kollisionen erzeugen kann
dann kann man halt quasi beliebige Texte
mit einem bestimmten Hash erzeugen und das ist natürlich ganz schlecht
Genau, dann habe ich halt deinen Schlüssel
und dann kann halt jemand anders einen anderen Schlüssel
generieren und die haben plötzlich den gleichen
Hash. Dann kann er sich mit
seinem eigenen Schlüssel, der so tut, als wäre dein Schlüssel
damit authentifizieren
Also es geht um Sicherheit von Kryptografie
oder sowas in der Hinsicht noch?
Ja, aber ich glaube, ich weiß gar nicht, ob man
sich als Endanwender oder so
wahnsinnig viel mit beschäftigen muss, weil
ich glaube, wenn man da anfängt
sich für zu interessieren und dann irgendwelche
Entscheidungen zu treffen, dann liegt man
wahrscheinlich eher, ist die Wahrscheinlichkeit hoch,
dass man falsch liegt. Also genau, dann sollte man
quasi diese Wahl auch gar nicht mehr treffen, welche
kryptografischen Algorithmen man zum
Verschlüsseln, Entschlüsseln benutzt.
Doch, also wenn du
zum Beispiel hasht, dann muss dir der
Python-Hashlet, musst du sagen, okay, ich möchte
diesen Hash haben. Dann sagst du zum Beispiel, ich möchte
SHA-1 haben oder ich möchte MD-5
haben. Und wenn du da die falsche Wahl
triffst, dann hast du durchaus ein Problem. Also SHA-1
oder MD-5 sollte man nicht nehmen, sondern SHA-256
oder? Genau, SHA-256
oder eine SHA-3-Variante oder
was anderes. Aber eigentlich willst du gar nicht, dass
der Entwickler sich drum Gedanken machen soll.
Der Entwickler soll gar nicht sagen, okay, ich nehme ShyOne,
sondern der Entwickler soll eigentlich sagen, okay, ich nehme
eine fertige Bibliothek. Und dafür
gibt es dann in Python zum Beispiel die
neue Passwortbibliothek
oder es gibt Bcrypt.
Und
da muss ich mich halt gar nicht drum kümmern.
Ich weiß gar nicht, die Passwortbibliothek heißt, glaube ich, Secret?
Secrets. Secrets, ja, genau.
Und da muss ich halt nicht mehr drum kümmern.
Also da wird halt die Wahl für dich getroffen
und das macht es für den
Entwickler natürlich
besser, weil der Entwickler keine Entscheidung
treffen muss. Wenn du ein System groß
zertifizieren musst, dann musst du wahrscheinlich trotzdem irgendwo eine Entscheidung
treffen, weil da andere Leute drüber schauen wollen,
aber für so die Wald- und Wiesenanwendung,
die einfach mal so von
vielleicht einem kleinen Team entwickelt wird, ist das
sicherlich eine bessere Option, wenn die
keine kryptographischen Entscheidungen treffen. Also
nicht mal die Entscheidung treffen, welche Algorithmen
sie verwenden, sondern vielleicht nur noch sagen,
ich möchte ein bestimmtes Sicherheitslevel
haben. Das ist ja auch immer ein Trade-off,
dass ich sage, okay, ich kann ja zum Beispiel mehrfach
hintereinander hashen und dann kann man
das halt bei dem Passwort
dauert es auch länger, das rauszufinden,
weil ich halt, wenn ich
ein Testpasswort habe,
muss ich das ganz oft hashen, um das Zielpasswort
zu finden. Aber das ist halt auch ein
Problem, was auf deiner
Seite, weil wenn du das jetzt sehr oft
hasht, dann dauert es natürlich bei dir länger.
Und du möchtest ja nicht, dass dein
Service plötzlich eine Minute braucht, wenn es den
Benutzer einloggt, weil dein Passwort irgendwie
eine Million mal hasht oder sowas.
Das ist übrigens auch mal so ein schönes Ding bei
Tests, wo man halt irgendwie Zeit sparen
kann. Und da halte ich meine,
die Passwort-Hash-Funktionen sind ja genau die,
sie sind ja genauso
gestaltet, dass sie möglichst langsam sind.
Und
genau, da will man dann vielleicht auch mal MD5
verwenden oder sowas in der Art,
weil das ist halt dann deutlich schneller.
Und man legt ja, wenn man jetzt einen Testsuite
durchlaufen lässt, oft irgendwie ganz viele Nutzer an
und ja,
das kann Dinge deutlich beschleunigen.
Ja.
Sehr, sehr interessant. Also da fallen mir
ganz viele Sachen, glaube ich, noch zu ein.
Was man da so macht mit
Vulnerabilities und Disclosure und
alle so Themen. Ja, Pics
tatsächlich. Und die Frage, wollen wir
ein Standard-Lib-Modul
vorstellen?
Ich finde, jetzt vielleicht ein Siegwitz vorstellen.
Ja, das wäre super. Kennst du dich mit Siegwitz auch
aus? Nicht im Detail.
Okay.
Schade.
Ich dachte, er hat gedacht, ich kann
die Verantwortung von mir schieben.
Ja, aber wenn du dich damit beschäftigt hast, dann mach das doch.
Was, ich? Nein, nein, nein.
Nein? Nein, nein, nein.
Was wäre denn euer Blick?
Ja, also meiner
wäre jetzt
tatsächlich YouTube.dl.
Wie kommst du
da drauf?
Ja, ich habe damit in letzter Zeit, im letzten Jahr
viel gemacht. Ich habe das so, ich habe es früher
vielleicht ab und zu mal benutzt, um irgendwie mal Videos
runterzuladen, die ich gerne auf der Platte hätte.
Also genau dafür ist es ja da.
Aber im letzten
Jahr habe ich das auch viel
sozusagen in Projekten
verwendet, weil es darum ging,
wie man da Videos irgendwie automatisch verarbeiten
kann und so.
Ja, und
es ist ein sehr, sehr schönes Tool.
Aber ich glaube, Philipp kann das deutlich
besser erklären, was das eigentlich so tut und was so
ein bisschen...
Es gab auch so einen kleinen politischen Vorfall beim YouTube.
Dann müssen wir auch noch natürlich erzählen.
Also der Name von YouTube.de
ist stark irreführend.
Also es hat angefangen
als ein Download-Tool nur für YouTube
und als ich das damals
übernommen habe, da
wurden glaube ich noch Vimeo unterstützt
und noch ein, zwei andere Seiten, aber als ich
das abgegeben habe, also mittlerweile
entwickle ich auch schon länger nicht mehr daran,
oder entwickle schon ein bisschen dran, aber bin halt nicht mehr
der Chef-Maintainer
oder überhaupt ein Maintainer und
mittlerweile unterstützt es über tausend Dienste, das heißt
du kannst es auch auf irgendeine komische Anime-Seite
laufen lassen oder auf die ARD-Audiothek
oder auf
archive.org
oder die CCC-Kongress-Seite
und es wird dir halt immer ein ordentliches
Video zurückliefern, du kannst
natürlich auch sagen, ich möchte verschiedene
Konfigurationen, also möchtest du das Video
sortieren oder möchtest du direkt eine Playlist runterladen
und YouTube-Date ist komplett in Python
geschrieben, das ist vielleicht auch ein bisschen besonders, weil
es eine Python-Anwendung ist,
die gar keine Dependencies hat.
YouTube.dl verlangt nur die Standard-Diplotek
und das auch sehr, sehr, sehr flexibel.
Also bis vor kurzem noch konnten wir zwischen Python 2.6,
ging noch bis Python 3.8, wurde alles unterstützt.
Hat sehr, sehr viele Benutzer.
Und ja, ist halt hoffentlich ein super flexibles Tool,
das man auch sowohl programmatisch
als auch als Kommando-Zeitanwendung verwenden kann,
um schnell was runterzuladen.
Viele grafische oder serverseitige Programme
verwenden auch intern YouTube.dl
um halt Videos runterzuladen
aus verschiedensten Quellen. Typischerweise
also oft YouTube, aber kann auch was ganz anderes
sein. Und der
Vorfall, der halt passiert war, ist
also vor dem öffentlichen Vorfall
bin ich und ein Hoster
angeschrieben worden von einer deutschen Anwaltskanzlei
die Rush heißt die
die sind, wenn man nach denen googelt, dann
also ich hab zuerst natürlich nach denen gegoogelt
als ich das Schreiben bekommen hab, sieht man okay
die schicken normalerweise Abnahmen wegen
Tauschbörsenvorfällen oder sowas.
Irgendwie bekannt für den Namen, ja.
Und die haben halt da typischen, also ich kann das jetzt nicht so beurteilen, ich bin kein Jurist, aber die haben ein sehr langes Papier geschrieben, wo sehr große Drohungen drin standen, was für mich eigentlich jetzt irrelevant ist, weil ich bin ja nicht mehr in ein Projekt involviert.
auch schon, also ich habe noch gelegentlich
Contributions geleistet, aber auch nichts mehr zu
YouTube, sondern nur noch zu ganz anderen
Seiten. Und dann
haben die wohl aber mitbekommen, dass
YouTube.dl auf GitHub gehostet ist.
Und dann an die
amerikanischen, ja, so richtig technisch
drauf waren sie nicht, aber gut, sind auch
recht anwesend, sind keine Programmierer, haben halt
nur so ein bisschen was gefunden und haben auch viele Sachen
nicht richtig verstanden. Also
das ist halt,
ja, kann man ja nicht machen.
Und dann sind sie halt
zu den Amerikanern gegangen
und die RIAA
und die hat dann halt
GitHub eine Notiz geschickt,
eine
DMCA-Notiz,
dass sie halt
die YouTube-DA
sperren sollen. Und davon haben die meisten Leute
erst mitbekommen, dass irgendwas nicht stimmt.
Also diese Vorgeschichte, das war schon Wochen davor in Deutschland
und auch andere Sachen waren
Wochen davor, aber was die Öffentlichkeit mitbekommen hat,
war okay, GitHub ist gesperrt.
Und GitHub ist freundlicherweise
für das YouTube-2L-Projekt, das hostet die Downloads.
Das YouTube-2L
muss relativ häufig aktualisiert werden.
Also wird so alle 2-3 Tage
aktualisiert. Klar, bei irgendeiner Webseite ändert
immer was oder irgendjemand fügt etwas hinzu.
Und es ist halt auch ein sehr, sehr aktives Open-Source-Projekt.
Also da laufen pro Tag
10 PRs rein.
dadurch
stehen halt große, hohe Download-Zahlen und dann ging halt
erstmal gar nichts, weil GitHub das nicht gemacht hat.
Das Projekt ist direkt umgeschwenkt und ich hatte
schon befürchtet, dass es daran endet,
dass das Projekt nur noch YouTube-Musik runterladen kann.
Also der Stein des Anstoßes waren nicht die normalen YouTube-Downloads,
sondern die YouTube-Musik-Videos.
Das war das Problem, was die Rechtsanwälte bemängelt hatten.
Und was jetzt aber passiert ist,
dass glücklicherweise die EFF, die Electronic Frontier Foundation,
in den USA die Verteidigung übernommen hat von YouTube.dl
und da eine Gegennotiz geschickt hat.
Und jetzt auf GitHub wieder alles da ist und GitHub das wieder hostet.
Und das Projekt wahrscheinlich jetzt ganz normal weiterläuft und alles wieder klappt.
Ich war da auch gar nicht so viel involviert.
Ich bin halt nur von zig Leuten angeschrieben worden, habe einige Interviews gegeben.
Und ich bin halt natürlich rechtlich, habe ich mit einem Rechtsanwalt gesprochen.
Damals hatte ich da nicht den richtigen Überblick.
Habe dann auch eine Unterlassungserklärung abgegeben, dass ich nicht mehr daran teilnehme an YouTube.de.
Sehr traurig.
Aber das Projekt sieht jetzt gut aus
und scheint überhaupt kein Problem zu sein.
Und ich bin sehr froh, dass die EFS sich darum gekümmert hat.
Und auch über die Unterstützung von GitHub.
Und zuletzt sollte man vielleicht auch erwähnen,
es gibt einen deutschen Hoster, der daran beteiligt ist.
Das ist Uberspace.
Da kann man super leicht seinen eigenen Dienst hosten.
Und die sind auch rechtlich angeschrieben worden,
auch von den Rechtsanwälten rasch.
Und die haben sich auf eigene Kosten,
die ihre eigene Verteidigung organisiert.
Die hosten halt nur die Webseite.
die hostet nicht das Programm selber,
aber auch das fand die Rechtsanwälte verwerflich.
Glücklicherweise ist jetzt, glaube ich, alles gut
und ich glaube, YouTube.de wird es genutzt.
Ich glaube, völlig unbestritten,
dass es absolut legitim ist.
Es haben sich nach der Sperrung
auch sehr, sehr viele Museen
oder Archivare oder Bibliotheken gemeldet,
die gesagt haben, okay, wir verwenden das
und wir haben sogar rechtlich das Anrecht darauf,
selbst Musikvideos runterzuladen,
weil das genau steht
und irgendwie muss es halt passieren
und YouTube-DL ist genau das Werkzeug, um sowas zu machen.
Und ich glaube, der Nutzen von YouTube-DL überwiegt bei Weitem
das jegliche Probleme, dass man da ein Musikvideo
in meiner Weise relativ schlechter Qualität von YouTube runterladen kann,
was man ja auf Spotify oder überall bei Amazon oder bei Apple
als MP3-Datei oder als Flak-Datei in deutlich besserer Qualität kaufen kann.
Ich glaube, das ist viel besser für die Gesellschaft,
dass YouTube.dl für alle verfügbar ist.
Aber als deutscher spitzfindiger Winkeladvokat,
da kann man sich ja noch mal überlegen,
ob man nicht noch einen kleinen Pfeilstrick herbeizaubern kann.
Ja.
Aber ja, ich glaube auch eher,
das hat dem Projekt wahrscheinlich doch eher stark genützt.
Das hat jetzt noch mal sehr viel Aufmerksamkeit bekommen
und hat der Streisand-Effekt voll zugeschlagen.
Ja, auf jeden Fall.
Also ich bin tatsächlich froh, dass es mittlerweile so weit ist,
dass solche Sachen nicht mehr einfach so dann weggeblockt werden,
sondern dass die Leute sich anfangen,
mit solchen Dingen auch juristisch dann auszukennen
und dass diese komischen Kanzleien
oder wie man ja auch immer das dann nennen soll,
langsam aber sicher gegen die Wände rennen.
Ja, ist halt schwierig als Open-Source-Programmierer.
Ich bin halt nur eine Person.
Ich habe keine große juristische Know-how.
Also ich kann das halt technisch beurteilen,
was im Gesetz steht.
Aber offensichtlich gibt es auch einige Gerichte,
die das sehr flexibel ausgelegt haben,
was da im Gesetz steht.
Also das Landgericht Hamburg hat gesagt, okay, im Wesentlichen, da steht, dass es technisch eine technisch durchsetzbare Verschlüsselung oder Verschleierung geben muss und das haben sie einfach interpretiert als, ja, das hört sich aber komisch an, das interpretieren wir jetzt anders und jetzt haben sie es gesagt in dem Urteil, eigentlich alles, was ein normaler Benutzer nicht machen kann, ist verboten.
Das heißt, es gab ein vergleichbares Urteil und da hat ja jemand argumentiert, okay, das kann man aber auch in den Browser-Tools machen und dann hat das Landgericht Hamburg gesagt, nee, das kann aber ein normaler Benutzer nicht, weil das ist nicht im Internet Explorer drin oder so. Und das ist halt eine sehr fragwürdige Argumentation.
Ja, da hat der Jurist das dann selber ausprobiert
und dann festgestellt, nee, er kann das nicht.
Ja, genau, genau, exakt.
Und YouTube-DLS funktioniert eigentlich
wie ein normaler Browser.
Nicht grundsätzlich unterschiedlich wie Chrome.
Es hat auch eine eigene JavaScript-Engine in Python geschrieben.
Ach, äh,
ah, okay, das und tatsächlich
die ist selber, aha, naja, stimmt,
wenn es keine externen Abhängigkeiten gibt.
Oh, das wusste ich nicht, das hätte ich jetzt auch gedacht,
dass das vielleicht irgendein Headless-Browser-Engine
noch mit dabei ist oder so, nee, komplett, wow.
Also gar keine Python-Abhängigkeiten.
Klar, wenn ich jetzt normale Python-Anwendungen schreibe,
dann verwende ich Abhängigkeiten.
Wir haben ja eben gerade besprochen,
dass es eigentlich gut ist, wenn ich fertige Bibliotheken verwende.
Aber YouTube.jl muss halt auf ganz unterschiedlichen Systemen laufen.
Da gibt es halt Leute, die kommen an mit Red Hat
und haben halt Python 2.6 oder bis vor kurzem noch Python,
oder vor allem jetzt halt noch Python 2.5 haben die noch drauf
oder Python 2.4, keine Ahnung.
Und da kannst du halt nicht darauf vertrauen,
dass die auch überhaupt irgendwas installieren können.
Die sind halt froh, wenn die ein Binary bekommen.
Und das geht ja in Python relativ gut, man kann die Datei ja einfach als ZIP verpacken und dann ist es ausführbar und man kann das auch mit, ich glaube, mittlerweile verwendet YouTube.jl CX Freeze, um halt auch eine Excel für Windows zu erzeugen und das läuft dann wirklich überall, ohne dass man es installieren muss.
Und ich glaube, das ist auch ein Grund für den Erfolg dieser Software, dass man das halt einfach so laufen lassen kann, dass man sich keine Gedanken machen muss, auch wenn das System komplett zerschlossen ist als Python-Entwickler, das klappt immer. YouTube.jl, klar, braucht ungesunde Politik.
Sehr gut, sehr gut
Ja, das klingt sehr spannend
Ja, ja
Mir war das auch gar nicht so klar, dass man da tatsächlich
irgendwie die meisten Seiten mit
bedienen kann und dann
ja, ich hatte
früher auch immer gedacht, das wäre eigentlich für YouTube
aber ja, es ist wirklich
sehr, sehr praktisch, es nimmt einem auch viel ab
Ich benutze das jetzt halt immer so
quasi
um halt automatisiert von allen
möglichen Seiten Dinge runterzuladen und das
halt sozusagen die Schnittstelle, die
YouTube-DL ist sozusagen meine API zu
Seiten, die Videos haben,
um das Video da rauszukriegen.
Genau, ohne...
Ja, Pics.
Also ich würde dieses Mal gleich Python Date
Util picken, weil irgendwie das ein schöner
Rapper ist, über wie man
Datumsangaben irgendwie machen kann.
Verschiedene Zeitkalendern mit Deltas
irgendwie. Ich wollte es nur mal erwähnt haben,
das stand irgendwo noch auf meiner Liste, hat jetzt nicht den Topic
gar nichts mehr so viel zu tun.
Ja, Datutals
ist tatsächlich auch sehr nett.
Das Datutal-Pass,
das passt erstaunlich viel.
Also dem kann man irgendwelche Strings geben,
also man hat ja oft irgendwie, sieht man dann irgendwo
so einen String mit Datums
und Zeitangaben drin und dann denkt man sich,
oh, wie waren
jetzt nochmal die Format-String-Dinger,
wie hießen die nochmal alle?
Und dann nimmt man Datutal-Pass
und dann passt das automatisch,
aber dann muss man irgendwie noch, ich glaube, das geht
aber auch irgendwie, man kriegt auch aus dem
Datutel-Pass dann raus, wie der Format-String
eigentlich sein müsste.
Und andere Kalender.
Weil Datutel-Pass sollte man nicht
über größere Datenmengen
aufrufen, weil das wird dann halt sehr langsam,
wenn man das Inhaltschleife verwendet, aber
um rauszukriegen, wie man das denn jetzt eigentlich
aufpasst und dann halt an den Format-String zu kommen,
den man dann letztlich verwendet
für Striptime oder so,
das ist super.
Und dein Pick-Up?
Hatte ich doch schon.
scheuen? Ja, YouTube.dl. Ach, verdammt.
Ja, richtig. Ich dachte jetzt, das ist der Philips-Pick gewesen.
Na gut. Du bist da
ausnahmsweise wegen dem YouTube.dl
da rumgekommen. Es sei denn, du hast noch einen.
Extra.
Ne, das habe ich jetzt nicht vorbereitet.
Ich habe mich bei dem Secrets
sehe ich gerade völlig vertauscht.
Das ist gar nicht die Bibliothek, die eine
die eine fertige Algorithmus nimmt,
sondern die generiert dir erstmal nur den Zufall
darunter und generiert
erstmal nur zufällige Werte.
Die richtige Bibliothek, um halt Passwörter zu herstellen, wäre
sowas wie B-Crypt.
Da haben wir das auch noch reingekriegt.
Ja, schön,
dass ihr alle dabei seid. Danke, Philipp, dass du Zeit gefunden hast
für uns. Ja, voll gut.
Eine sehr interessante Episode.
Ja, auch für mich sehr interessant.
Ja, vielen Dank,
dass ich dabei sein durfte.
Wenn ich noch einmal ganz kurz Werbung
machen darf, bei Coxine suchen wir immer
Python-Entwickler.
Aktuell suchen wir auf jeden Fall
Python-Entwickler oder auch Leute, die mit
Java oder mit JavaScript arbeiten,
speziell mit React.
Also wenn ihr ein guter Entwickler seid,
vielleicht sogar im Raum Düsseldorf oder
auch nur ganz grob in NRW irgendwo,
dann meldet euch bei Baboxine.
Die Tonybox zu programmieren
macht wirklich, die Dienste
rund um die Tonybox zu programmieren, macht sehr
viel Spaß. Es ist total toll zu wissen,
okay, jede Nacht
gehen
Tausende oder Millionen Kinder
mittlerweile mit der Tonybox ins Schlaf und
wir machen gute Dienste, die
die hoffentlich den Eltern
das Leben einfach machen und
dafür sorgen, dass die Kinder gute Geschichten hören.
Das war die erste Werbeanzeige
im Preißen-Podcast.
Ja, aber ich kann nicht nur...
Könnt ihr rausschneiden, falls...
Nein, nein, nein, das finde ich super.
Das ist ein schönes Projekt
hier aus der Gegend.
Ja, alles klar,
dann würde ich sagen... Ja, vielen Dank, Philipp.
Und bleibt uns gewogen.
Egal, wann ihr uns hört, schaltet wieder ein.
Morgens, mittags, abends, tags, nachts.
einschlafen, das ist auch immer super.
Ja, liebe Grüße und bis zum nächsten Mal.
Jo. Ja, tschüss.