Transcript: Security

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.

Da 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 es 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.

im Podcast.

Das habt ihr mich wahrscheinlich schon

einmal dabei gehabt.

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.

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

Internet Security, glaube ich.

Oder wie haben sie sie genannt? Also Internet Security,

einfach Security.

die Security-Vorlesung gehalten.

Netzwerk haben wir sie genannt.

Also Netzwerksicherheit sieht 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 Tonybox. Also wenn man keine Kinder hat,

dann kennt man die Tonybox.

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. Interessant.

Ja, ja, ich habe mich letztes Wochenende genau mit Jens,

deswegen kannst du dann wahrscheinlich auch lange unterhalten.

Genau, der Jens ist auch in meinem Team. Jens ist auch

einer von den Python-Entwicklern

bei Boxine.

Ja, die

Tonybox ist super beliebt.

Ja, dass es ein Python-Projekt geworden ist.

Ihr kennt ja bestimmt, das sind diese kleinen Spielzeug-

Figuren, 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. Sie immer, ich habe

keine Ahnung, stell du mir Fragen. Und

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 dann so ein Rechner

mit grüner Schrift und dunklem Monitor

oder wie sieht das aus?

Das trifft es wahrscheinlich schon ziemlich

gut.

Du möchtest Leute

schützen davor,

oder du möchtest

Systeme schützen vor irgendwelchen

Angreifern. Das ist das grundsätzliche Prinzip

für Sicherheit. Du hast dann verschiedene Ziele.

Ganz traditionell hat man die Integrität,

dass ich sagen möchte, niemand möchte etwas ändern.

Ich habe die Vertraulichkeit, dass ich sagen möchte,

niemand soll rausfinden 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. 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 denn in Python?

Ja, 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-Overflows

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

und 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

Benutzereingabe, Speicher, also Buffer, Overflow

vielleicht nochmal ganz kurz, 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

Mensch mit dem Kapuzzer-Kolore

Naja, also ganz ganz kurz

irgendwie, ja, ist auch eine relativ spezielle Art von Sicherheitsproblem, aber das gab

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, das sind Strings

Nullpointer terminiert und, naja,

wenn man... Ach so! Genau, also da steht nicht

anzuzwingen 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 er

gar nicht, liest er es immer noch weiter. Genau, wenn man

zum Beispiel einen festen Buffer definiert hat

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

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.

Das war

lange Zeit,

viel Server-Software hatte

diese Fehler und man konnte das halt ausnutzen.

Obwohl, ich meine, heute spielt

ist vielleicht auch immer noch eine Rolle, vielleicht eher so bei Clients, ich glaube Server,

obwohl es gibt es vielleicht immer noch, ich weiß es nicht mehr so genau,

ich habe auch lange nicht mehr drauf geguckt,

aber 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 hat 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

und die Programme, die man nicht will,

lässt sich halt stark darauf zurückführen,

dass wir halt eine sogenannte

von-Neumann-Architektur haben.

Das geht halt zurück auf die,

was weiß ich jetzt, gar nicht mehr.

Mir wurde mal vorher erworfen,

Opa redet vom Krieg,

aber da war ich nicht dabei.

60er, 70er, irgendwo da, noch älter,

40er, von-Neumann-Architektur, noch älter.

Das war vor dem Zweiten Weltkrieg wahrscheinlich sogar.

und 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 mit der Datenspeicher einzeln.

Es gab früher Rechnerarchitekturen, 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 die 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 da dran, 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.

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.

Moderne CPUs haben einen Marker, wo

drin steht, okay, diese Speicherseite

ist ausfüllbar oder nicht.

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 halt 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.

Ich wollte eigentlich zu dieser Frage

mit den, was machen denn die CPUs dann da falsch?

Kannst du 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 ist,

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 dazugeschickt werden,

in den einzelnen, was sind das,

Stacks? Nein, Registern.

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,

und der Angeber gibt eine längere Datenfolge an.

Und wie wir eben schon erwähnt haben, da könnten dann zum Beispiel verschiedene Instruktionen wie

Nobcodes drin vorkommen. Und das sieht aus wie

normaler Text, aber das ist halt genauso

designt, dass man das auch als Obcodes für die CPU interpretieren kann.

Und genau das ist das Problem danach, 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. Eine 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

und sagt, 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,

das SQL-Statement, was ich an den Server drücke, ist ja aus Serverperspektive erst mal Daten,

die als Programm zu interpretieren sind.

Und wenn darin halt Mist stattfindet, dann geht da alles quer durcheinander.

Und das ist in 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 hab mit sowas halt selber

auch, also ich sag immer,

ich fass C nur dann an, wenn die anderen es verrissen haben.

Ich schreib nie C-Code

neu. Ich hab 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 mir ganz mache.

Der Pleiko-PG

ist zum Beispiel halt im Datenbankumfeld,

da merkt man so,

und das ist ein bisschen

und die Programmiersprache Python.

haben ein Minuszeichen drin. ISO 8501 und so 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, na jetzt kommt hier ein Encoding-Name,

also streiche ich das Minus raus, also ziehe 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 6-Byte langen Buffer statt in einen 7-Byte langen Buffer.

Und weil sie aber nicht einfach nur malloc benutzt haben,

weil ganz kleine Objekte zu alloziieren 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, das System kann ja auch ein Megabyte oder größer sein,

aber gehen wir mal von einem K aus oder 4K,

und dann packt Python halt solche 6-Byte-Objekte alle zusammen in eine Page

und 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, mit ein paar 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 Byte 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 einen Zagfault

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 auch dann sein, dass das nachher auf dem 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.

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...

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,

damit machen wir jetzt einen schönen nächsten Bogen,

dass Security extrem kontextspezifisch ist.

Sie stellen 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 Fun 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...

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

Context einführt, hat

die Verantwortung sicherzustellen, dass er

da was Sinnvolles tut.

Dann macht er ein

Projekt mit NPM-Paketen.

Genau, 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 etwas zusammengeschimmertes

kleines Raumschiff, was immer droht auseinanderzufallen, was auf der einen Seite mit Kohle und auf der anderen

Seite mit einem Handpedal betrieben wird

und kann also 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.

Ich weiß nicht, weil

zu viele Leute

gehen nämlich ohne diese

Vorsicht heran.

Also, man hat mal früher gesagt,

die Deutschen bauen die besten Atomkraftwerke,

weil die so scheiß viel Angst davor haben.

Und halt entsprechend in die

Sicherheit investieren.

Deswegen ist Siemens mit den

Atomkraftwerken 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,

und wer sich unsicher fühlt und einen Helm aufsetzt, ist am Ende bei einer echten Kollision feiner raus.

Ja, aber ich meine, das ist einfach so.

Ich glaube, das, was mich da so unsicher fühlen lässt, ist halt einfach, es ist schwer zu hinzu...

Also 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.

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 Kampfhufschrauber 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 hätte hier gern 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,

ihr kennt jetzt hier gerne mal schnell eine

HTTP-Library und ich würde dir

SSL nochmal da drüben, Repository

von GitHub, sowas ist bei aller

halt eher nicht so an der Tagesordnung.

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.

Ja, das, 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.

Und 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, 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

der von irgendeiner neuen Ariane-Version

war, Ariane 5, äh Ariadne

Ariadne oder Ariane, Ariane glaube ich

5

Ich glaube auch die Steuerungssoftware dafür ist

auch in Ada 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

die Spezifikation war halt für die alten Motoren

irgendwie und dann hat

irgendwie 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

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.

machen.

und der Code sieht komisch aus.

Und dann kann ich ja 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

Hacker-Tool und das probiert einfach mal aus.

Kann ich hier komische Sachen eingeben und

und crashen 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ürzt 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 viel 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

Abschluss oder zu komischem Verhalten Und damit kann ich auch in Python glaube ich sehr gut Sicherheit sichern Also du wirst tats in solchen kritischen F wo du dir

ich weiß nicht so genau, was da rauskommt, Assertment-Statements

in den Code schreiben einfach und dann

sagen Asserts should never happen oder sowas.

Und dann fliegt dann...

Genau, vielleicht auch testen.

Also bei dem Beispiel, was ich eben gebracht habe, wo die

zwei 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 Emotions eingebe oder andere komische Strings.

Und wir haben aber auch einen End-to-End-Test, der das gesamte System testet.

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,

zu schreiben,

der halt wirklich eine echte Anfrage

gegen das echte System schickt, oder gegen Prod, also

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 amerikanischen 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.

Da geht es ja nicht um eine reguläre Kriegsführung nach 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 Inputs

zu zeigen. 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 wenn Jochen

der halt sagt, hilf ich, ich will keinen Space-Structure-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

und die

und Jochen unterhalten sich über die Programmiersprache Python

und Jochen unterhalten sich über die Programmiersprache Python

Petent 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 da vorstanden und

sagten, fuck, ich muss jetzt hier das Siegel drauf machen, obwohl ich eigentlich

in der Liste geschrieben habe, verstößt 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, hier das Siegel.

Das geht halt bei Software nicht so gut,

weil die muss man ja ändern und eigentlich braucht man

dann eine neue Zertifizierung.

Ja, genau, das wäre,

könnte man jetzt denken, dass das die Lösung wäre.

Ich habe das schon gemacht.

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.

Eine ERP 3 Plus oder ERP 4 oder so ein

Kram.

Ich kann

auch nur die humoristische

Variante irgendwie so, die unterste ist

irgendwie das Programm existiert,

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

und es existiert

ein formaler Beweis, dass das Programm korrekt ist.

Wo dann irgendwie so ein Zwischenschritt fehlt,

das ist, glaube ich, 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?

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, da musst du dir über Zeitstempel-Gedanken

machen, da 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, außer 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 also

für viele Anwendungen besser ist es,

wenn man sagt, ich mache einen Pentest, also 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-Good an, ich schaue mir das mal an,

was du so in Python oder auch in anderen

Programmiersprachen alles programmiert hast.

Und das sind dann halt erfahrene Entwickler

in der genau der Programmiersprache

und die können 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 den wesentlichen Leuten anfangen, uns zu coden.

Und das muss man natürlich auch

regelmäßig wiederholen. Das bringt natürlich nichts, wenn man vor 10 Jahren

das mal gemacht hat. Aber das ist auch

sicherlich eine Methode, mit der man

seine Anwendung gut absichern kann.

Du musst also den Angreiferhut aufsetzen und da draufhauen,

solange bis auseinander fällt. Da brauchen wir halt gute Angreifer

auch, die so ein bisschen ein paar Tricks kennen.

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 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 Benutzernamen

und Passwort irgendwie verfügbar und man kann beliebig

einen 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 brechen für das, was wir jetzt zu Corona-Zeiten kennengelernt haben als irgendwie Schweizer Käse-Modell.

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 es 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 meinem Haus aufschreibe,

und Jochen unterhalten sich über die Programmiersprache Python

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, ne dann

machst du halt lieber auch noch gleichzeitig sozusagen

eine externe Code Review

die sozusagen über das was du brauchst halt 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

knall 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.

Da habe ich irgendwie

ein Muster, das ich suche.

bei einer Bar und sagt, okay, wenn ich das Muster

finde, dann mache ich irgendwas, dann

unterbinde ich die Anfrage oder schmeiße das

Muster raus und mache irgendwas.

Das ist

schon ein bisschen gefährlich, weil

eine Möglichkeit ist halt schon, wie bei einem Visenscanner,

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 Schweißer Gessel,

Modell, das macht es vielleicht ein bisschen besser, aber gleichzeitig kann ja so ein Waf auch wieder

ein anderes Modell 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 Waf 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 Waf ist ja nur Code.

Ne genau, deswegen ist das 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

dann packe 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 er mir, jetzt machst du wieder aus

dann mache ich es halt wieder aus

und 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.

Und das ist halt tatsächlich was, das filtern wir dann damit zum Beispiel vorne weg.

Also jetzt hier haben wir den natürlichen SQL-Kram, das hat da nichts zu suchen, zack, weg, raus.

Ah, okay.

Ja, aber ich habe auch schon mal von jemandem gehört, der so Pentests macht,

dass er meinte, da war eine Bank, die hatte irgendwie ein System vor den Datenbanken

und das sollte eigentlich aus dem SQL irgendwie alles rausfiltern,

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 Quadrat Verbindungen

mindestens und

wenn du jetzt sagst, okay, das ist mir zu unsicher

ich packe noch eins davor

dann hast du noch mehr

n plus 1 Quadrat

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 in 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 dann auch wieder sparen und

wenn man das dann rauslässt, dann ist ja klar,

Fehler sind ja völlig vorprogrammiert

und sich da richtig vor zu schü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,

und Jochen unterhalten sich über die Programmiersprache Python

und Jochen unterhalten sich über die Programmiersprache Python

eigentlichen Zertifizierung oder die Prozesse, sondern vielleicht mehr, wie lasse ich die entwickeln?

Wie sorge ich dafür, dass, 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.

und 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. 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

Exploits, wenn man irgendwie genug nach sucht,

die irgendwo drinstehen und das wird dann

von den Leuten irgendwie geaudited und man fragt sich halt

okay, was machen die denn da eigentlich?

Warum tun die das?

Das ist halt wieder der Griff in Richtung

Product Security statt Process Security

Also ein prozesshafter

Ansatz und wir haben jetzt ja auch seit

einhalb Jahren, 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, ne, muss man nicht

ich habe auch eine 27, aber dann müsste man das doch auch mal so

nehmen müssen wir nicht.

Ja, aber, aber, ja, nehmen müssen wir nicht.

Dann dreht man so eine Schleife mit,

naja, die ISO sagt, du musst dich halt

um die für dich relevanten Normen und

Vorschriften kümmern, das sagt die

ISO 27000, 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.

Ihr könnt 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

du eben rechtliche

Rahmenbedingungen bewertest,

etc., weil du musst am Ende

immer für alle deine Assets

und für den hat das halt schon die vier

Grundsicherheitsaspekte, also

bei uns sind sie aufgeschlüsselt, 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... Ja, 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

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 NUS einbringt.

Stromkabel,

das kann zum Beispiel passieren,

wenn du deinen Prozess so aufschätzt und sagst,

und Jochen unterhalten sich über die Programmiersprache Python

und

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 fahre ich jetzt die Lücke

und sage, aha, ich hab rausgefunden, der ein Hoster

kauft immer irgendwie beim,

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

der 5-Dollar-Entschlüsselungsmaschine?

XKCD, bitte

nochmal einmal.

XKCD, Comic.

Da gibt es

eine schöne...

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

und wenn das für mich 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, also

wenn jetzt halt 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 den 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

so deswegen

ist eben

wenn man das mal schluckt und sagt

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.

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 drauf haben

und die installieren dann halt wie

hier in der Uniklinik Düsseldorf

deine Ransomware und die wollen halt,

die sind auch fast auf dem Level

von so einem Advanced Persistent Threat.

und 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 nochmal kurz, und nicht in Düsseldorf, da gab es einen Vorfall, da ist 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

Hab ich nicht verfolgt, muss ich zugeben

War aber auch, glaube ich, nicht der erste Fall in Deutschland

und ich glaube, Python hat es auch ein paar Mal so richtig erwischt

Die, ne, 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

und Jochen unterhalten sich über die Programmiersprache Python

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 ein 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 zu 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 den 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 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

Ja.

der Review-Prozess aber zum Beispiel auch umgedreht.

Der Review-Prozess

in dem 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 sein Aber der Pull ist halt wenn er gemerged wird ist das halt nicht die Aussage von dem Reviewer dass er seinen Erstgeborenen irgendwie mit Blut unterschrieben dem Teufel 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.

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.

und Jochen unterhalten sich über die Programmiersprache Python

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, ne?

Ja genau, also war eine Vulnerability,

und die

Anforderungen, Anforderungen 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 alles immer nur noch Asscovering, 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 erstmal 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, das ist interessant, was mir da gerade noch als Idee kommt.

Es gibt da 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

sehr, ja, so ein bisschen

diese Informationsasymmetrie dann ausnutzen.

Für mich

regelt das der Wettbewerb. Eine Firma, die so drauf ist,

wird halt Schwierigkeiten haben,

wirklich immer weiter 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 nochmal 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 CVEs oder sowas raus über die letzten 20 Jahre.

Viel mehr kommt da einfach nicht.

Und das ist halt auch schon mal was, wo man sagen kann,

okay, das ist was.

Auf der einen Seite die Sprache selber hat viele Probleme nicht,

so was 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 Doktorkittel angezogen

haben muss, um ja nicht daneben

zu tappen.

Ja, dann hat das glaube ich sowas wie Rust

auch deswegen gekommen, oder? Weil das genau das dann

wieder anders macht und

den Griff kriegt, ja.

Ja, ja, also Rust ist

auf jeden Fall, also ich meine, es kommt halt

immer darauf an, was man jetzt,

ich glaube eben vor Buffer-Overflows

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, man kann nicht viel dran machen und das ist natürlich schon irgendwie, irgendwie so, ja, das ist, ja.

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.

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,

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, die er 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 wieder hergibt.

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

Mellox groß und klein und

groß und klein zu machen, hat auch

Nachteile. Es hat Nachteile in der Hauptspeicherfragmentierung,

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 drauf steht,

verstehe ich, dass es in diese

Richtung neigt, eben eher

diesen universalen Ansatz 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, was ein Melloc ist, also du alloziierst irgendeinen Speicher?

Genau, also wenn du vom Betriebssystem halt Speicher haben möchtest, dann ist es heutzutage eh schon nur noch virtueller Speicher.

und die Programmiersprache Python

und dann teilt er ihnen 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 2er 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 aber 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 Append an Listen bei Python

ist

sind Listen nicht immer ein O von 1 Append?

Ja, sollte.

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 allozidierten Buffer für die

für das Array, um die Indizes zu verwalten

und

alloziiert aber, wenn er dann

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 muss er 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.

da habe ich lange Zeit meines Lebens auch immer mit dem Kopf

an 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 ok, frühmorgens haben die Leute ihren Kaffee getrunken, jetzt lesen sie alle irgendwie das was auf seiner Webseite ist

und Jochen unterhalten sich über die Programmiersprache Python

ist es schwierig, kontrollierbar schlanke

Prozesse zu machen.

Das geht nicht so ohne weiteres. Also das geht schnell,

dass dein, wenn du

zum Beispiel eine Datenverarbeitungspipeline

hast mit 9 oder 10 Schritten

und jeder Schritt davon braucht

irgendwie einen Gigabyte RAM,

dann kann das schon sein, dass dein Python nachher

10 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 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 Rast ohne weiteres nicht möglich ist

und auch in anderen Programmiersprachen 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 einen 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,

man hat das gefälligst nicht zu machen oder

man hat gefälligst immer Shell gleich false zu setzen

oder der Standard, dass man eine Liste

übergibt.

aber

es gibt noch zahlreiche andere

Schwachstellen, glaube ich, die

auf höherem Level noch passieren können,

die gar nichts mit dem Speicher direkt zu tun haben.

Ja,

absolut, genau.

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.

Der Shellout, den Philipp

da nennt, das ist schon schlimm.

Das ist klassisch.

auch sehr beliebt ist, wenn Leute

meinen, ich muss hier Flexibilität reinbringen

und jagen halt irgendwie User-Input einfach durch

ein Eval durch. Das ist sozusagen

die interne Variante des Shell-Out.

Was ist denn ein Eval?

Eval ist Evil.

Aber das ist im Prinzip die...

Oh ja, doch, Pickle.

Eieiei.

Ja, Pickle, nur trusted.

Ja.

Da kann man sich schon mit dem Fuß schießen.

Mit Eval haben wir 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-Schlafstelle 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,

die halt, also da kann man halt

Wenn man Schwachstellen verkettet, kann man das auf sehr krumme, sehr fiese Sachen, die man mit der einzelnen Schwachstelle gar nicht machen könnte.

Also das war jetzt nicht der Fehler von denen, also es war ein Fehler, dass man den Cache plötzlich sehen kann und es war ein anderer Fehler, dass sie überhaupt Ival verwendet haben, aber erst durch die Kombination ist es halt eigentlich eine Schwachstelle gewesen.

Auch so ein klassisches Ding ist ja 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

. . . Kombinationen plötzlich dir

dann irgendwie etc. pass, wenn du dir unseren 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 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.

in 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.

So, 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,

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 Passwort-Manager 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.

Und das ist halt, wie wir das bei Microsoft damals, alle zwei Millionen Mal,

ja, das ist bei uns halt nächsten Dienstag.

und

sowas, 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öttchen

und irgendwer greift

eh daneben und deswegen bin ich mal

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.

Aber wie bekommst du dann mit, wenn Exception passiert? Also an irgendein System muss das ja weitergeleitet werden, oder?

Ja, internes System. Ich habe mich hier heute jetzt noch nicht wieder vorgestellt, ich bin ja so ein bisschen Stammgast schon.

Philipp und und

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 hat 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.

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 listet er diese Anfrage aus. Ich glaube, da gab es auch schon mal Virus-Genere, 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, alles sofort blocken, 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 wir halt gerne mal rum

zu gucken, wie sie aussehen

und dann willst du halt immer noch die Möglichkeit haben, nochmal

durchgreifen zu können in dem Moment

Klar, aber ich meine

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 hatte ich nachher Kibakisch-Banane an

Ja

auch immer nur, dass man da externe Services

verwendet. Kein Problem, Sentry kann man

ohne Problem, ist ja 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, aber

stimmt, ist auch genau.

Sentry 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

der eine bugt 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, einfach so.

vor allem müssen die ganz viel mit Speicher machen

und ganz viel Level erarbeiten

genau, das was ich nicht haben will

also wo ich es noch sehe, wo ich noch mitspiele

ist, wo wir es gerne haben

wo es angefragt wird und wir dem nicht

harsch widersprechen

ist, wenn du

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 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 damit 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, Schlangenhöhle und so.

Ein gutes Konzept.

Was ich eben noch kurz erwähnt hatte, was ich mir noch irgendwann drüber gestolpert

bin, was bei Django eine DOS-Attacke möglich war, und zwar bei RackEx,

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 endlose

Schleife produzieren und dann die

Seite... Man kann Regex

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 zwinkern.

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.

Was ist das? Perl RegEx oder wie nennt man das?

Diese Perl Compatible RegEx

als PCIe, aber ich

weiß nicht, ob das...

Die Python RegEx Engine ist eine eigene.

Ja, okay.

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 einen Regex produzieren,

der einfach so lange dauert, weil ich einfach sage,

okay, hier kommt irgendwas Beliebiges und das

darf beliebig auch vorkommen und wenn ich dann

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 unerländlich nicht, aber schon mal

länger ist das Universum.

So, ich mache hier mal kurz,

wir müssen eine Chapter-Mark hier ziehen.

Ich muss jetzt raus, ihr könnt mich rausschneiden.

Alles klar, du kannst

das falsche sagen.

Wir haben eine Sekunde Pause gehabt, das könnt ihr rausschneiden.

Alles klar.

Insofern, bis zur

Fortsetzung demnächst mal wieder.

Euch noch 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 erstmal euch weiter.

Was willst du denn noch erzählen?

Es gibt, also, was

wichtig ist, dass

man eine Funktion nimmt

oder eine Standardmöglichkeit nimmt,

um sich gegen eine Sicherheitsschwachstelle

zu verteidigen. Also, wir haben eben schon

Path Traverses angesprochen, da könnte man denken, okay,

also, bei Path Traverses ist das Problem, dass ich

irgendwas in den Pfad einschleuse, typischerweise

halt . . . .

slash 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ß ich, die Passwortdatei oder die Datenbankdatei oder irgendwas anderes.

Und eine Möglichkeit, um sich dagegen zu beteiligen, 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.

und 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

Induction 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, in Prath

zu verhindern, kann man halt

os.path.basename oder aus der PathLib

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. An einigen Stellen kann das richtig

sein. Und ich glaube, ein anderes häufiges Problem

ist auch, dass man sagt,

ich versuche, die Eingabenbedarfen zu früh

abzufangen.

Also ich sage, okay, ich habe eine ganz komplizierte

Anwendung und immer wenn mir jemand

was mit einem Anführungszeichen schickt, dann sage ich, geht

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 da

daraus gibt oder welche Dinge man daraus macht, wenn das

nicht dem erwarteten Standard entspricht oder so.

Ein paar Stolperfallen, dass man einfach

interpretiert, was da kommt, ist wahrscheinlich

eine Mitte, wie die... Genau, man muss immer misstrauisch sein gegenüber

bei allen Daten, also auch der eigene Datenbank,

auch die kann Schrott enthalten.

Okay, guter Tipp.

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 und dass die Leute nutzen und sagen das ist der Standard den es da gibt Ich habe aber auch jetzt auch noch nicht so viel gefunden was man da anderes machen kann Es gibt irgendwie Passeto oder PyPasseto aber da gibt es noch nichts wirklich Nutzbares Das muss man irgendwie auch alles wieder selber machen vielleicht und das ist auch 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.

Ja, Session-Cookies ist halt

manchmal ein bisschen

schwierig, aber

Aber ja, das ist immer wieder, wo ich mir denke, das müsste doch eigentlich jetzt einfach sein, aber irgendwie ist es das nicht.

Oh, oder hast du mal so von Indie aus gehört?

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

das ist auch von dem

von den gleichen, also das hat

jetzt komme 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, wo man

normalerweise immer irgendwelche Unternehmen für braucht

die das halt machen

und es geht zum Beispiel darum, dass man sich mit seiner eigenen

Webseite einloggen können will

sozusagen. Also nicht

Username, Passwort, sondern man

gibt halt ein URL an und dann hat man

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 kriegt einfach eine E-Mail geschickt

oder so und drückt dann auf einen Link und dann

Ja, mal dein YubiKey bitte oder sowas. Genau, genau, genau.

und 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.

Das ist ja sicherlich immer die einfachste Lösung, wenn du sagst, ich möchte selber keinen Benutzernamen,

keinen 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

und Passwörter und ich verwende irgendein Single Sign-On-System. Du hast ja schon ORAS angesprochen

oder OpenID Connect, das ist ja der

alternative Standard,

dass man sagt, okay, jemand anders muss sich drum kümmern.

Und dann habe ich zwar diesen

anderen Dienst, der irgendwo vielleicht auch in meinem Netzwerk

ist oder vielleicht sagt, okay, ich erlaube

Login mit Facebook, mit Google, mit Twitter und so weiter

und mit GitHub.

Dann müssen die sich halt drum kümmern und dann kann ich halt

da auch meinen, 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.

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 irgendwie Schriftstelle 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.

Ich bin mir nicht sicher, ob das, was wir da gebaut haben,

alles so gut, so richtig funktioniert.

Das wird sich dann irgendwie im Laufe der Zeit zeigen.

Das müssen wir richtig testen. Mal gucken.

Beim ersten

Pentest, hoffentlich.

Oder beim ersten Pentest, der ungefragt ist

und ungefragt ausgesucht wird.

Ja, aber

was ich

vor allen Dingen blöd finde bei diesen ganzen

OpenID-OAuth-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 Blitz halt nur noch

ein Kennwort und Facebook kann halt sehr, sehr

viel bessere Sachen, bessere Authentifizierung

durchführen, als du es machen könntest.

Die schauen halt auf deine IP-Adresse, auf deinen Browser,

die haben noch einen Session-Token, die haben

vielleicht auch eine Mehrfach-Authentifizierung,

dass du noch

irgendwie auf dem Handy was bestätigen musst

und das gibt es ja

an einer Partei, das musst du nicht alles selber

implementieren.

Wenn du es selber implementierst,

Es gibt wirklich dann einige Firmen, die das dann wohl doch dann ernster nehmen, als man manchmal so denkt.

Ich war zum Beispiel mich einmal irgendwo ans Ausland geflogen, als man das noch durfte irgendwie

und habe eine relativ hohe Überweisung angefordert, irgendwie da so durchgeführt.

Und auf einmal bekam ich dann so einen Anrufer von meinem Telefon von der Bank, die meinte so,

ja, hallo, wollen Sie das wirklich tun? Oder waren Sie das?

Ja, das war ich. Ja, das ist ja alles gut.