Praktische Einführung in die Websecurity


Ashley: Willkommen zur nächsten Ausgabe der Taktsoft Campus Podcast der Podcast für Software und IT Professionals. Mein Name ist Ashley Steel und heute habe ich Ben Furmannek bei mir. Dann schießen wir mal los. Hallo, Ben.


Ben: Hallo, Ashley.


Ashley: Hi. Und wie geht es dir heute?


Ben: Ja, hervorragend. Schön, dass ich hier sein darf.


Ashley: Ja. Vielen Dank, dass du Zeit für uns genommen hast. Ja. Wir wollen in das Thema Web Security einsteigen. Aber vielleicht, bevor wir das machen, könntest du ein bisschen so zu deinem Werdegang erzählen? Quasi, was du so gemacht hast und was du momentan für Schwerpunkte hast?


Ben: Ja, gerne. Also, ich bin Ben Fuhrmannek, ich bin Informatiker, ich habe auch studiert und nach dem Studium habe ich mir etwas Zeit genommen, um Software zu entwickeln, relativ unbekannte Software und da wurde viel, viel gelernt, viel entwickelt mit den absurdesten Programmiersprachen, wie zum Beispiel mit Erlang. Es hat. Es hat. Es hat viel Spaß gemacht. Es wurde jedenfalls nicht langweilig. Aber es hat mich immer in Richtung IT Security gezogen. So bin ich nach ein paar Jahren gewechselt von der Softwareentwicklung in die IT Security und da speziell in die Web Security. Es ist nicht nur Web Security, sondern es geht auch in Richtung sagen wir mal Hardware, Hardware, Nähe. Ja, aber es ja. Bisher wurde es nicht langweilig. Das mache ich inzwischen seit elf Jahren, seit 2009, also mit zwölfte Jahr. Die Die Web-Security bleibt und ist spannend.


Ashley: Wir Das wollte ich gerade sagen. Ich denke, es gibt immer, immer Herausforderungen. Ich sag mal so Webentwickler, die haben viele Herausforderungen. Responsive Design, Datenschutz. Und so weiter. Und dann kommt das Thema Sicherheit. Und ich kenne das auch aus vielen Projekten, wo ich daran beteiligt war. Es wurde ein Stück Software entwickelt, alles gut und man wollte diese Software dann freigeben. Dann wurde es einen, ein Test oder ein Sicherheitscheck gemacht und dann kam eine Liste von Punkte, die verbessert werden sollten oder verbessert sollten. Und dann ist halt die Frage okay, oder? Zwei Fragen für mich erstmal Welche Sachen muss man berücksichtigen? Quasi welche Art von Angriffen gibt es? Und dann die zweite spannende Frage ist Was kann ich dann während der Entwicklung machen, um zu vermeiden, dass ich hinterher wirklich, ich sag mal so viele offene Punkte haben, die ich dann nacharbeiten muss? Und vielleicht fangen wir mit dem mit dem ersten Thema an Welche Angriffs Techniken gibt es momentan?


Ben: Ja, das ist eine sehr gute Frage und das ist auch eine Frage, die im Rahmen dieses Podcasts nicht vollendet beantwortet werden kann. Es gibt einfach so furchtbar viele Angriffe, aber ich kann einfach mal, ich kann einfach mal erzählen, wie das normalerweise so abläuft, wenn jemand bei uns anruft und sagt Herr Fuhrmann, wir haben da ein Problem.


Ashley: Hilfst du mich? Have a problem.


Ben: Genau wie wir. Wir brauchen sie da mal, aber meistens ist es so, also vielleicht in der Hälfte der Fälle ist es so, dass der Kunde nicht so genau weiß, was er möchte. Er möchte natürlich, dass die Software sicher ist und dass er keine Probleme mehr hat, aber wir da hinkommt, das versucht er auch noch von mir zu erfahren. Das heißt, die, die Telefonate, die laufen dann so ab. Ja, wir haben da ein Problem und dann wird so ein bisschen um das Problem außen herumgeredet. Aber da wir den ersten Kontakt haben, sozusagen es gibt noch kein NDA, es gibt noch keine Vertrauensbeziehung, wird nicht so richtig gesagt. Übrigens, ich bin von der Firma Soundso und wir wurden gehackt. Das ist. Das ist nicht so, das ist nicht das erste, was passiert. Aber so ist es nun mal manchmal. Manchmal ist es auch so, dass gesagt wird Ja, wir wollen halt nicht gehackt werden. Wir wollen nicht, dass jemand unsere Daten abgreift und deswegen lassen wir da jetzt mal draufgucken und dann gibt es ein Freigabe Prozess. Oder es gibt vielleicht ohnehin jemanden, der sich damit auskennt, aber eigentlich mit einer anderen Sichtweise draufgeht, nämlich mit der Sichtweise des Entwicklers und sagt Ja, es ist eigentlich jetzt gut entwickelt, aber lassen wir doch noch mal den Experten draufgucken. Na ja, und dann geht es los. Ich habe mehrere Optionen zur Auswahl. Das eine ist eine Penetration Test. Da geht es hauptsächlich darum, so zu tun, als wäre ich der Angreifer von außen, also der böse Angreifer, sage ich mal, und versuche anzugreifen. Ich guck einfach mal, was geht das? Da würde ich gleich noch mal näher darauf eingehen und auch, welche Arten von Angriffen da passieren können. Überhaupt was, vielleicht auch, was man dagegen tun kann in Teilen. Genau dann habe ich die Option einer Quellcode Analyse. Wenn wenn sich die Firma traut den Quellcode rauszugeben, dann kann ich einfach sagen ja, ich gucke mir den Code mal an und das ist für mich meistens sehr sehr amüsant, denn ich bin in der in der vorteilhaften Position, dass ich nur die Fehler erkenne und mich darüber lustig machen kann. Und dann, also sozusagen, wenn man sich das bildlich darstellt, kann ich hingehen und sagen Haha, da hat jemand was falsch gemacht. Und jetzt kann man über diesen und jenen sehr skurrilen Weg einen Angriff starten. Und das ist, das ist aber nicht böse gemeint, sondern im Gegenteil, es ist sehr. Vorteilhaft, denn entweder habe ich recht und der andere hat was dazugelernt oder der andere hatte recht und ich habe was dazugelernt. Irgendeine absurde neue Programmier Technik beispielsweise.


Ashley: Also es gibt kein es gibt keine Verlierer dann sozusagen. Es gibt da nur Gewinner.


Ben: Ja genau. Und meistens ist es aber so, dass die Anwendung angegriffen werden kann auf die eine oder andere Art und Weise. Und das wird dokumentiert und dann bekommt der Kunde Berichte, das war's im Wesentlichen. Und dann gibt es natürlich noch die Option wer, vor allem, wenn ich merke, irgendwie die, die Leute haben ja irgendwie mehrere Jahre programmiert, aber nicht so richtig darauf geachtet, ob es vielleicht Angreifer gibt oder nicht. Aus verschiedenen Gründen. Dann sage ich denen Ja, besucht doch mal eine Schulung und ich biete auch eine Schulung an, so ein Zufall, das sage ich den Kunden natürlich.


Ashley: Aber das sage ich den Kunden nicht.


Ben: Die können von mir aus auch woanders eine Schulung besuchen. Aber manchmal ist das wirklich sinnvoll. Ja, so sieht das aus, wenn sich dann der der Kunde entschlossen hat und gesagt hat Ja, ich habe eigentlich, ich habe nicht so viel Geld gucken. Gucken Sie doch mal so ein bisschen drauf. Dann. Dann machen wir erst mal einen Test und gucken, wie sieht es denn aus? Und wenn wir in den, sagen wir im ersten Tag, in den ersten zwei Tagen schon schon was finden, dann wissen wir danach, wie es weiter gemacht wird. Ja, und dann? Dann geht es weiter. Dazu muss man wissen Ja, bitte.


Ashley: Ich wollte nur sagen und dann okay, dann gibt es Test Quellcode Analyse. Aber dann vielleicht dann doch mal ein bisschen reingehen, welche Art von Angriffe es dann dann gibt. Was, was, was erkennst du? Ist das ein Denial of Service oder ich? Ich kenn mich da wenig aus. In diesem Bereich muss ich auch sagen, ich lerne heute viel lernen von dir. Aber welche Art von Angriffe dann sind so die typische in Anführungsstrichen bin ist mir schon klar, dass wie du sagst, da gibt es immer wieder neue neue Sachen. Aber was sind so die typische Sachen wo wie angegriffen wird oder irgendwelche Topics sage ich mal so momentan die du, die du gesehen hast.


Ben: Ja, das ist eigentlich der Knackpunkt, das ist die, das ist die große Frage, die es herauszufinden gilt. Was ich meistens mache, ist, ich stelle mir vor, wie denn der Angreifer die Anwendung sehen würde. Der der Entwickler selbst weiß natürlich, wie seine Anwendung aussieht, aber der Angreifer weiß das nicht. Der muss sich also ein Modell vorstellen. Das Modell sieht meistens so aus, dass man sich denkt, es gibt irgendeine Art Server Seite. Das stellt die Applikation selbst da. Die Server Seite kann natürlich beliebig komplex sein, das können hunderte micro Services sein oder ganze Server fahren, die redundant ist. Und so weiter. Das spielt eigentlich erst mal keine Rolle für den Angriff im Detail dann schon, aber erstmal keine für das Modell. Dann gibt es meistens einen Client, also das ist der Webbrowser und den Benutzer dazu. Der Benutzer benutzt den Webbrowser, der Webbrowser macht sowieso, was er möchte. Also Webbrowser sind Monster an Code, also es steckt, es steckt einfach so viel Code in diesem Webbrowser. Ja, zu Recht. Die sollen ja etwas tun, die sollen das Web darstellen, die sollen irgendwie interaktiv sein, die sollen alles Mögliche nachladen und Bilder nachladen und JavaScript und vielleicht noch Applets. Und vor ein paar Jahren war es auch noch Flash Applets und was nicht, das ist inzwischen tot, aber es wird jedenfalls einiges nachgeladen. So, jetzt gibt es also eine Interaktion zwischen der Anwendung und dem Browser, meistens nicht direkt zwischen der Anwendung und dem Browser steht noch was dazwischen, und zwar das Internet. Natürlich klar, der möglicherweise der Angreifer. Also das schlimmste Szenario wäre genau zwischen dem Server und dem Browser sitzt der Angreifer und liest alles mit. Und das ist eigentlich auch das Szenario, von dem ich ausgehe, so dass sozusagen mein Anhaltspunkt, das heißt, wenn ich einen Angriff starte, dann setze ich mich auch genau zwischen meinen eigenen Browser und den Server und dann gucke ich, was geht, dann gucke ich, was der Browser sendet, dann gucke ich, was hier an Anwendung antwortet. Ich bin aber nicht der Einzige, der das tut. Meistens gibt es noch eine Anzahl. Proxy ist dazwischen, denn den ersten Proxy kann man sich vorstellen in in einem großen Konzern, zum Beispiel Virenscanner, der bei allen Downloads nachsieht. Ist das, was da heruntergeladen wurde, eigentlich erlaubt? Darf man das herunterladen? Vielleicht ist es gesperrt, vielleicht ist es ein Virus. Vielleicht gibt es irgendwelche anderen Gründe, weshalb man das nicht runterladen darf. Oder vielleicht soll es gekappt werden, damit es schneller geht, damit man Bandbreite spart. Das ist so der der erste Proxy. Vielleicht gibt es auch lokal auf dem auf dem Desktop System des Anwenders auch noch mal einen Proxy. Vielleicht auch aus Virenscanner Gründen. Dann auf Server Seite gibt es auch noch nochmal eine Anzahl Proxy zum Beispiel um eine gewisse Verteilung zu implementieren. Man sagt ja es geht erst mal zum Proxy und der entscheidet dann, wo geht da eigentlich Anfrage hin, zu welchem der vielen Server, die dahinter stehen? Das weiß ich natürlich erst mal nicht, wenn alles richtig konfiguriert ist. Finde ich das auch nicht heraus. Das ist für mich dann transparent. Aber das muss man wissen. Also die, die das Szenario sieht nun so aus. Wir haben den Webbrowser, dann haben wir eine Anzahl Proxys. Einer davon bin ich und dann haben wir die Anwendung selbst, so die Anwendung selbst. Die steht natürlich nicht alleine da, die möchte selbst auch noch mal kommunizieren. Zum einen natürlich zurück zum Browser, aber den Weg haben wir jetzt schon abgehandelt. Das geht über den Proxy. In die andere Richtung gibt es unglaublich viele, was passieren kann. Also zum einen, es gibt eine oder mehrere Datenbanken. Vielleicht gibt es besonders schnelle oder andere artige Datenbanken, so was wie Cache oder andere Caching Mechanismen. Vielleicht gibt es ein Dateisystem, wo etwas nachgeladen wird, wo etwas hingeschrieben wird. Vielleicht werden System Kommandos ausgeführt in der Shell, vielleicht werden Emails verschickt, vielleicht gibt es interne oder externe API Calls, die ausgeführt werden. Zum Beispiel was ich Bezahlvorgang bei irgendeinem Dienstleister oder man man guckt über was ich im Telefonbuch nach wieder die Telefonnummern sind von den Mitarbeitern. Also es gibt gibt unglaublich viele Dienste, die im Hintergrund laufen können. So. Das waren schon einige Angriffspunkte. Alles, was ich an Komponenten erwähnt habe, also Benutzer, Browser hochgeladene Komponenten, Proxy, die Datenbank, das Dateisystem, die Shell, der E Mail Verkehr, die externen APIs all das kann man angreifen und die Kommunikation dahin und wieder zurück. Und daraus ergibt sich natürlich auch, welche Art Angriff man dort fahren kann. Also den den Browser greift man an, in dem im Browser etwas angezeigt wird, was eigentlich so nicht gedacht war. Am besten natürlich Code, der ausgeführt wird, also meistens JavaScript Code. Das ist dann das Cross Height Scripting X. Das ist so, das ist ein ganz beliebter, auch sehr einfacher Angriff. Dann geht es weiter, auch gleichzeitig diverse Session Angriffe. Vielleicht kann man eine Session übernehmen, vielleicht gibt es eine Session IT, die nicht geschützt ist. Vielleicht wird die irgendwie übertragen, wie es ein bisschen ungewöhnlich ist. Vielleicht ist die nicht verschlüsselt. Und dann gibt es Angriffe auf den Benutzer selbst. Zum Beispiel, wenn der Browser anzeigt, geben Sie Ihr Passwort ein und dann gibt es einen Benutzer, da gibt es ein Passwort, ein, dann ist das ein Angriff gegen den Benutzer oder so was wie Click Checking. Hast du schon mal Click Checking gehört?


Ashley: Habe ich nicht gehört.


Ben: Das ist das absurdeste Angriff überhaupt. Und zwar bekommt man als Benutzer etwas angezeigt, zum Beispiel ein Spiel auf der Seite des Angreifers. Wie kommt man da drauf? Da stellt man sich natürlich zu Recht die Frage. Aber das Internet ist nun mal voll mit Spielen und Leute sind nun mal langweilig. Also Leuten kann langweilig sein. Leute selbst sind nicht spannend, aber.


Ashley: Klickt man, ohne dass man darüber nachdenkt, was man eigentlich tut?


Ben: Auch das passiert ja, oder? Es ist so was wie Ich habe fünf Minuten Zeit, ich möchte mal meine Nerven abreagieren. Wo gibt es denn hier Moorhuhn oder irgendwelche Spiele? Na ja, passend platziert sind natürlich die Angreifer Seiten und dann kommen die Spiele im Hintergrund und das sieht der Anwender nicht, wird in Wirklichkeit eine Anwendung von dem Anwender geladen. Aber die ist transparent, sodass er zwar in der Anwendung rum klickt, er merkt es nur nicht. In Wirklichkeit klickt er aber da drin rum und was er sieht, ist das Spiel, das er spielt. Was auch immer das sein kann, das kann beliebig komplex sein. Von mir ist es ein 3D Shooter, Doom oder was auch immer, was so im Browser läuft. Im Hintergrund klickt er in Wirklichkeit um zu gewinnen, exakt da, wie es die andere Anwendung erwartet, um irgendeine lustige Aktion auszulösen, zum Beispiel um neue Benutzer anzulegen oder zu löschen oder um Zeiten zu buchen oder um Freunde zu bekommen von irgendwelchen Leuten oder um Geld zu verschicken oder was auch immer die Anwendung tut. Das sieht der Angreifer nicht und das sieht auch der Benutzer nicht. Aber die Anwendung, die ferngesteuert wird, die sieht es natürlich. Und dass das passiert, indem die Anwendung in einem Frame geladen wird. Und das Frame ist transparent, sodass der Benutzer nicht sieht, was passiert. Also, es ist ein ganz lustiger Trick Click Checking. Das wurde als erstes verwendet, als es noch Flash gab. Also manche Leute, die noch, die schon ein bisschen älter sind, kennen das noch, diese Flash Applets irgendwie Werbebanner blinken.


Ashley: Weil ich kenn Flash noch. Ja.


Ben: Ja ich auch. Und da gab es so eine Konfiguration Webseite. Das war eine ganz normale URL, die man aufruft und dann bekam man einen Konfigurator, wo man sagen kann, für diese Webseite möchte ich die Kamera freigeben und das Mikrofon. Das hat der Benutzer natürlich nicht gesehen. Der Benutzer hat in Wirklichkeit ein Spiel gespielt. Tatsächlich wurde aber seine Kamera freigegeben und das Mikrofon und da ein Video von dem gemacht.


Ashley: Ja.


Ben: Das ist. Das ist der Trick. So, jetzt gibt es da ganz einfache Maßnahmen, wie man das verhindern kann. Und wenn man die einhält, dann ist alles wieder gut. Aber das zeigt, wie wichtig es ist, einmal zu prüfen, ob dieses Problem existiert oder nicht. Das ist auch ein sehr, sehr einfacher, schneller Test. Man muss nur einmal wissen, dass es das Problem gibt und wie man das verhindert. Und das war es und das, das gilt eigentlich für alle Schwachstellen, die bekannt sind.


Ashley: Zumindest aber wenn ich jetzt so ich habe so ein Bild vor Augen, jetzt wie gesagt, es mit dem Browser mit mit Proxys, mit meiner Kommunikation. Ich habe mein backend system, ich habe mein datenbank, ich habe meine schnittstelle wie du sagtest, du Bezahldienst oder ich. Ich rufe Daten von anderen Systemen ab. 1111 riesen komplexes Miteinander. Sag ich mal so von diesen Services, um eine Anwendung darzustellen. Wenn ich dann so die Frage stelle okay, als Entwickler während der Entwicklung, wie kann ich ihn, ich sag mal, so frühzeitig darüber nachdenken, dass sich bestimmte Lücken schließen? Verschlüsselung ist als ein einfaches Beispiel, aber gibt es dann irgendwelche, ich sage mal so Tipps, Tricks Guidelines? Wo du sagst. Okay. Während der Entwicklung. Denk über das, das und das nach. Ich denke, das, das, das. Und das ist wahrscheinlich. Hundertmal kann ich das sagen. Aber welche Tipps und Tricks könntest du dann ein Web Entwickler geben? Ich sehe das. Du lachst jetzt. Du. Du schmunzelt so ein bisschen. Ich denke die Liste wird lang, aber da gibt es ein paar Kern Sachen wo du sagst, da muss man wirklich ich sag mal so drauf konzentrieren, fokussieren während der Entwicklung, so das dann hinterher während eines Tests oder eine Call Code Analyse, dass diese Lücken nicht vorhanden sind.


Ben: Tja, also das ist eine sehr gute Frage. Was kann man mal eben tun, damit man sich entwickelt? Das ist die Frage, die ich verstanden habe.


Ashley: Genau. Genau.


Ben: Genau. Und das ist. Das ist keine so furchtbar einfache Frage. Also, welche Empfehlung kann man geben, damit man sicher entwickelt? Ja, man muss halt wissen, was man tut. Dafür ist man professioneller Softwareentwickler. Dann kann man sich ja entwickeln. So einfach ist es natürlich nicht. Es gibt ein paar Stichworte, die immer wieder fallen. Wenn ich eine Schulung gebe, dann ist das so die Haupt, das Hauptproblem und auch die Lösung für praktisch alle Probleme. Und zwar ist das die Eingabe Validierung und die Ausgabe Behandlung. Es ist immer dasselbe Eingabe, Validierung, Ausgabe, Behandlung, Eingabe. Validierung bedeutet, wenn der Benutzer etwas eingibt. Dann darf das nicht ungeprüft verarbeitet werden, sondern man muss als Entwickler wissen Was darf der denn überhaupt eingeben? Wie lang dürfen die Daten sein? Welchen Datentyp haben die Daten? Kann man das einschränken? Braucht er über? Muss ich überhaupt diese Daten angeben, nicht nur aus Datenschutzgründen, sondern ist es überhaupt nötig, das zu verarbeiten? Wenn man die weglassen kann, dann lässt man die weg. Wenn man die einschränken kann, dann schränkt man die ein. Wenn er nur bestimmte Zeichen eingeben darf, dann filtert man eben serverseitig, damit nur die Zeichen eingegeben werden dürfen.


Ashley: Aber ich sag mal so, nur zu meinem Verständnis das ist so eine Art von Eingabe. Wenn ich dann wirklich so eine Eingabemaske habe und ich erst benutze, dann was eingeben muss, was ist aber dann, wie gesagt von vom Backend sage ich mal so, ich rufe dann eine externe System auf. Das heißt, ich habe keinen Benutze, der was eingibt. Aber ich bekomme eine Antwort auf meine Anfrage über 111 API. Ist das dann gängig oder gilt es dann genauso dann für diese Eingabe Validierung, wenn es von einem anderen System oder einen anderen Service, dann wo wo die Daten herkommen?


Ben: Also das, das ist natürlich auch eine gute Frage. Nicht nur der Benutzer kann Angriffe starten, auch auch Tools können Angriffe starten auf APIs. Das ist sogar sogar der Normalfall. Also ich selbst beschäftige mich nicht mehr mit langweiligen, automatisiert baren Angriffen. Da drücke ich einfach auf das Tool und sage Start und dann, dann, dann kommt raus Ja, ist verwundbar oder ist nicht verwundbar. Selbst beschäftige ich mich hauptsächlich nur mit den spannenden Angriffen wie logische Fehler beispielsweise. Ja, aber um auf die Frage zurückzukommen Es spielt keine Rolle, ob ob es eigentlich gedacht war, dass der Benutzer die Daten eingibt oder ob es gedacht war, dass ein Tool die Daten eingibt bei einer API Schnittstelle. Das ist für den Angriff dasselbe.


Ashley: Weil quasi jede externe Schnittstelle, egal wie diese Schnittstelle dann bedient oder mit Daten gefüttert wird, muss dann diese Eingabe Validierung dann oder es muss eine Eingabe Validierung dann geben, wenn ich das so richtig verstanden habe.


Ben: Das ist ja, das ist eine gute Zusammenfassung. Also geht jede jede Benutzer Eingabe muss validiert werden. Ja, das ist das einfachste Beispiel. Ist tatsächlich ein Formular so was wie geben Sie Ihr Alter ein und man gibt nicht ein 97 oder wie alt man auch immer ist, sondern gibt zum Beispiel einen -15 ist nicht der richtige Wertebereich oder man gibt ein ABC falscher falsche Zeichen, das funktioniert nicht. Oder man gibt vier Gigabyte Daten ein. Das ist ein bisschen ein bisschen lang, die Zahl wäre zu lang. Oder man gibt gar nichts. Einmal lässt den Wert weg. Das ist auch falsch. Man braucht ja den Wert. Ja, also das ist. Also beim Alter ist das relativ einfach, da kann man sehen, ja, ist das eine Zahl, ist irgendwie sinnvoll. Alles klar. Bei bei anderen Eingabe Werten ist das nicht ganz so trivial wie ich. Geben Sie Ihren Namen ein und dann nimmt man als Entwickler immer an Ja, wie lang kann denn schon so ein Name sein? Reichen vielleicht 20 Zeichen? Reichen 50 Zeichen aus? Niemals. Es gibt Leute, die haben absurde, wirklich, wirklich lange Namen. Und dann hat man vielleicht immer denselben Namen. Stimmt auch nicht. Nein. Es gibt Leute, die wechseln ihre Namen, oder die führen mehrere Namen gleichzeitig. Also Hochzeit ist das einfachste Beispiel, wo man seinen Namen wechseln kann.


Ashley: Und du sprachst auf das Thema Ausgabe behandelt. Hat es die zwei Themen angesprochen Eingabe, Validierung, dann Ausgabe, Behandlung. Könntest du einen kurzen paar Tacken dazu sagen? Zum Thema Ausgabe Behandlung.


Ben: Ja, Eingabe Ausgabe. Das gehört auch ganz gut zusammen. Also die, wenn man eine Eingabe tätigt, dann muss die irgendwann auch weiterverarbeitet werden und egal in welche Richtung die weiterverarbeitet wird. Da muss ich noch mal angefasst werden mit mit einem Äquivalent zur Eingabe Behandlung sozusagen. Das Beispiel Ich ich gebe ein Name ein. Der Name ist was ich O'Reilly mit apos. Mit Anführungszeichen, mit Apostroph drin. Also Anführungszeichen sind problematisch, wenn es um SQL geht, beispielsweise SQL, die Sprache, um Datenbanken abzufragen. Da werden Strings mit Anführungszeichen gestartet und damit beendet. Ich möchte also nicht, dass Anführungszeichen auch verwendet werden, um aus diesem Namen auszubrechen und zu sagen wie Anführungszeichen. Nach dem o vom O'Reilly. Beende ich jetzt mal einen String und danach schreibe ich mit SQL weiter. Dann hätte ich eine große Schwachstelle, nämlich die SQL Injection. Da muss man also noch was tun und das tut man nicht von Hand, sondern da gibt es für jede Art Ausgabe in dem Fall die Ausgabe Richtung Datenbank. Da gibt es was schon. Und zwar verwendet man ja ein Framework, wenn, wenn man es sinnvoll strukturiert entwickelt. Und in dem Framework gibt es dann die Möglichkeit zu sagen, ja, ich nehme entweder Escape. Um die Daten zu skripten. Da kommt dann ein Backslash vor, das Anführungszeichen oder ich verwendet prepare Statements, sodass separat SQL und Daten separat sind. Oder ich abstrahieren meine Datenbank und sage Kümmere du dich mal darum Framework und dann schreibt man gar kein SQL mehr, das. Das beste Beispiel dafür wäre zum Beispiel Ruby und Rails. Das waren die Protagonisten, die haben einfach gesagt Ja, wir machen hier Magie. Der Entwickler muss sich gar nicht mehr drum kümmern. Das passiert irgendwie im Hintergrund. Dann ist schon alles gut. Aber inzwischen kann das eigentlich alle modernen Frameworks. Eine Abstraktionen, wo man sagt, ich speichere das dann mal irgendwie, aber kümmer dich nicht weiter drum.


Ashley: Gibt es denn? Ich glaube, ich weiß, wie du diese Frage beantworten willst. Aber gibt es dann Bereiche, wo ich sage mal so, spezielle oder besondere starke Schutzmechanismen gebraucht werden? Ich sehe, du lachst wieder. Ja oder nein?


Ben: Es sind immer gute Fragen. Also.


Ashley: Ja, aber das ist. Ich habe. Ich habe dieses Bild. Und das ist ein wahnsinns komplexes Zusammenstellen von Services. Schnittstellen. Dann frage ich mich okay. Erstens kann ich alles abdecken. Und zweitens, wenn ich nicht alles abdecken kann, gibt es dann Bereich, wo ich wirklich sah, wo ich wirklich mich darauf konzentrieren muss als Entwickler? Und ich sage mal so, um eine Priorisierung in Anführungsstrichen dann zu zu zu finden.


Ben: Ja, also die die Frage nach der Priorisierung ist, ist immer eine gute Frage. Also wenn, wenn ich eine Anwendung untersucht habe, dann bewerte ich die Schwachstellen nach Kriterien und besonders kritisch. Bewertete Schwachstellen sollte man natürlich zuerst beheben und weniger kritische, die kann man später beheben. Im Endeffekt ist es natürlich besonders schön, besonders sicher für die Anwendung, wenn alle Probleme behoben sind, also alle sicherheitstechnischen Probleme. So ob die Anwendung tatsächlich noch Probleme hat und deswegen nicht funktioniert, das interessiert mich meistens nicht. Das ist die Aufgabe des Entwicklers. Mich interessiert es nur, ob die Anwendung mehr kann als das, was sie eigentlich soll, damit sie nicht angegriffen werden kann.


Ashley: Gibt es dann irgendwelche Anekdoten, die du erzählen möchtest bzw erzählen darfst? Auch klar, das ist sicherlich ein sehr sensiblen Bereich in deiner oder aus deiner Menge Erfahrungen, die du gesammelt hast. So entweder wo du einmal den Kopf geschüttelt hattest oder wo du sagst Wow, das war richtig kniffelig, was da los war. Gibt es irgendwelche Sachen, die du, ich sage mal so, aus dem Nähkästchen sozusagen, äh erzählen kannst?


Ben: Ja, gibt es, was ich erzählen kann? Also normalerweise, wenn ich eine Schulung gebe, dauert die drei Tage und zweieinhalb Tage davon sind Anekdoten. Also ganz so ist es natürlich nicht, aber praktisch zu jeder Schwachstelle kann man irgendwas erzählen und es wird nicht langweilig. Also ich kann. Um darauf hinzuarbeiten, kann ich einfach noch ein paar Schwachstellen erklären und im Rahmen der Schwachstellen dann sagen Ja, das sind, das ist typisch für diese Schwachstelle. Und das ist sozusagen die Anekdote, auch wenn sie manchmal nur sehr kurz ist. Genau. Also wenn, wenn ich so ein Test starte, dann starte ich meistens mit mit einer Infrastruktur Analyse, wo ich einfach mal gucke was was hat denn die Firma so im DNS? Welche Namen gibt es denn? Welche Namen gibt es denn für die Firma? Für die Domain? Welche? Dann mache ich ein paar Scans und gucke mal, was ist denn da so offen? Ja, und das das Schlimmste, was an der Stelle schon passieren kann, ist, wo ich eigentlich einen Angriff noch gar nicht gestartet habe, ist, dass da was gefunden wird, wo man sagt Moment, es gibt zwar www Firmenname, aber es gibt auch www test Firmenname. Und dann probiert man natürlich aus irgendwie Test Test, Admin, admin, STANDARD Passwörter, irgendwie was, was könnte denn da gehen? Oder Name der Firma? 123? Wenn jetzt ein Zuhörer lacht, dann sollte er mal das Passwort ändern. Also das.


Ashley: Ich. Ich muss mein Passwort nicht ändern. Meins ist 1234.


Ben: Ja, es ist verblüffend häufig und die Passwörter sind teilweise tatsächlich so, so einfach. Es ist ja nur ein Testsystem, da muss es nicht sicher sein. Aber die Test Systeme sind unglaublich spannend für mich. Also wenn ich da reinkomme, dann bin ich schon mal in deren Netz, dann kenne ich schonmal die Anwendung, dann kenne ich die URLs der Anwendung, die ich eigentlich angreife, dann kenne ich vielleicht die anderen Anwendungen oder die Art, wie die Entwickler der Firma entwickeln, wie das ungefähr funktioniert, welche Probleme die da haben. Vielleicht haben dieselben Probleme auch in der anderen Anwendung. Vielleicht ist das ein System, wo ich noch mehr Informationen rausziehen kann, weil das zum Beispiel ein Bug Tracker ist. Das kommt vor.


Ashley: Ja. Das heißt, man darf nicht nur das Thema, ich sage mal so. Wie stelle ich fest, wie stelle ich sicher, dass man Produktionssystem sicher ist, sondern immer so Development, Environment, Test Umfeld oder Pre Production Systeme? Ja, und auch diese Hinweis was du sagst. Vielleicht kommst du dann in einen Bug Tracking, dann siehst du die Bugs und dann daraus schließen kannst. Okay, wenn dieses noch vorhanden ist, dann kann ich dann über diesen Weg im System reinkommen. Wow.


Ben: Ach ja? Also da, der. Der Angriff wird erst mal vorbereitet, so wie es ein echter Angreifer auch machen würde. Der. Der Angegriffene bekommt noch gar nichts davon mit. Unter Umständen. Also normalerweise betreibt man sein DNS Server nicht selbst, sondern man verwendet irgendeinen Dienstleister dafür. Der Dienstleister ist es gewohnt, dass da gescannt wird, der hat einfach gute Nameserver. Das das interessiert den nicht, da kann man ruhig kennen, das ist das ist noch kein echter Angriff, der bekommt das nicht mit. Und der, der. Kommt das auch nicht mit. Ports bekäme man theoretisch schon mit. Die sind aber so geläufig, dass es eigentlich keine. Also da gehen keine Alarmglocken an in dem Sinn. Es ist eigentlich ganz normal. Sobald man irgendwas im Internet hat, wird gescannt. Nicht nur von mir. Ich habe den großen Vorteil, dass ich es noch darf. Ich habe ja einen Vertrag, wenn ein Kunde zu mir kommt und sagt Hier, machen Sie das doch mal und ich mache das, dann kommt nicht die Polizei vorbei, sondern ich habe den Vertrag. Ich darf das. Das ist ja Luxus. Luxus. Von meiner Seite zu sagen Genau. Ich habe denselben Spaß wie die Hacker, nur dass ich es darf.


Ashley: Landet nicht im Knast. Sozusagen. Ich meine, dass in den in den letzten 25 Minuten, als wir da gesprochen haben, ich, ich, ich, ich sehe dieses noch mal, dieses wirklich komplexes Bild vieler Möglichkeiten, wo ein Herr Hacker mal angreifen kann oder jemand von extern angreifen kann. Und ich glaube, wir könnten noch zwei Stunden miteinander und und uns unterhalten über die. Über dieses Thema. Und ich denke, du machst auch oder du wirst es demnächst auch im Rahmen vom Talkshow Campus auch so Seminare oder Blended Learning machen, wo du dann auch noch mehr ins mehr digital reingehen kannst und um die Leute mehr zu erzählen, was die zu berücksichtigen haben, auch ich sage mal so, dieses ganze Thema zu zu vertiefen. Und ich denke für für die Leute, die jetzt in der Webentwicklung da einsteigen, das ist auf jeden Fall ein sehr, sehr, sehr guten Anhaltspunkt. Bzw zu empfehlen war, wie wir gesagt haben, alles was man vorher ausschließen kann. Es ist, ist ist besser. Ja, gut.


Ben: Ja.


Ashley: Möchtest du ein paar abschließende, abschließende, abschließende Worte sagen? Denn, wie gesagt, das war ein sehr, sehr spannendes Unterhaltung.


Ben: Ja, da könnte man praktisch einen zweiten Podcast anschließen.


Ashley: Ja, wir können das auf jeden Fall mal vorschlagen. Das wäre eine gute Idee. Würde mich sehr freuen, wenn wir das machen könnten. Ben, vielen, vielen Dank für deine Zeit. Wie gesagt, ich glaube, das war nur der Spitze von Eisberg, was wir angerissen haben. Aber ich denke schon, dass es ein sehr gutes Bild von den Komplexität und wie umfangreich dieses Thema Web Sicherheit ist. Vielen, vielen Dank für deine Zeit.


Ben: Ja, vielen Dank, dass ich hier sein durfte.


Ashley: Und ich sage mal so, bis die Tage an ich wird mein Passwort jetzt ändert, muss ich nicht tun. Herzlichen Dank. Ja.


Ben: Ja. Bis zum nächsten Mal.


Ashley: Bis zum nächsten Mal. Ciao. Taktsoft Campus Podcast Der Podcast für Software IT Professionals Im Taktsoft Campus Podcast beschäftigen wir uns mit einem breiten Themenspektrum, um euch zu helfen. Praxis Fragen zu Technologie, aber genauso Fragen zur Umsetzung, Prozessen oder Projektorganisation. Danke, dass ihr dabei wart. Euer Taktsoft Campus Podcast Team.