Welche Inhalte werden in dem Workshop vermittelt? Welche Erfahrungen macht man, wenn man sich mit Secruity für Web APIs beschäftigt und welche Besonderheiten liegen gerade bei Security für Web APIs vor? Diese Fragen klärt Niko Köbler (www.n-k.de) im Interview auf dem API Summit 2017 in Berlin.
Mirko Hillert: Du hast gestern einen Workshop zum Thema Securityauthentifizierung und -autorisierung für Microservices und Web-APIs gehalten. Welche Inhalte hast du den Teilnehmern deines Workshops vermittelt?
Niko Köbler: Natürlich habe ich zunächst erst einmal die Sinne für das Thema Sicherheit bei den Anwendern geschärft, da dies meistens noch schmerzlich vernachlässigt wird. Programmierer und Entwickler wollen sich wenig mit dem Thema Sicherheit auseinandersetzen, da es gefühlt immer ein diffiziles Thema ist. Da kann ich viel falsch machen, indem ich irgendwelche Sicherheitslöcher aufmache, sodass Angreifer ins System können. Deshalb herrscht bei vielen Entwicklern noch der Gedanke: „Ich mache nichts. Dann kann ich auch nichts falsch machen.“, was natürlich auch nicht zielführend ist. Von der Technologie sind wir momentan so weit, dass es einfacher wird, sichere Anwendungen zu bauen und sie auch zu pflegen. Wir entwickeln uns schließlich alle weiter, und so tut es auch die Technologie. Im Bereich verteilte Anwendungen, gerade bei Web-APIs und Microservices, habe ich mit verteilten Systemen immer wieder zu tun und brauche aktuelle Technologien. Diese brauche ich, um meine Authentifizierungs- und Autorisierungsinformationen, wer also der Anwender ist und was er darf, bequem zwischen den Anwendungen transportieren zu können. Dabei spielt das Thema Token eine große Rolle. Token ist kein neues Thema. Das hatten wir schon vor fünfzehn Jahren mit einem SAML Token und es hat gefühlt noch nie jemandem Spaß gemacht. SAML gibt es heute immer noch und ist auch noch eine super Technologie, aber es ist schwer, im Web damit umzugehen. SAML basiert nämlich auf XML, XML-Handling mit JavaScript, Webtechnologien – ist auch immer schwer, das zu hantieren. Deshalb haben sich vor ein paar Jahren die Standards OAuth, OAuth2, OpenID Connect und JSON Web Token entwickelt, die gerade im Mobile-Umfeld für mobile Anwendungen und im JavaScript-Umfeld, wenn man eine Single-Page Application hat, sehr gut dazu geeignet, Sicherheit zu transportieren und das abzubilden. Dazu habe ich in meinem Workshop praktische Beispiele behandelt. Wir haben zudem ein komplettes Webshopbeispiel durchgearbeitet, das wir von „komplett unsicher“ komplett abgesichert haben, bis in die Backend-Services rein. Wir haben Tokens propagiert – von dem Benutzer bis in Backend-Services und damit rumgespielt.
Mirko Hillert: Du bist viel in Kundenprojekten unterwegs. Wie sind deine Erfahrungen, wenn es um das Thema Security geht?
Niko Köbler: Meistens werde ich gerufen, wenn es zu spät ist. Mich erwartet meistens Folgendes: „Wir sind einen Monat vor dem Livegang und wir brauchen noch eine Log-in-Maske.“ Dann muss ich dem Kunden erstmal vermitteln: „Nur eine Log-in-Maske, wenn ich ein verteiltes System habe – das ist heute nicht mehr!“ Ich muss die Informationen irgendwie transportieren. Den Benutzernamen und das Passwort speichern und weitergeben ist schließlich höchst unsicher. Single Sign-on heißt, ich melde mich in nur genau einem System an, und nur dieses eine System, also das Single in Single Sign-On, kennt meine Benutzerdaten. Das muss dann meine Informationen weiterleiten. Ganz oft sehe ich dann, wie unverschlüsselte Passwörter irgendwie zwischengespeichert und hintenherum weitergereicht werden. Das sind No-Gos im Bereich Sicherheit. Das macht man nicht. Security ist eine nicht funktionale Anforderung in Softwareprojekten, die von Anfang an in der Architektur mitbedacht werden muss. Das führt dann meistens dazu, dass ich Kunden sagen muss, dass sie ihren Livegang verschieben müssen. In einem Monat werden sie das nämlich nicht schaffen. Das muss erstmal richtig implementiert werden, sodass sie dann erst in einem Monat plus x live sind. Das ist natürlich ziemlich schmerzhaft, da es nun ein wenig länger dauert. Hätten sie es jedoch von Anfang an richtig gemacht, hätten sie diese Schmerzen nicht gehabt. Aber wie heißt es so schön: „Wer nicht hören will, der muss fühlen.“
Mirko Hillert: Gibt es beim Thema Security Besonderheiten hinsichtlich Web-APIs?
Niko Köbler: Die gibt es sicherlich. Lustigerweise sind das ganz rudimentäre Features, die man beachten sollte. Das fängt bei „kommunizieren nicht über Plain HTTP miteinander“ an, da es nämlich sensitive Informationen sind, die es zu schützen gilt. Diese über ein offenes Protokoll wie HTTP zu vermitteln, das zudem auch jeder einsehen kann, ist unsicher. Deswegen sollte heutzutage nur noch über HTTPS kommuniziert werden. Das klingt einleuchtend, wenn man darüber redet. Dennoch sehe ich in den Projekten noch immer, dass es so gemacht wird. Das habe ich auch im Workshop erlebt. Ich habe davon erzählt und die Teilnehmer nickten. Danach habe ich gefragt, wer denn ausschließlich HTTPS mache, und es gingen nur ungefähr 20 Prozent der Arme hoch. Der Rest macht halt noch immer HTTP, weil es natürlich einfacher ist. Aber Sicherheit und Einfachheit schließen sich natürlich immer ein wenig gegenseitig aus. Entscheide dich für eins! Genau das sind diese rudimentären Dinge. Auch wenn ich eine Webanwendung habe, die ich absichern möchte und ich mit einer Cookie-basierten Authentifizierung arbeite, dann spielen auch Dinge wie Cross-Site Request Forgery (CSRF) eine Rolle, sodass fremder Code in meine Anwendung eingeschleust werden kann. Das sind alles Dinge, denen unglaublich leicht entgegengewirkt werden kann – man muss es einfach nur tun. Und genau diese Dinge werden einfach zu oft vernachlässigt.
Mirko Hillert: Ich bedanke mich für das Interview.
Interviewt von: Mirko Hillert
Mirko Hillert verantwortet seit 2007 als Leiter der Entwickler Akademie den Trainingsbereich bei Software & Support Media. Er studierte Betriebswirtschaft an der Westsächsischen Hochschule Zwickau und der Universidad Valencia sowie Marketing an der Westfälischen Wilhelms-Universität Münster. Als ehemaliger Dozent und Ausbilder für Managementprozesse treibt er seit vielen Jahren die fundierte Aus- und Weiterbildung von Entwicklern und Softwarearchitekten im IT-Markt voran, unter anderem mit innovativen Eventformaten und hochwertigen Trainingsinhalten.
