Sicherheit von IT-Systemen

Willem van Kerkhof: Ja, hallo Stefan. Wie schon gesagt, ich bin Willem van Kerkhof, bin für die innoQ tätig seit mittlerweile glaube ich bald sechs Jahren. Fünf, sechs Jahren. Ich bewege mich im Web-Applikationsumfeld, Ruby on Rails hauptsächlich. Und ja privat beschäftige ich mich immer mal wieder gerne mit Themen, die technik- und sicherheitsrelevant sind und so ein bisschen alles was mit Sicherheitsproblemen, die große Projekte – wie sie heutzutage immer wieder losgetreten werden, ohne lange nachzudenken – die damit im Zusammenhang stehen.

Stefan Tilkov: Genau. Immer wenn wir jemanden brauchen, der besonders paranoid ist, dann fragen wir dich. Das ist deine Rolle.

Willem van Kerkhof: Genau. Aber ich habe keine Ahnung von all diesen Themen, deswegen…

Stefan Tilkov: … wird das ganz schnell vorbei sein, unser Gespräch.

Willem van Kerkhof: Genau. Gesunde Paranoia bewahrt einen vor vielem.

Stefan Tilkov: Als wir überlegt haben, worüber wir so reden, habe ich gesagt: „Lass uns doch über ein paar technische Themen reden.“ und du hast gesagt: „Nee, machen wir nicht.“ Warum willst du nicht über Technik reden, wenn wir über Security sprechen? Also wir tun das vielleicht später noch, aber wieso muss ich dich erst dazu überreden?

Willem van Kerkhof: Haah, Technik ist doof. Nein, Technik macht alles komplizierter. Ich denke wir haben, wenn wir über das Thema Security reden, dann ist das erstmal ein Thema, welches a priori nicht technisch ist. Wir reden da über Themen wie „Wer darf was in meinem System?“, „Wie sorge ich dafür, dass keiner mir meine Sachen kaputt macht, meine Daten klaut?“ usw. Und das hat erstmal damit zu tun, „Wer darf überhaupt was?“, „Wem vertraue ich was an?“ und „Wie lege ich in einem Unternehmen auch fest, welche Daten von welcher Organisationseinheit sind überhaupt relevant für andere Organisationseinheiten?“ usw. Und da hat die Technik erstmal nichts mit zu tun.

Stefan Tilkov: Was du meinst ist, dass man sich zunächst einmal überlegt, ob man überhaupt für irgendwas ein System zur Verfügung stellt und wem, bevor man dann darüber diskutiert, wie man es konkret absichert.

Willem van Kerkhof: Wir Menschen sind überhaupt noch nicht dazu in der Lage – ob das jetzt ein evolutionäre Problem ist oder nicht, weiß ich nicht – mit den Sicherheitsproblemen umzugehen, die uns diese Wolke von Technologie bietet. Wir hacken da irgendwas in unsere Systeme rein und irgendwas passiert damit, aber wir verstehen die Systeme nicht. Also der normale Benutzer weiß überhaupt nicht, was in diesesm System überhaupt funktioniert und er weiß auch nicht, wie er diesem System vertrauen soll, weil wenn er nicht versteht, was da passiert, kann er auch nicht absehen, was die Folgen von seinem Handeln sind. Und deswegen denke ich, bevor wir über das Thema „Technische Absicherung von Systemen“ reden, sollten wir erstmal darüber reden, wie bringen wir unseren Benutzern z.B. bei, zu verstehen, ja was sie da eigentlich tun. Hast du schon mal einem Benutzer zugeguckt, wie er sein SAP-System bedient oder so? Von dem kann man z.B. noch nicht einmal erwartet, dass er versteht, was es dann für Konsequenzen auf größerer Ebene hat, wenn wir sagen „Log dich mal eben auf meinem System mit meinem Passwort ein.“ Der sieht nicht, was die Konsequenzen davon sind, wenn er plötzlich im Namen eines anderen Benutzers etwas ins SAP-System einträgt. Da sitzen vielleicht ganze Workflows hinter, der tritt vielleicht ganze Prozesse los im Namen eines anderen Benutzers. Ich sag mal, im System steht dann „Benutzer X hat irgendwas frei gegeben“ – hat er gar nicht getan, der weiß gar nichts davon. Nur weil da irgendeiner sein Passwort weiter gegeben hat, was gar nicht böse Absicht war.

Stefan Tilkov: Ja. Was absolut gang und gäbe ist. Ich kenne ganze Abteilungen, wo es völlig üblich ist, dass die ganze Abteilung mit einer User-ID arbeitet, obwohl jeder in der Abteilung eine eigene User-ID hat, aus dem einfachen Grund – aber das ist ein interessanter Querbezug – weil die Sicherheitsanforderung nicht zu der Art und Weise passen, wie dort gearbeitet werden muss. Also das Beispiel, was ich kenne, ist bei einem Retailer, wo Kassen sind und bei den Kassen ist immer irgendjemand angemeldet. Und eigentlich müsste man sich an den Kassen immer abmelden und wieder anmelden, aber das tut man natürlich nicht, weil als aller höchste Priorität möchte man schnell den Kunden bedienen.

Willem van Kerkhof: Richtig.

Stefan Tilkov: Das bedeutet vielleicht, dass man eine andere Security-Lösung braucht, weil als aller wichtigste ist, dass die auch aktzeptiert wird, denn sonst hat man nur eine Scheinsicherheit.

Willem van Kerkhof: Natürlich. Verständnis für das System geht natürlich in beide Richtungen. Also diejenigen, die ein solchen System bauen, sollten auch erstmal komplett verstehen, was eigentlich die fachlichen Anforderungen sind. Also das ist dann nicht mehr nur Security-relevant, sondern betrifft die komplette Architektur und Applikationsentwicklung. Man sollte wissen, wie die Leute arbeiten und die Leute arbeiten aber grundsätzlich nicht so, wie es quasi ein IT-System vorgibt, sondern wir arbeiten komplett anders. Wir arbeiten, mit Dokumenten zum Beispiel. Also ich merke das in meinem aktuellen Projekt z.B., das ist inherent Dokument-getrieben. Bei jeder Übergabe fallen irgendwelche Dokumente an, aber man übergibt das Dokument, man übergibt nicht den Prozess. Aus unserer Sicht reden wir davon, wie so ein Dokument generiert wird beim Übergang eines Prozessschrittes. Wir machen eine Freigabe und dabei wird ein Dokument generiert. Früher war die Freigabe die Unterschrift auf dem Dokument. Und jetzt bringt mal einem Benutzer bei, dass wenn er sich einloggt als wer anders und dann die Prozessfreigabe macht, dass dann implizit dokumentiert wird, dass der andere den Prozess freigegeben hat. Das kann im einfachsten Fall einfach eine Unklarheit sein, aber im extremen Fall – reden wir mal von sicherheitsinfrastrukturellen Sachen, irgendwie in größeren Projektumfelder, in größeren Firmen – das kann auch nicht absehbare Folgen haben. Das muss man dann auch wiederum prozesstechnisch abdecken, mit dem Vier-Augen-Prinzip oder solchen Sachen. Man ist da so schnell in einem großen Sumpf, wo ich eigentlich gar nicht hin will, ne?

Stefan Tilkov: Lass uns vielleicht feststellen, es gibt gewissen Dinge, wo wir das gar nicht wollen. Z.B. wollen wir wahrscheinlich beide nicht, dass die Bundestagswahl mit Wahlautomaten erfolgt oder so. Jetzt nehmen wir einfach mal an, dass es bestimmte Dinge gibt, bei denen wir uns jetzt darauf geeinigt haben, dass wir zumindest ungefähr wissen, was wir da bauen und wir sind uns auch sicher, dass es sinnvoll ist, das zu bauen. Und dieser Teil, das ist grundsätzlich sinnvoll ist, es zu machen und dafür die Sicherheitsdomäne sozusagen relativ klar ist – wer da was wissen soll. Was ist der nächste Schritt? Fangen wir jetzt an uns über konkrete technische Dinge zu unterhalten oder siehst du noch irgendein Architekturthema dazwischen? Suggestiv-Fragen, ne?

Willem van Kerkhof: Haha, Suggestiv-Frage, kann man auch schön aus dem Weg gehen. Ne ich denke Sicherheit in einem System: man sollte sich erstmal überlegen, was sind meine Datenhoheiten, was sind meine – also das sind architekturelle Sachen, sowieso – „Wer darf überhaupt was?“, „Wer weiß was?“, „Wer hat über welche Daten was zu sagen?“. Was ich ja sicherstellen will, ist ganz grundsätzlich, dass keiner meine Daten – egal welcher Art – anpasst, ohne dass ich es merke. Und anfasst, ohne dass er es darf. Dass er sie vielleicht sieht, ohne dass er es darf. Auf dieser Grundlage müssen dann auch architektonische Entscheidungen getroffen werden. Sei es jetzt der Schnitt von Services, wer darf überhaupt über welche Daten verfügen. Und andererseits natürlich technische Sicherheitsmaßnahmen, um dann auch diese Grenzen zu erzwingen. Also wenn ich einen Service hab – z.B. einen Authentisierungsservice – der verfügt über sensible Daten, vielleicht irgendwelche gehashten Passwörter und Passwort-Reminder und vielleicht sogar biometrische Daten, wie wir es jetzt aktuell Thema haben, wenn wir schon von IT- Großprojekten reden. Ne, Bundesregierung baut hier große – wie heißt es mittlerweile – es ist die elektronische Fußfessel, der neue Personalausweis.

Stefan Tilkov: So ähnlich.

Willem van Kerkhof: Das sind ja riesige Datenbanken letztenendes, die irgendwo aufgebaut werden, wofür als Schlüssel nämlich dein Fingerabdruck und dein Pass dient. Ok, das ist ein hochsicherheitsrelevantes System. Da müssen natürlich auch die Grenzen ganz klar abgesichert sein. Also erstes Wissen, dass diese Daten da sind. Sie sind sensibel und die müssen wir natürlich auch absichern oder abschotten vor unbefugtem Zugriff und vor allem auch vor unbefugter Änderung. Keine Ahnung, wie die IT hinter diesem NPA aussieht und ich will es glaube ich auch gar nicht wissen.

Stefan Tilkov: Sicherlich alles perfekt. Ähm ok, lass uns dann vielleicht mit dem Passwort-Thema mal anfangen. Also Passwörter sind etwas, wo man sich offensichtlich drum kümmern muss und am besten macht man das doch, indem man einen klugen Algorithmus erfindet, mit dem man diese Passwörter verschlüsselt – oder so ähnlich.

Willem van Kerkhof: Passwörter verschlüsseln machen viele Leute sehr gerne. Da nehmen die dann irgendeinen Secret – noch aus PHP-Zeiten – packen das Secret in den Code, das wird dann irgendwie verschlüsselt, ver-x-odert, weil ver-x-odern ist ja total sicher und so. Nein, das ist natürlich Unsinn. Also Passwörter legt man natürlich gehasht hab, Einweg-verschlüsselt sozusagen. Und das möglichst heutzutage nicht mehr mit md5 von Passwort xy. Warum nicht? Weil md5-Hashing ist einfach eine Hashfunktion, die z.B. auf Geschwindigkeit ausgelegt ist, sodass ich möglichst schnell einen md5-Hash von möglichst großen Datenmengen erstellen kann. Wenn, dann sollte man natürlich schon auch eine Hash-Funktion benutzen, die inherent langsam ist, sodass es auch lange dauert, ein Passwort zu knacken, wenn man den Hash hat.

Stefan Tilkov: Auch wenn das vielleicht 100% unserer Zuhörer klar ist, will ich es trotzdem kurz sagen. Also das, was man tut ist, man bildet aus dem Passwort einen neuen Wert mit der Hash-Funktion und das geht nicht rückwärts. Das geht nur in die eine Richtung. D.h., ich kann nachher, wenn sich der Benutzer nochmal anmeldet, mit demselben Passwort, werde ich bei der Operation wieder dasselbe heraus bekommen und kann dann das Ergebnis mit dem Vergleichen, was ich abgelegt habe.

Willem van Kerkhof: Plus natürlich so grundlegende Sachen, wie Passwort-Salting, dass ich dazu noch einen Salt ablege. Nicht, dass ich dann irgendwelche großen Tabellen von Standard-Passwörtern ablegen kann.

Stefan Tilkov: Genau. Aber auch das musst du glaube ich noch kurz erklären. Was genau ist ein Salt?

Willem van Kerkhof: Ein Salt ist im Prinzip einfach eine bekannte Zeichenkette – ich habe z.B. mein Passwort XY. Und wenn ich jetzt Passwort XY – oder sagen wir mal so, es gibt schöne Statistiken darüber, welche Passwörter am häufigsten verwendet werden. Und das ist glaube ich allen voran irgendwie „Se…“

Stefen Tilkov: „1234567“ oder „Secret“.

Willem van Kerkhof: Genau. Oder „Geheim“ oder „Passwort“. Und dann kommen die Namen von Geliebten, Bekannten usw. D.h., wenn ich jetzt einmal so ein Passwort abgelegt habe, gehasht mit SHA-1 oder SHA-256-Hash, von „secret“, gibt es auch beim nächsten Benutzer den gleichen Hash. Und das will ich nicht. Ich will ja, dass jeder Benutzer ein einzigartigen Hash hat, sodass ich nicht sehe „Ah, die haben ja das gleiche Passwort“. Deswegen packe ich da noch einen Salt dran, was Teil des Hashes ist. Also z.B. wenn man sich mal so ein Unix-Passwort oder Shadow-File anguckt, da steht ja dann $hash$salt und dann kommt erst der Passwort-Hash. D.h., ich muss noch eine Operation mit dem Salt und dem Passwort, dem Klartext-Passwort durchführen, z.B. Konkatenieren, und dann erst hashen und dann bekomme ich das Hash raus.

Stefan Tilkov: Ok. Angenommen ich will das implementieren. Was mache ich jetzt? Überlege ich mir jetzt, wie ich das mache oder wie mache ich das?

Willem van Kerkhof: Du implementierst das nicht.

Stefan Tilkov: Ah ok. Wieso nicht?

Willem van Kerkhof: Nein sowas, dafür gibt es fertige Bibliotheken, wie man so schön sagt. Ne, all sowas, was mit Krypto zu tun hat, das implementiert man nicht selber. Das überlässt man Leuten, die es können, erstmal.

Stefan Tilkov: Die kennt man in der Regel nicht persönlich.

Willem van Kerkhof: Die kennt man nicht persönlich, aber man kennt so Projekte wie „OpenSSH“ oder die ganzen Bibliotheken, die mit dem Betriebssystem mit kommen. Also das beschränkt sich jetzt nicht nur auf Passwort-Hashing, sondern auf jede Art von Hashing und Encryption, symmetrisch, asymmetrisch, Public-Key usw. Das baut man nicht selber.

Stefan Tilkov: Ok. Also lass uns als erstes mal festhalten: Passwörter werden nicht irgendwie abgelegt, werde nicht einfach verschlüsselt, werden ordentlich mit einer Bibliotheksfunktion mit einem spezifischen Salt irgendwie ordentlich abgelegt.

Wenn wir eine Webanwendung bauen, was hat auf einmal das Thema REST mit Security zu tun und das HTTP-Protokoll mit Security zu tun?

Willem van Kerkhof: Das Thema HTTP-Protokoll – du kommst auch von Hölzchen auf Stöckchen, hehehe.

Stefan Tilkov: Ja, das fällt mir grad so ein. Ich will darauf, ich frage deswegen, weil das sind Dinge, die man erstmal aktiv richtig machen muss. Da kann man einen Fehler machen, indem man erstmal das falsche implementiert, was gar nicht so offensichtlich ist, ist doch keine wirkliche Lücke, ist eher ein doofer Fehler.

Willem van Kerkhof: Ja gut. Also gehen wir vom Thema Passwörter weg – also ne, bleiben wir noch kurz beim Thema Passwörter und HTTP. Also klar, wenn wir von Authentifizierung sprechen und Co., wir müssen ja z.B. dieses Passwort irgendwie zum Server, zu unserer Applikation hin schicken oder einem Authentifizierungsservice oder was auch immer. Ja gut, da haben wir verschiedene Möglichkeiten, z.B. Formular-basiert oder Basic Authentification oder Digest- Authentication, usw. was ja mit im HTTP-Protokoll mit drin ist sozusagen, ne. Ich schicke entweder einen Token über den Header mit – BasicAuth – das ist das einfachste. Das ist einfach nur Base64-codiert Benutzer und Passwort als HTTP- Header. Wird mit jedem Request mit geschickt und verschlüsselt. Also Base64 sieht erstmal…

Stefan Tilkov: Eine sehr gute Verschlüsselung.

Willem van Kerkhof: Ein Base64-verschlüsseltes Passwort: äh, nee. Natürlich, wenn man sowas macht: https. Mit Secure, also per SSL abgesichert. Wenn man sensible Daten überträgt, natürlich nur verschlüsselt und dann vielleicht nicht unbedingt nur die Formularseiten oder die Seiten, wo etwas sicher sein sollte verschlüsseln, sondern am besten gleich alles. Dann sieht der Angreifer auch nicht, „Ah da ist etwas interessantes.“, sondern es könnte alles interessant sein, d.h., der Aufwand steigt, die Seiten raus zu picken oder raus zu finden, wo tatsächlich etwas Interessantes übertragen wird. Aber eben auch hier ist HTTPS ein etablierter Standard mit bewährten Chiffren – wollen wir jetzt gar nicht weiter drauf einsteigen.

Gut, wo waren wir? Basic Authentication, verschlüsselt übertragen. Genau es gibt noch HTTP Digest Authentication, die funktioniert anders. D.h., ich übertrage nicht das Passwort und den Benutzernamen als solchen, sondern ich bekomme eben einen Challenge-Token vom Server, hashe das irgendwie zusammen und schicken den Token zurück. Und wenn ich nicht beides kenne, dann ja. Ich schicke nicht mein Passwort mit, sondern auch wieder eine Operation, eine Art Hash-Funktion, die da durchgeführt wird mit dem Server-Token und kann im Prinzip auch ohne Verschlüsselung mich mit dem Server authentisieren.

Stefan Tilkov: D.h., Server und Client beweisen sich sozusagen gegenseitig, dass sie das Passwort kennen.

Willem van Kerkhof: Genau.

Stefan Tilkov: Ich wollte auf HTTP-GET vs. -POST hinaus, das war meine Suggestiv-Frage.

Willem van Kerkhof: Ah, ok. GET vs. POST. Machen wir mal einen großen Sprung. Ja, GET ist ja eigentlich klar, zum Lesen von Informationen. Wenn ich die verändern will, mache ich das mit POST, als allein schon gutes Applikationstransportprotokoll und gutes Applikations – na sag schon.

Stefan Tilkov: Design.

Willem van Kerkhof: Design, genau. Einfach wenn man REST baut, baut man das ja schon so. Warum ist das wichtig? Es ist einfach, einen GET-Request irgendwohin abzusetzen, ne. Gehen wir mal in die Richtung: ich logge mich auf einer Seite ein, bin da eingeloggt und sehe jetzt da irgendwelche Bilder, die auf irgendwas anderes zeigen. Diese Bilder sind vielleicht in einem Forum gepostet von irgendwem anders. Das sind jetzt tolle Bilder und bei einem da hat jetzt einer die Idee gehabt, anstatt einem Bild, der Bild-URL vielleicht eine GET-URL auf irgendwie eine destruktive Aktion, die man mit GET aufrufen kann – eine Schreib-Operation oder Lösch-Operation oder so – auf dem Server, wo ich gerade eingeloggt bin, einzuschleusen. D.h., mein Browser versucht diesen Link, was es letztenendes ist, automatisch aufzurufen. Das Bild ist aber kein Bild, sondern damit lösche ich zufällig irgendwas, keine Ahnung, ob es die eigene Session ist oder irgendwas aus der Datenbank, worauf ich Zugriff habe usw. Das ist im Prinzip so eine Art Cross-Site-Request-Forgery, d.h. ich zwinge den Benutzer dazu irgendetwas aufzurufen, was er eigentlich gar nicht aufrufen will und wenn das per GET geht, dann haben wir im Prinzip den schlimmsten Fall. Also ich kann ihm den Link unterjubeln, er klickt drauf und schon macht er etwas kaputt. Deswegen machen wir das per POST, alles was er kaputt machen kann, einfach weil es schwieriger ist einen POST-Request abzusetzen. Das geht nicht einfach durch einen Link, sondern da muss der Benutzer entweder aktiv was tun oder ich muss es halt per JavaScript irgendwie einbinden. Das kann man natürlich irgendwie aus einer Mail heraus auch, das kann man auch irgendwie bei einem Foren-Post oder so, wenn jetzt der böse Benutzer ein JavaScript-Snippet einbaut in seinen Post. Wenn das nicht ordentlich behandelt wird vom Server, dann taucht das vielleicht genau so wieder beim anderen Benutzer auf und dessen Browser führt das aus. Z.B. ein POST-Request auf irgendeine Ressource, auf die der andere keinen Zugriff hat, aber ich vielleicht schon, wenn ich z.B. Admin bin. Schon mache ich etwas kaputt, was vielleicht gar nicht hätte sein sollen. Da kann man natürlich vorbeugen.

Stefan Tilkov: Genau, die Antwort bei einem GET wäre: bei einem GET macht man einfach nichts kaputt, dann kann auch nicht passieren, wenn jemand einen dazu bringt, dass man ein GET ausführt. Weil das schlimmste was ich machen würde wäre, dass ich lese, was ich nicht lesen wollte.

Willem van Kerkhof: Richtig.

Stefan Tilkov: Was mache ich denn bei einem POST, was habe ich da für Optionen?

Willem van Kerkhof: Bei einem POST ist es natürlich etwas schwieriger. Im Prinzip mache ich das mit einem Page-Token, also einem Server-generierten Token, das in die Page, in die Seite mit embedded wird, z.B. in einem hidden-Field bei Formularen mit gesendet werden muss, sonst wird der Request nicht weiter verarbeitet vom Server, wenn das Token nicht stimmt. Das wird üblicherweise aus der Session-ID generiert, weil die im Cookie steht. D.h., du musst im Prinzip den Cookie-Wert haben und bzw. es ist nicht genau das, was im Cookie steht, sondern es ist auch wieder etwas verhashtes, was im Cookie steht plus einen Server-Secret-Token, was dann mitgeschickt werden muss im Formular.

Bei Rails ist das im Prinzip eine einfache Sache. Ich sage, hier aktivier mir dieses Feature sozusagen im Controller und dann wird es automatisch mit jedem Formular eingeblendet. Das funktioniert da z.B. aber nur mit HTTP-Formularen. Sobald ich auf XML- oder JSON-Requests gehe, dann greift das wiederum nicht mehr.

Stefan Tilkov: Wobei das da glaube ich nicht so dramatisch ist, weil ich ja nicht den Browser dazu bewege, solche Requests zu machen.

Willem van Kerkhof: Genau. Also ich kann mir natürlich Szenarien ausdenken, wo es dann doch wieder ein Problem ist, aber das ist…

Stefan Tilkov: Jaja, ok. Was haben wir noch an Standard-Dingern, wenn wir schon dabei sind? Injections?

Willem van Kerkhof: Injections, ja klar. Also das ist ja schon eine Art von Injection. Also ich jubele dem Benutzer irgendwas unter im JavaSript und dann kommt irgendwas, was eigentlich gar nicht da rein soll. Das ist eine Art von Injection, wie sorge ich dafür, dass so ein Cross-Site-Scripting nicht möglich ist. Wenn man einen Token mitschickt, ist das gut. Aber ich sollte eigentlich dafür sorgen, dass das JavaScript nicht ausgeführt wird, dass es einfach raus gefischt wird. Also ich sollte mich niemals auf Eingaben eines Benutzers verlassen. Ich sollte immer davon ausgehen, dass der Benutzer entweder zu 99% dumm oder zu 1% böswillig. Übrigens sind die 99% dumme Menschen eher das Problem, als das 1% böswilliger Menschen, das ist schon ein wichtiger Aspekt. Mich gegen Böswilligkeit zu schützen ist in der Tat sehr schwierig. Gegen Dummheit auch, aber gut. Ne, aber wegen Injection sollte man den Inhalt, den man vom Benutzer bekommt, immer erstmal überprüfen. Sei es JavaScript rausschmeißen, Blacklisting: sagen ich schmeiße alle script-Tags raus, oder Whitelisting: ich lasse nur bestimmte Tags zu, z.B. ich lasse nur grundlegende Formattierungen in Blogposts oder so zu. Hat beides seine Vor- und Nachteile. Dann gibt es natürlich noch Sachen: wenn ich weiß, auf irgendeine Art, wie meine Datenbank- Struktur dahinter aussieht, dann kann ich auch böswillige Angriffe machen mit SQL-Injections, sogenannte. D.h., ich gehe davon aus, dass mein POST als Inhalt in Spalte „Post-Content“ landet oder so und ich baue mein Request einfach so, dass im Prinzip mein Content einen validen SQL-String enthält, oder sagen wir, dass ich dem Server vorgaukle, dass mein Inhalt früher aufhört und danach kommt irgendwie was ; AND DROP table irgendwas. Und den Rest kommentiere ich aus, sozusagen. Auf owasp.org steht das auch alles wunderbar beschrieben.

Stefan Tilkov: Genau. Wir müssen unbedingt Little Bobby Tables in die Shownotes verlinken.

Willem van Kerkhof: „Did you call your son…“

Stefan Tilkov: Ja genau.

Willem van Kerkhof: Also klar, wie gesagt, kein Inhalt, der vom Benutzer kommt, egal in welcher Art, sollte so genommen werden und weiter verarbeitet werden, sollte nicht so in die Datenbank kommen, sollte immer escaped werden. Das ist einfach was, das muss in Fleisch und Blut sitzen. Was ich immer gerne mache und in Projekten auch so code-convention-mäßig gerne erzwingen würde, ist sowas wie – ganz banal – doppelte Anführungsstriche vs einfache Anführungsstriche. Wenn ich Queries an die Datenbank absetze, dann will ich keine doppelten Anführungsstriche irgendwo sehen. Ich will kein WHERE "irgendwas", weil alles, was da drin steht wird potentiell evaluiert. D.h., wenn da irgendwas mit Benutzereingaben rein kommt, dann wird das potenziell evaluiert, nicht escaped usw. D.h., ich will immer einfache Anführungsstriche, ich will ein String- Literal haben, wo ich irgendwas über einen Schutzmechanismus meines Frameworks z.B., meines Webapplikationsframeworks, wo ich dann meine Strings rein packe. Ich will mich auch nicht selber um das Escaping kümmern müssen, das darf ich nicht selber machen, weil ich vergesse immer etwas. Ich bin nur ein einfacher Entwickler und solche Frameworks, die man doch gerne nutzen sollte, die sind meistens doch mit etwas mehr Man-Power entwickelt worden, als ich jemals in meinem ganzen Berufsleben da rein investieren kann.

Stefan Tilkov: Lass uns doch vielleicht mal so ein Fazit zusammen basteln. Was sollte man denn aus deiner Sicht so wissen? Also was ist für einen Entwickler unbedingt notwendiges Wissen über die ganze Security-Thematik?

Willem van Kerkhof: Also unbedingt notwendig ist als aller erstes nicht unbedingt das Wissen, sondern erstmal eine Einstellung. Und zwar die Einstellung, dass ich keine Ahnung von dem Ganzen habe und ich mich auf die Sachen verlassen sollte, wo andere schon Vorarbeit geleistet haben. Sei das, es gibt Best-Practice-Pattern, Steigerung von technischer Sicherheit, an sowas sollte ich mich halten. Ich sollte die nur dann umgehen, wenn ich ganz genau weiß, was ich tue. Und selbst, wenn ich glaube, dass ich weiß, was ich tue, weiß ich, dass ich es nicht weiß, weil ich bin ja nur ein einfacher Entwickler. Unbedingt Wissen: man sollte die OWASP-Seite, die Open Web Application Security Project Seite sollte man vielleicht mal ein bisschen kreuz lesen. Da stehen hunderte, tausende sicherheitsrelevanter Themen drin. Das fängt eben auch mit Cross Site Scripting an, geht weiter mit Session Highjacking, Thema Hashing, Thema Best Practice „Wie lege ich meine Daten überhaupt ab?“ usw. Deswegen, ich würde da jetzt aus dem Kopf gar nicht weiter zitieren.

Stefan Tilkov: Hast du einen Literaturverweis, Bücher die du empfehlen würdest?

Willem van Kerkhof: Klar, immer. Wer sich irgendwie fürs Thema Security interessiert sollte auf jeden Fall mal so alles von Bruce Schneier gelesen haben. Dem Rockstar unter den Security-Experten. Der Mann hat einen riesen Output, aber auch noch mit viel weiter gefassten Security-Themen als nur in der IT. Das ist auch, was ich jedem mit auf den Weg geben würde – da haben wir jetzt noch gar nicht groß drüber gesprochen – Security fängt eigentlich wo ganz anders an. Das ist nicht bei meinem System, sondern beim Denken, beim Menschen, beim Vertrauen zu Menschen, bei der Manipulierbarkeit von Menschen. Weil was bringt mein hochsicheres System, wenn ich dem Benutzer dahinter, notfalls mit einer Kneifzange am Ohr oder so, dazu bringen kann, das zu tun, was ich will, ne? Also Thema Sicherheit in Firmen. Viele Angriffe kommen von Innen und wie wir jetzt gerade neulich so, in der letzten Zeit in den Medien aufmerksam verfolgen können, was passiert, wenn einer aus politisch motivierten Gründen – seien die jetzt in Ordnung oder nicht – dazu bewegt wird, einfach mal riesige Datenmengen mitzunehmen, nach Hause und die dann an die – aus Sicht der Firma oder Organisation – falschen Leute zu verteilen. Da hilft auch nichts, wenn ich meine Cross Site Scripting Lücken im Griff habe. Da hilft es auch nichts, wenn meine Passwörter irgendwie gut verschlüsselt sind, wenn der Mensch, der SysAdmin ist. Also da muss ich ganz woander eingreifen. Organisatorisch, ich muss meinen Leuten vertrauen, ich muss den Kreis der absolut Mächtigen möglichst gering halten. Ich muss den Leuten auch den Anreiz geben, sage ich mal, im Sinne der Organisation sicher zu denken, nicht zu persönlichen Vorteilen, dass sie sich selbst zu persönlichen Vorteilen verhelfen, wodurch auch immer. Seien es jetzt politisch motivierte Aktionen wie neulich bei Snowden und Co. oder seinen das halt rein finanziell motivierte Sachen, wie „Ich kenne irgendwelche Kundendaten, die vielleicht interessant sein könnten für andere und die klaue ich jetzt mal“. Das tut meinem Arbeitgeben weh, aber vielleicht bezahlt mir die Konkurrenz dafür Unsummen.

Stefan Tilkov: Oder das Finanzministerium, wer weiß.

Willem van Kerkhof: Oder das Finanzministerium, ganz genau.

Stefan Tilkov: Alles klar.

Willem van Kerkhof: Also das Thema geht noch viel weiter. Das ist dann natürlich sozial-politisch usw.

Stefan Tilkov: Ok. Willem, vielen Dank. Wir konnten das natürlich nur anreißen, völlig klar. Hat trotzdem sehr viel Spaß gemacht. Danke dir.

Willem van Kerkhof: Würde ich auch sagen, danke Stefan. Bis zum nächsten Mal.

Stefan Tilkov: Bis zum nächsten Mal, ciao.