Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Ritschi und habe eine Folge von den Software Quality Days 2024 aus Wien mit im Gepäck. Bei mir zu Gast war Christian Bieler, ein Experte für Sicherheit und Sicherheitstests. Das Thema ist gerade brennender denn je, denn wo bis jetzt vielleicht Sicherheitstests am Ende der Softwareentwicklung einmal als Pen-Test gemacht wurden, geht es mittlerweile darum, wie man
Sicherheit im gesamten Softwareentwicklungszyklus betrachten und umsetzen kann. Wie das funktionieren kann und welche Tipps und Tools Christian uns da empfiehlt, hört ihr jetzt in der Folge. Viel Spaß dabei. Hallo Christian, schön, dass du da bist. Hallo, danke, dass ich da sein darf. Ja, sehr schön, hier ist Software Quality Days in Wien. Hast du gute Anreise gehabt? Ja, bin gestern schon angekommen. Geht ja relativ schnell von uns aus mit dem Flieger. Ja, war gut. Das erste Mal in
Wien tatsächlich. Da musst du ja gleich das Wochenende noch da bleiben. Das machen wir wirklich. Wir fliegen erst am Sonntag zurück. Wir sind alle Mann da und bereit und genießen im Anschluss noch ein bisschen Wien. Das ist schön, wenn man das auch miteinander verbinden kann. Ja, ich habe mir ja im Vorfeld so ein bisschen die Agenda angesehen von der Konferenz und dann bin
ich bei deinem Thema hängen geblieben. Thema Security, das ist ja eh jetzt gerade wieder auch in aller Munde, weil es jetzt auch für viele mit Cyber Resilience Act und so auch wieder mehr Bedeutung bekommt und natürlich eh auch ein total wichtiges Thema auch ist. Und da bin ich so hängen geblieben, weil du darüber sprichst in deinem Vortrag oder in deinem Workshop auch, wie kriegt man das in den Entwicklungsprozess rein. Aber hol uns da mal rein mit ins Thema. So, was ist denn
da so heute? Was muss man überhaupt so rechnen, was eigentlich Software so betreffen kann an Sicherheit? Also Software Sicherheit, da ist natürlich an Schwachstellen alles drin, was wir in den letzten zehn Jahren kennen. Also ich mache das jetzt beruflich seit zehn Jahren tatsächlich. Pentesting und Anwendungen kaputt machen und seit zehn Jahren habe ich die Hoffnung,
bald wird alles besser. Dann kam auch der DevOps-Gedanke, dann kam auch DevSecOps mit dazu und immer die Erwartungshaltung, okay, diese Standard-Schwachstellen, das Auslesen von Daten aus der Datenbank, das Kompromittieren von Systemen über das Internet, irgendwann werden wir das los sein, irgendwann wird die nächste Generation das im Griff haben und irgendwann sind wir als Pentester tatsächlich arbeitslos, die am Ende immer mit dem Finger drauf zeigen und sagen, du, du, du, so
könnt ihr Software doch nicht produktiv nehmen, weil das ist ja eigentlich nicht das Ziel. Und tatsächlich mit dem Gedanken DevOps und mit der Automatisierung von diesem ganzen Security Testing,
Software Testing, kann man vieles ja schon vorher machen. Also es gibt ja mittlerweile viele Werkzeuge am Markt, die frei verfügbar sind, die man in die Pipelines einbauen kann, um einfach Security von Anfang an mit in den Prozess reinzubringen und viele Dinge auch schon zu machen, die am Ende jemand mit dem Finger drauf zeigt und sagt, hey, das müsst ihr noch machen. Aber ihr habt jetzt halt irgendwie acht Monate Entwicklung geschlafen und jetzt müsst ihr ganz
vorne wieder ansetzen und müsst euren Code wieder umschreiben. Also das, denke ich, kann man heute besser machen als vor zehn Jahren. Es ist lustig, weil das ist ein Thema, das haben wir bei Performance auch schon gehabt und bei architekturellen Sachen und bei Usability. Da wird am Schluss dann ein bisschen rumgetestet, macht man einen Performance Test, einen Usability Test oder einen Pentest,
oje, jetzt müssen wir wieder alles ändern. Also der Gedanke ist ja eigentlich nicht neu, aber trotzdem tun sich ja viele noch schwer damit, das auch zu integrieren. Tatsächlich, auch wenn man sich hier umguckt, ich bin durch die Stände einmal gelaufen hier auf den Software Quality Days und ich muss sagen, das Thema Security oder das Passwort Security
Testing fehlt da halt einfach. Das ist was, was ich anhand der großen Presseresonanz, die man ja in letzter Zeit auch für Schwachstellen und Angriffe hat, irgendwie nicht ganz nachvollziehen kann. Weil Security ist ja auch nur ein Testfall, also ein Bundle von Testfällen, aber es gehört ja auch mit zum Testing. Lass uns da mal noch ein bisschen reinschauen, weil ich finde das ganz
spannend. Was sind denn heutzutage so die typischen Schwachstellen, die ausgenutzt werden, wenn man so Web-Applikationen, das ist ja glaube ich das Häufigste, was ist da eigentlich gerade so State of the Art, die große Lücke, wo man immer wieder reintappt?
Die große der vielen Tausend. Es hat sich ein bisschen gewandelt im Laufe der Zeit. Früher war das Thema SQL Injections ja ein ganz, ganz großes Thema, wo man eine Datenbank abfragen, als Angreifer eigenen Code einschleißen könnte, die ganze Datenbank auslesen, Passworte überschreiben und und und. Da gab es viel Entwicklung, was Frameworks angeht, die das mittlerweile einfach können. Also wenn man auf Standard Framework setzt in der Entwicklung,
um mit den Datenbanken zu sprechen, dann passiert das einfach nicht mehr. Deshalb sind solche Schwachstellen-Kategorien eher weniger geworden. Was aber tatsächlich zugenommen hat, ist alles so mit Logik und Access Control. Also bestes Beispiel immer, ich logge mich bei meiner Bank ein, will meinen Kontoauszug abrufen, rufe Kontoauszug ID = 1 ab, kriegt es. Was mache ich als Angreifer natürlich? ID = 2, ID = 3, ID = 4 und dann kriege ich die Kontoauszüge von Leuten,
die mich viel mehr interessieren als meine, weil da viel mehr Geld drauf ist. Und das sind tatsächlich momentan so die häufigsten und schwerwiegendsten Lücken, weil diese Standardsachen wie SQL Injection halt über Frameworks viel abgefangen werden. Okay, verstehe. Ich hoffe, dass ja viele Banken sich da auch schon Gedanken darüber gemacht haben, wie sie den Rest auch schon... Banken ist vielleicht ein schlechtes Beispiel.
Aber es betrifft natürlich jeden, der irgendwie was ins Internet auch zur Verfügung stellt und sich einfach auch darum kümmern sollte, was damit passiert. Genau, also tatsächlich jede Anwendung, die irgendwie ein Rollen- und Berechtigungsmodell hat und jede Anwendung, wo man irgendwie nur auf bestimmte Bereiche Zugriff hat, sowohl dieses Durchenumerieren von beispielsweise PDF-Dokumenten, was ich gerade gesagt habe,
aber auch das Thema administrative Funktionen. Ich verstecke Sachen. Wir sind ja in einem Webumfeld, was immer mehr in den Kleindreien geht, immer mehr JavaScript-lastig wird und dann nur noch mit einer API spricht. Und manch Entwickler tendiert dazu, Security-Sachen auch mit vorne ins UI zu legen, was natürlich nicht funktioniert, weil der Angreifer da einfach die API-Anfragen abhängt, manipuliert und so Zugriff auf die Daten kriegt, die er da haben will.
Okay, ja, verstehe. Und trotzdem ist es so, dass so viele Unternehmen, auch einer meiner letzten Kunden, die haben dann auch irgendwann einmal so zum Entwicklungsende hin gesagt, so, jetzt müssen wir ja noch unseren Pen-Test machen, weil den müssen wir machen, ist vorgeschrieben. Das war die Motivation. Dann wird der gemacht und dann endet der natürlich dramatisch, weil Sachen gefunden werden. Und das wollen wir ja jetzt besser machen.
Genau, also wir leben natürlich als Pen-Tester von genau diesem Konstrukt, aber es ist irgendwann nach zehn Berufsjahren auch echt deprimierend, wenn man dann anfängt, irgendwie im Pen-Test am Ende HTTP-Security-Header zu setzen oder das Cross-Site-Scripting in der Suche, die präsent als Hauptseitenmerkmal ist. Das wollen wir besser machen. Das können wir besser machen, weil solche offensichtlichen Dinge finden halt die frei verfügbaren Werkzeuge heutzutage.
Also ich kann ja nicht nur mit statischer Code-Analyse heute Sicherheit in die Anwendungen reinbringen, sondern ich kann ja über die Pipelines auch dynamische Scan-Werkzeuge für die Anwendung reinbauen. Genau das, womit die Angreifer auch arbeiten. Wenn man heute an so einen Bug-Bounty-Hunter, so einen Hacker, so einen Pen-Tester denkt, ist egal an wen, keiner sitzt dann mehr mit einem schwarzen Kapuzen-Hoodie, den ich passenderweise anhabe.
Immer zu Demo-Zwecken heute schon mit Hemd dabei. Aber so sitzt ja keiner mehr im Keller bei Mudi und hackt da irgendwie sich händisch durch, sondern die benutzen ja alle Tools, die automatisieren das, soweit es geht. Und das kann man natürlich schon im Entwicklungsprozess im Deployment in die CI/CD-Pipelines mit reinbauen, klar. Hast du da ein paar Beispiele für uns? Die bekanntesten Beispiele bei der OWASP ist man eigentlich immer ganz gut aufgehoben,
wenn es um so Security-Tools geht. Sehr web-lastig. Aber der OWASP-Zap ist so das frei verfügbare Application-Security-Testing-Programm oder -Tool der Wahl. Das lässt sich auch in eine Pipeline integrieren, das spuckt ein XML-Report aus, HTML-Report. Das lässt sich über API steuern, lässt sich über CLI steuern und geht dann so wie ein Angreifer auch die Anwendung durch, crawlt einmal jede Seite, die er findet, crawlt einmal jeden Parameter, den er findet
und macht dann halt die klassischen Injections. Also wenn man ehrlich ist, hat sich an den Injections ja in den letzten zehn Jahren nicht so viel getan, dass die jetzt so Neuland wären. Ein Cross-Site-Scripting ist immer noch ein Script-Tech mit einem Alert-Datent und einer Injections im einfachsten Fall und eine SQL-Injection startet immer noch häufig mit einem Hochkomma. Das heißt, diese ganzen Patterns geht dann der OWASP-Zap durch für jedes Feld der Anwendung,
sind dann halt ein paar 10.000 Requests, dauert eine Weile, bis das durch ist. Aber dann hat man das schon mal gemacht, was so ein typischer Angreifer auch macht. Und diese ganz normalen Anwendungs-Schwachstellen zumindest in den leicht auffindbaren Bereichen kriegt man damit auch schon gut abgedeckt. Das kann ich natürlich schön auch integrieren. Wie wirkt
sich das auf meine Durchlaufzeit an? Ein Pipeline muss ja schnell sein. Ist das was, was ich immer machen kann oder brauchen die schon recht lang? Wir haben, wenn man das Toolset anschaut, so einen Satz verschiedener Werkzeuge. Also es gibt noch andere Werkzeuge, beispielsweise Nuclay ist so ein Template-basiertes Werkzeug,
was einfach bestimmte Prüfschritte macht. Der ruft aber nur alle Anwendungsseiten einmal auf, ruft den Server einmal auf, prüft sowas wie die Verschlüsselung, die HTTP-Header, zu Basic-Sachen. Das läuft in Minuten durch. Ein Overswap, der muss ja jedes Formular crawlen, jede Seite crawlen, jede Anfrage einmal abschicken mit jeder Payload. Das läuft gerne mal zwischen einer und vier Stunden, je nachdem wie groß die Anwendungen sind. Und da muss man sagen,
das passt in so einen modernen Entwicklungs-Deployment-Pipeline-Zyklus nicht rein. Wenn man nightly deployed, vielleicht noch, aber wenn man irgendwie mehrmals täglich sagt, man möchte das deployen, dann muss man das rausziehen aus der Standard-Deployment-Pipeline. Jetzt ist es so, es gibt ja so Kataloge auch von so typischen Sicherheitsszenarien, also auch quasi hinterlegt. Wie viel kann ich denn jetzt so toolmäßig eigentlich damit auch
abdecken? Also vielleicht sowohl statisch als auch dynamisch. Hast du da so einen Daumen für uns? Was kann ich denn damit so guten Gewissens auch bei mir in die Pipeline einbauen? Ich habe einen Daumen, der geht aber eher so quer. Wenn man mal beispielsweise in den Anforderungskatalog, in den ASVS-Katalog guckt, was der Anforderungskatalog ist, nachdem wir auch Sicherheitsüberprüfungen machen in der Branche in der Regel. Also diese Top 10 ist nett, aber nach
der kann man halt nicht vernünftig prüfen. Wenn man den ASVS-Katalog rannimmt, das sind so 290 Controls. Wenn wir mal dagegen sagen, okay, wir möchten unsere Werkzeuge, Standardkonfiguration, Default, Default, drüber scannen, dynamische Werkzeuge, Sourcecode-Analyse, Tools, nehmen noch einen Dependency-Checker mit dazu, um das Thema Updates und Libraries mit abzudecken und gucken uns das Betriebssystem an. Dann haben wir so vier verschiedene Werkzeugkategorien. Mit denen
kriegen wir einen relativ hohen Anteil abgedeckt. Wenn wir jetzt so Out-of-the-Box-Werkzeuge nehmen, dann würde ich mal sagen, so irgendwas zwischen 60 und 80 der Anforderungen, können wir mit einem OWASP-SAP dynamisch prüfen. Die statische Code-Analyse ist ein bisschen besser. Wir haben dann aber halt immer noch einen Gap. Aber es hält ja niemand jemand davon ab, wenn er eh schon Unit Tests oder Testfälle schreibt oder wie auch immer er das macht, dann dort auch noch Security-Tests
mitzumachen. Einfachstes Beispiel sage ich immer, ich möchte wissen, ob eine gültige E-Mail-Adresse eingegeben wird. Da gibt es ein RFC dazu und das kann natürlich auch einen OWASP-SAP testen, aber das kann ich auch als Entwickler testen. Wenn ich eine E-Mail-Eingabe fällt habe und die Eingabe ist auf einmal 400 MB groß, dann möchte ich das vielleicht sicher verwerfen,
Fehlerhandling drauf machen und das als Testfall mitgeben. Das geht ja auch noch. Wenn man das alles zusammen nimmt, dann hat man schon eine sehr, sehr gute Abdeckung, aber dann gehört tatsächlich auch Hirnschmalz mit dazu. Dann kann man nicht mehr Tools von der Stange nehmen, Clicky-Bunty starten. Da muss man sich Gedanken dazu machen und schauen, was können die tatsächlich abdecken, was muss ich an Testfällen selber schreiben. Ich verstehe. Gut, aber man kann ja
auch mit den Standard-Tools beginnen. Das ist ja, glaube ich, vielleicht schon für viele der erste Schritt. Warum tun sich denn so viele Unternehmen schwer damit, dass sie lieber dann quasi am Schluss so einen Pen-Test bezahlen und den machen und sich das nicht in den Entwicklungsprozess holen? Also aus der Erfahrung heraus kann ich sagen, da gibt es verschiedene Gründe. Meistens ist es, in den Unternehmen steht jemand in der Tür in einem Meetingraum und hat einen Hut in der Hand
und will den auf irgendjemanden werfen, der ab dann Security machen soll. Und natürlich, wie überall, ist der Entwicklungsabteilung keiner aus dem Betrieb, hat irgendwie Langeweile und alle versuchen sich wegzuducken und zu sagen Security, das macht doch die Abteilung da oben. Wenn wir in Projekten sind, das meiste, also technisch die Implementierung zu machen von so einer dynamischen Testing-Suite, man braucht natürlich die Tools und, und, und. Aber das hat man in anderthalb
Tagen aufgesetzt. Das ist ja kein Hexenwerk. Viel, viel mehr ist einfach, wer macht's, wer betreut's, wer ist denn jetzt auf einmal der Benannte, der den Hut gefangen hat, der sich mit Security-Themen auskennt. Macht das jedes Team für sich oder macht's nicht Sinn, so Themen einfach zu bündeln, wenn man mehrere Dev-Teams hat, um zu sagen,
die Security-Tools steuern wir zentral. Aber dann sind wir ganz schnell in Rollen, Verantwortlichkeiten, Zeiten und, und, und typischen organisatorischen politischen Machtkämpfe. Wer macht jetzt was? Und das ist tatsächlich das, woran es dann am ehesten meistens knausert, weil keiner sich hinsetzt und sagt, ich nehme mir das Thema an und ich finde das Thema cool und ich bringe es ins Unternehmen, sondern sage, ich habe genug zu tun.
Was traurig ist, weil am Ende des Tages natürlich, wenn dann der Pentast am Ende kommt, den sie machen müssen, weil irgendjemand sagt, ihr müsst, dann ist halt wirklich auch richtig Arbeit da. Das hätte man schon früher vermeiden können. Aber es ist halt einfach gefühlt, alle sind an der Belastungsgrenze und keiner will einen zusätzlichen Hut. Und es ist ja auch nicht, wessen Thema ist Security in der Entwicklung? Wen findet man denn, der das Know-how dafür hat,
der die Tools kennt? Darum sind wir auf so Veranstaltungen und versuchen das den entsprechenden Leuten näher zu bringen. Aber man muss sie halt im Unternehmen finden. Wie hoch ist denn der Einarbeitungsaufwand? Es gibt ja diese Tools, die sind ja dann auch schon zum Teil fertig, die vielleicht Open Source sogar, die kann ich irgendwie integrieren. Was brauche ich denn wirklich an Background, um das jetzt umsetzen zu können? Muss ich da rein
und ein halbes Jahr mich da eingraben in diese Dinge? Oder wie schnell kriege ich so was immer ins Laufen, auch in meiner Pipeline? Das ist tatsächlich die Angst meistens davor, zu sagen, oh, das ist so kompliziert und das ist Neuland und das kann ich nicht. Und man kann das auch kompliziert machen, natürlich. Man kann jedes Thema beliebig kompliziert machen. Das schafft man gerade in der Softwareindustrie gut,
wenn man alles kompliziert macht. Acht Monate pro Projekt, wir führen irgendwie Security ein. Nee, aber wenn man startet, man hat ein Tool, man kriegt ein Ergebnis. Das Ergebnis muss man in ein Jira-Ticket pumpen oder wo auch immer rein. Und der Entwickler muss es sich angucken. Die Tools liefern Texte mit. Also, Oberst Sepp liefert einen Text, was ist passiert, die Beschreibung dazu, wie kann ich es beheben, an welchen Parameter, wenn es irgendwelche Injections
sind. Also, man kriegt diese Informationen alle. Ich glaube, viele trauen sich einfach nicht zu starten. Das ist auch das, wo wir mal hingehen und sagen, hey, fang doch mal an. Nehmt doch mal ein einfaches Werkzeug. Dann nehmt ihr halt nicht Sepp mit dazu, sondern dann nehmt ihr Nuclei und ein
paar Templates und guckt erst mal nach den Headern, nach der TLS-Konfiguration. Einfache Dinge. Es muss ja nicht gleich das perfekte Mittel sein und ihr wollt ja nicht am Ende des Tages eine 1+ mit Sternchen, wenn Security kommt, sondern ihr wollt ja einfach nur kein blaues Auge haben. Und das ist ja schon mal ein guter Start. Ja, also, ist gut. Da kann man ja einfach eigentlich leichtgewichtig auch starten. Also, das ist natürlich schon gut. Und ich glaube,
das ist aber auch mit ein Thema. Bei Security wie bei vielen anderen, das ist so eine abstrakte Gefahr. Das sagt ja keiner, dass das wirklich passiert. Und vielleicht erlebt man es auch gar nicht mehr mit, wenn das eigene Produkt vielleicht mal gehackt wird oder so. Also, ich glaube, da ist einfach auch, das können sich viele konkret gar nicht vorstellen, was da für Auswirkungen auch sind oder nehmen das nicht das konkrete Gefahr auch mit wahr.
Manchmal ist es tatsächlich auch die Vorstellung, die einfach fehlt, was ein Angreifer machen kann. Also, wir haben gerade im Web-Bereich auch Entwickler in Schulungen, die sitzen, wieso? Wir haben doch einen Dropdown definiert. Was anderes kann der Angreifer da doch gar nicht eingeben? Also, so Grundlagen, wo einfach fehlt, hey, der Angreifer hat ein Proxy, der kann da eingeben, was er will. Der kann auch rechtsklick machen und im Source Code editieren.
Das, was ihr da hinpackt, das interessiert einen Angreifer tatsächlich nicht. Also, auch solche Punkte, da stolpert man manchmal drüber. Da geht es aber dann eher tatsächlich um dieses Security-Wissen und dieses Gefühl, diesen Angreifer-Gedanken, einfach mal den schwarzen Hoodie anzuziehen. Man nennt das Mob-Hacking in dem Bereich. Und einfach mal sich hinzusetzen mit dem Team und zu sagen, komm, wir nehmen uns mal so ein Angreifer-Werkzeug, wir schicken das
mal drüber und wir gucken mal, wie sich ein Angreifer so eine Anwendung kriegt. Das kann schon sehr viel für Erleuchtung sorgen tatsächlich. Jetzt werden ja gerade in der Webentwicklung ja auch häufig Frameworks verwendet, React, Angular und so Konsorten. Wie weit helfen die denn einen schon per se von bei Design auch da mehr Security zu leben oder ist das da ausgeklammert? Das kommt auf die Kategorie der Schwachstellen an. SQL-Indexation habe ich ja schon genannt
als Beispiel. Das haben die Frameworks ganz gut im Griff. Auch Cross-Site-Scripting, was ja so das zweite große Lieblingsthema immer ist, was kommt, können viele Frameworks rausfiltern, weil sie die Ausgaben entsprechend enkodieren. Aber man wäre ja nicht flexibel als Framework, wenn man dem Entwickler nicht die Möglichkeit gibt, sich selbst ins Knie zu schießen
und diese Features wieder auszustellen. Also wir haben tatsächlich teilweise auch Frameworks, die eigentlich Encoding machen, wo aber dann irgendwas auf der Webseite komisch aussah und dann wird das Encoding wieder ausgestellt und dann hat man den Salat wieder. Aber grundsätzlich diese klassischen Injection-Schwachstellen kriegen die Frameworks gut hin. Das ganze Thema Autorisierung und Rollenmodelle natürlich nicht, weil das liegt bei demjenigen, der das
definiert und wer da welche Berechtigungen hat und dass die geprüft werden. Da helfen die Frameworks in der Regel nicht so viel, weshalb das auch momentan immer mit zu den kritischsten Sachen sind, die man findet. Ich verstehe. Es gibt ja jetzt, also Web ist ja immer so, da konzentriert sich das Security-Thema sehr häufig darauf. Aber wir haben natürlich auch noch, sagen wir mal, aus der Historie her ganz viele ganz normale Client-Anwendungen,
Desktop-Anwendungen unter Windows zum Beispiel. Oder auf der anderen Seite auch jetzt eigene Mobile-Apps oder so. Wie sieht es denn da aus? Also ist das ein Thema? Sollte man sich da auch kümmern? Und wenn ja, gibt es da auch ähnliche Tools? Also eine Frage ist ja… Wenn ich jetzt sage, man sollte sich um Security nicht kümmern und dann… Das ist eine rhetorische Frage.
…kriege ich ein Problem. Nein. Die Frage ist ja risikoorientiert, was kann passieren, wenn ich eine Desktop-Client auf einem Windows-Rechner habe und die ist Security-technisch kritze, dann ist mir das ja so lange egal, bis sie irgendwo Daten hinspeichert oder verarbeitet. Da reden wir heute bei allen Anwendungen, die gefühlt nach meiner Geburt geschrieben wurden, über irgendwas, was per HTTP ins Backend kommuniziert. Natürlich gibt es auch noch
ein paar andere, aber man hat ja immer irgendwo am Ende eine Kommunikation. Sonst ist mir die Anwendung Security-technisch egal. Wenn der Calculator-Echse auf dem Windows-Client eine Schwachstelle hat, so what? Da geht die Welt nicht von unter. Aber wir haben ja irgendwo immer eine Kommunikation, es werden irgendwo Daten übermittelt. Auch eine Mobile-App ist im Grunde genommen ja mittlerweile in der Regel so entwickelt, dass es ein Frontend hat,
was auf beide großen mobile Endgeräte ausgespielt werden kann. Und die Datenverarbeitung findet irgendwo auf dem Server statt. Da gibt es dann halt API-Calls statt klassischer Post-Aufrufe mit Wert und Parameter. Aber auch da sind wir schon wieder in der Web-Welt. Die APIs haben ein paar Besonderheiten. Wir haben halt ein paar andere Prüfpunkte, aber grundsätzlich kann man mit den Werkzeugen, die es auch im Markt gibt, sowohl APIs als auch normale Web-Anwendungen
testen in den Mobile-Apps. Ja, Mobile-Apps speichern auch noch Daten auf dem Gerät und und und, verschleiern vom Bildschirm. Also die Banken wieder als Beispiel zu nehmen. Wenn du jetzt eine Banking-App in den Hintergrund schiebst, dann wird der Bildschirm so ausgeblurrt, dass man
die Zahlen nicht sieht. So ein paar Sachen kommen noch dazu an Security-Maßnahmen, aber vielfach sind wir heute tatsächlich irgendwo in der Kommunikation, irgendwo werden Daten ins Backend geschoben und da brauchen wir dann auch Eingabevalidierung und und und, weil da passiert am Ende der Schaden. Also wenn ich mir in meiner Handy-App selber schaden möchte, kann ich das machen. Aber wenn ich den Kontostand ändern will, dann brauche ich eine Kommunikation zum Server.
Ja, also lokal kann ich den Kontostand auch ändern. Da freue ich mich, vielleicht kann ich mir das affimieren und manifestieren, wie viele Millionen ich da habe. Aber es macht dann den echten
Kontostand auch nicht so, ne? Leider. Jetzt ist es ja so, ich habe irgendwie vor vielen Jahren von einem weisen Security-Tester mal geredet, dass Security-Testing ja ganz viel damit agiert, mit Dingen, die einfach ja nicht definiert sind, sondern eher in diesem anderen Bereich, dort wo man es in der Anforderung oftmals nicht hinschaut und dann eben dort dann auch die Lücken sucht. Jetzt ist OWASP oder so etwas, State of the Art, hat jetzt 290 Anforderungen da drinnen.
Wie entwickelt sich denn das weiter? Also ich denke, da ist ja eine eine Herrscher an Hackern im Dark Web unterwegs und sucht nur irgendwie neue Lücken und Möglichkeiten. Wie synchronisiert sich das und wie State of the Art ist man mit so einem Framework wie OWASP bei euch? Die OWASP sind Sprach- und Betriebssystemen und Datenbankmanagementsystemen unabhängig, weit es geht. Natürlich gibt es im Detail Angriffe, die funktionieren nur auf Linux,
Angriffe, die funktionieren nur auf Windows. Ich kann auf einem Linux keine ECC-Passwerte einbinden bei der Remote File Inclusion. Ja, solche Spezifika gibt es natürlich, die sind aber in der OWASP in den Prüflisten nicht drin. Da reden wir dann nur über Local File Inclusion oder über Remote Code Execution als Schwachstellenkategorie. Die sind wiederum ziemlich statisch über alle Neuentwicklungen. Wenn ich natürlich sowas wie Docker und Kubernetes
habe, dann habe ich wieder ein bisschen Bewegung drin. Aber wenn ich jetzt von einem Debian auf einen Red Hat wechsel oder auf einen iX wechsel oder von einem Windows 10 auf einen Server 2022, dann ändert das die Angriffsvektoren und die Schwachstellen nicht. Es gibt halt nur mal eine Müh, andere Wege das auszunutzen. Aber da ist die OWASP eigentlich immer relativ gut auf
dem Stand, um da die entsprechenden Hinweise zu liefern. Wir haben natürlich auch noch die SANS CWE-Liste, die dann auch aus dem Web rausgeht, wo man dann auch noch Sachen findet, die nicht webspezifisch sind, wie es bei der OWASP ja fast überall der Fall ist. Die hilft dann auch noch mal weiter. Aber auch da, es gibt so alle vier, fünf Jahre, gibt es mal so eine
Neuauflage von den Top 10 oder Top 20 bei der CWE. Da verschiebt man mal Sachen, aber es ist jetzt nicht, dass irgendwie großartig tatsächlich für die Security-Mechanismen da neue Dinge dazukommen. KI, um es einmal angesprochen zu haben, natürlich ist so ein Thema. Wir hatten letzte Woche tatsächlich auch mal so einen KI-Generator. Da liest man ja auch immer mal wieder, dass die Einschränkungen umgangen werden können, dass irgendwie die DRN dann dazu genutzt werden kann, im Kontext von der
Firma was auszuführen. Das sind natürlich schon noch mal Dinge, die hat man in so einer klassischen Top 10 nicht drin, weil das ist einfach ein Stück weit andere Technologie, anderer Mechanismus. Das zieht nach, aber da gibt es ja Vorträge wie "Sand am Meer" zum Thema Absicherung von solchen KI-Chatbots und Co. Da ist dann tatsächlich aber die Community und die Security-Experten manchmal vor der OWASP
dran. Wir wüssten zumindest gerade nicht, dass da schon irgendwas finalspruchreich ist von Seiten der OWASP. Da fällt mir eine Sache ein, die ich gerade erst letzte Woche gehört habe, das fand ich total spannend. Und zwar, es gibt ja jetzt auch ganz viel Verschlüsselung, ja heute schon, aber dass es quasi auch ein Angriff oder ein Szenario ist, heute schon Daten abzugreifen, diese verschlüsselten Daten, auch wenn ich die noch nicht entschlüsseln kann, aber wenn ich dann
einen Quantencomputer habe und dann mache ich das alles auf und komme an alle Geheimnisse ran. Was hast du dich damit beschäftigt auch? Oder ist das ein Thema oder ist das gerade so ein abstrakter Gedanke auch? Also mit Quantencomputing habe ich mich tatsächlich wenig beschäftigt. Das ist wie so ein Schleier, seit dem Studium schwebt der immer da und man hört immer "Bald ist es soweit,
bald könnt ihr eure RSA-Krypto in die Tonne treten und bald werden wir alles entschlüsseln." Der Gedanke ist natürlich nicht blöd, auch wenn wir heute über Transportverschlüsselung reden, also über TLS im Normalfall reden, die Algorithmen, da schwebt dieses Damoklesschwert natürlich auch drüber, dass irgendwann mit der Quantenkryptografie die Sitzungen entschlüsselt werden können. Auf
der anderen Seite, was sollen wir da gerade dagegen machen? Also wenn wir Security Audits machen, wir empfehlen halt auch noch die aktuelle TLS-Version mit aktuellen Ciphers, mit Wegwerfschlüsseln, also diese Ephemeral Cipher Suits, dass nicht immer der gleiche Sitzungsschlüssel verwendet
wird, um es den Angreifern zumindest ein bisschen schwerer zu machen. Aber klar, wenn ich heute was aufzeichne und in 50 Jahren ist es mit einem Fingerschnipps "decrypted", dann kann ich nur hoffen, dass in 50 Jahren die Daten keinen Wert mehr haben,
die man heute "decrypted" hat. Interessanter Gedanke. Wenn jetzt ein Team, was jetzt gerade zuhört, die merken, okay, wir machen immer so unseren Pantest, haben jetzt schlechtes Gewissen auch, dass das immer so ad hoc passiert, wo würdest du denn sagen oder einen Tipp geben, da könnt ihr mal anfangen, da legt mal los, das guckt euch mal zuerst an?
Die meisten legen ja schon los. Also wenn man die Leute fragt, macht ihr statische Code-Analyse, dann machen alle, ja, ja, klar, natürlich machen wir das, wir haben ja einen Linter in der RGE, der nutzt uns jetzt nicht so viel Security-technisch, aber habt ihr irgendwie einen Scanner drin? Ja, haben wir. Da fällt auch immer ein Produktname ganz klassisch mit als erstes,
der macht auch Security, das ist schon da. Security wird schon gemacht, man hat da Quality Gates definiert, man hat halt dann 4000 Befunde, die da rauskommen, die sich keiner angeguckt hat, weil keiner Lust hat, sich damit zu beschäftigen, aber es ist ja grundsätzlich schon da und auch sowas wie einen Dependency-Check, also welche Laber-Libraries habe ich da, auch eine gute Variante, welche JavaScript-Libraries habe ich da drin oder welche Java-Libraries habe ich da
drin, sind die veraltet, haben die Schwachstellen, ist in den meisten Pipelines ja schon drin,
also es gibt ja schon Security. Der nächste Schritt ist dann, sich zu trauen, zu sagen, ok, wenn die Anwendung deployed ist, wenn ich normale Testfälle drauf spiele, wenn ich meine Selenium-Tests abarbeite, dann mache ich einfach mal Edge-Case-Tests mit, dann lasse ich mal ein Security-Tool, eine Nuclea, einen Overstep mitlaufen oder lass den separat mal laufen, setz den mal auf, guck mal, was da an Ergebnissen bei rauskommt und spiel das dann entsprechend in
die Gruppe der Entwickler ins Team zurück und setz dich mal hin, guck dich das mal an, man muss es ja nicht gleich als Fail-Kriterium in die Pipeline zwei Wochen vorm Go-Live machen, das unterminiert im Normalfall so ein bisschen die Akzeptanz des Ganzen, sondern man kann sich dem ja mal nähern, ohne dass man das direkt gleich knallhart macht und ausgehend von sowas wie einem
Source-Code-Scanner und einem Dependency-Scanner hat man ja schon was da. Eine abschließende Frage habe ich noch, wenn du jetzt, also du hast ja, siehst du ja sicher auch Teams, die das in ihren Entwicklungsprozess mit integrieren, die das machen und dann noch einen Pen-Test machen, den du vielleicht begleitest oder sowas, wie wirkt sich das denn aus? Hast du da so irgendwie eine Zahl für uns, was dann wirklich so weniger an Findings ist im Pen-Test?
Wenn man mal andersrum anfängt und ich für meine lieben Kollegen Pen-Tester da draußen weltweit, die alle Dokumentation und Schreiben hassen, sprechen darf, wir haben ja in so einem Pen-Test, lass uns einen 60-Seiten-Report nehmen, weil die Anwendung nie vorher Security gecheckt wurde, dann sind von diesen 60 Seiten 45 Seiten irgendwelche HTTP-Header, irgendwelche Fehlkonfigurationen, irgendwelche Dinge, die muss man halt einfach machen, das ist aber viel
Härtung, viel Standardgedöns, da brauchst du nicht mal einen Obersp-Zap für, da reicht dir der Nuclei dafür, der dir da einfach diese Dinge rauszieht. Das hast du weg. Wir haben bei uns auch alles durchautomatisiert, diese Scans und wir haben alle Befunde in der Datenbank dokumentiert, das heißt, wir wissen von allen Pen-Tests, die wir in den letzten sechs Monaten gemacht haben,
was sind so die häufigsten Findings. Mal auf 100 Tests gesehen, haben wir einmal SQL-Injection, 30-mal bis 40-mal Cross-Site-Scripting, aber fast in 100% der Fälle irgendwelche Cypher-Suites, die nicht korrekt sind, irgendwelche Header, die nicht korrekt gesetzt sind, irgendwelche Debugging-Flags, irgendwelche Entwickler-statischen Files, die da sind und,
und, und, und, und. Wenn wir mal wieder an unsere 60-Seiten-Report denken, die tatsächlich spannenden Sachen, die nur ein Pen-Tester finden kann, also irgendwelche wirklich versteckten Sachen, irgendwelche Dinge, die über mehrere Formularfelder hinweggehen, dann reduzieren wir den Report auf
vielleicht vier bis fünf Seiten. Und dann kriege ich halt vier bis fünf Seiten, der Pen-Test kostet weniger, der Entwickler muss am Ende weniger lesen, der Pen-Tester ist glücklich, weil er nicht 45 Seiten mit irgendwelchen Blabla schreiben muss und ich weiß halt sofort, auf was ich mich konzentrieren muss und habe dann die zwei Issues im JIRA und nicht irgendwie 30 Issues mit Headern.
Also wenn das kein Grund ist, also muss ja jeder schon machen, dass er das in den Entwicklungsprozess integriert. Auf jeden Fall. Und wenn nicht der Technik zuliebe, dann den Menschen zuliebe, die sonst das jedes Mal wieder dokumentieren müssen. Genau, genau. Super. Christian, vielen lieben Dank für diese Einsichten. Das war ganz spannend,
auch habe auch viel gelernt für mich, das finde ich immer ganz toll. Ich wünsche dir noch ganz viel Spaß hier auf der Konferenz bei den Software Quality Days und ganz viel Spaß bei deinem Vortrag dann auch. Danke schön. Und alles Gute. Vielen Dank. Alles Gute. Danke. [Musik]