Interview mit Stefan Esser

Erstmal vielen Dank, dass du dir die Zeit genommen hast, uns ein paar Fragen über dich, deinen Job und PHP zu beantworten. Für viele giltst du als der Sicherheitsexperte im deutschsprachigen Raum. Der Ruf kommt natürlich nicht von ungefähr. Durch deine diversen Publikationen, Vorträge und nicht zuletzt der Mitentwicklung von Suhosin, scheint dir dieser Ruf zu Recht anzuheften.

Aber vielleicht erzählst du einfach mal ein paar Worte über dich, da es bestimmt ein oder zwei Leser gibt, die dich oder deine Projekte nicht kennen.

Ich bin 29 Jahre alt, lebe in Köln und arbeite als Leiter von Forschung und Entwicklung bei der SektionEins GmbH, die sich ausschließlich um die Sicherheit von Webanwendungen kümmert. Ich programmiere mit PHP seit circa 8 Jahren und bin fast ebenso lange PHP Core Entwickler. Im Umfeld IT-Sicherheit bewege ich mich seit circa 10 Jahren, was dazu geführt hat, dass ich das PHP Security Response Team mitgegründet habe, welches ich dann vor 2 Jahren verlassen habe. 2004 gründete ich das Hardened-PHP Projekt, dessen Ziel es war eine Sicherheitsgehärtete Version von PHP herauszubringen und gleichzeitig in Form von Audits von PHP Applikationen der Open Source Welt unter die Arme zu greifen. 2006 wurde aus Hardened-PHP dann Suhosin, welches als Allround PHP Sicherheitssystem mittlerweile Einzug in viele Distributionen gefunden hat. 2007 erregte ich dann mit dem Month of PHP Bugs einiges an Aufsehen, bei dem ich einen Monat lang jeden Tag eine oder mehrere Sicherheitslücken in PHP veröffentlichte. Ansonsten gehe ich gerne Schwimmen, liebe Kino, gutes Essen und lerne Koreanisch.

PHP ist leicht zu erlernen, was meiner Meinung nach auch eines der großen Probleme dieser Sprache ist. Man muss nicht viel Hintergrundwissen besitzen, um einfache Probleme zu lösen. Aber genau dies macht es einfach Skripte zu entwickeln, die vor Sicherheitslücken nur so wimmeln. Wo siehst du die größten Probleme bei PHP Anwendungen, welche Fehler werden immer wieder begangen?

Es stimmt, dass eine ganze Menge von PHP Programmierern keine Ahnung haben, was sie da eigentlich tun und komplett ohne Sicherheitskonzept programmieren. Das merkt man, wenn man sich einmal in einem Anfängerforum herumtreibt und dort die Fragen durchliest. Diese Tatsache wird sehr gerne herangezogen um das schlechte Bild von PHP in der Öffentlichkeit zu entschuldigen, aber in meinen Augen ist diese nur eine Ausrede.
Fakt ist, dass nicht nur die blutigen Anfänger, sondern auch sehr erfahrene PHP Programmierer Sicherheitsprobleme in PHP Skripte einbauen. Gründe hierfür sind natürlich auch der Zeitdruck der in Projekten häufig herrscht. Dies zeigt sich darin, dass Applikationen zwar Daten escapen/encoden bei der Ausgabe in HTML oder SQL aber es dann doch mal an ein paar Stellen vergessen. Es ist leider aber auch häufig zu sehen, dass Escaping und Encoding Funktionen in Kontexten benutzt werden, wo sie einfach nichts bringen, wie beispielsweise htmlspecialchars() innerhalb eines TAG Attributs oder mysql_real_escape_string() für Zahlen oder Order-By Statements. Leider Gottes treten seit einiger Zeit auch immer mehr PHP Security Experten hervor, die teilweise gefährliche Sicherheitstipps verbreiten. Beispiel aus der Praxis: die Empfehlung file_exists() zu verwenden um Remote URL Includes abzufangen. Dieser „Schutz“ bringt natürlich gar nichts, weil der ftp fopen wrapper auch den stat Aufruf emuliert und daher file_exists() auf für Dateien auf entfernten FTP Servern funktioniert. Darüber hinaus vergessen die Leute immer, dass PHP Code auch über lokale Dateien, wie z.B. Logdateien eingeschleust werden kann.

Allerdings bin ich der Meinung, dass der PHP Security Hype der letzten Jahre dafür gesorgt hat, dass viele Leute zumindest anfangen darüber nachdenken was sie machen. Ich denke jedoch, dass sie oftmals nicht defensiv genug vorgehen, was vielleicht zukünftige Sicherheitsprobleme abwehren könnte. Es werden auch oft Ansätze gewählt wie, alle Eingabedaten erstmal komplett durch irgendwelche Filter zu jagen und sie dann direkt für HTML/SQL zu encodieren. Es wäre viel sinnvoller sich ein Konzept auszudenken, dass dafür sorgt, dass alle Nutzerdaten nur noch über definierte Filterfunktionen erreichbar sind. Das heißt der Programmierer muss sich Gedanken machen, was für Daten er haben will und die entsprechende Funktion nutzen. Gleiches gilt für den Ausgabelayer. Es sollte explizit für jeden auszugebenden Datentyp eine Funktion geben und die direkte Ausgabe verboten werden. Das erzieht die Programmierer dazu nachzudenken.

Problematisch ist auch, dass die Themen SQL Injection und XSS sehr gehyped werden, dafür andere Probleme, die ebenfalls weit verbreitet sind, wie CSRF, schwache Zufallszahlen oder Probleme im Session Management nicht erwähnt werden. Es ist bereits heute so, dass wir Applikationen auditieren in denen wir keine SQL Injektion und auch kein XSS finden, die aber voll von anderen Problemen sind. Dies wird sich wahrscheinlich aber erst dann ändern, wenn es genug vollständiges Material im Web gibt.

Wie sehen die Entwickler von PHP deiner Meinung nach diese Probleme und wie versuchen Sie sie zu lösen?

Die Entwickler von PHP wollen im allgemeinen nichts von Sicherheitsproblemen in PHP Applikationen wissen, da sie ihrer Meinung nach nichts mit PHP sondern mit Programmierfehlern der jeweiligen Programmierer zutun haben. Sie ignorieren es in der Regel, wenn man versucht ihnen klar zu machen, das ein Feature gefährlich ist und wieder rausfliegen sollte. Das ist auch der Grund, warum es Jahre gedauert hat, bis allow_url_include eingeführt wurde, was hoffentlich irgendwann dazu führt, das Remote File Include Angriffe aussterben. Auch register_globals und magic_quotes_gpc werden erst mit PHP 6.0 verschwinden, obwohl sie auch noch heute Quell vieler Sicherheitsprobleme in alten PHP Anwendungen sind.

Am Beispiel der Filter Extension, die mit PHP 5.1 ausgeliefert wurde, sieht man deutlich, dass es manchmal gute Ideen gibt, diese aber nicht konsequent durchgesetzt werden. Per Default führt die Extension letztendlich nur eine neue API für bereits vorhandene PHP Funktionen ein, so daß man die notwendige Funktionalität vielleicht besser im Kopf halten kann, bzw. einfacher im Manual nachschlagen kann. Dies macht es für Entwickler unter Umständen leichter. Es wäre aber sinnvoller gewesen an dieser Stelle einen Bruch zu machen und den direkten Zugriff auf Request Variablen zu verbieten. PHP Applikationen sollten nur noch über eine Filter API Zugriff auf die Request Variablen erhalten, wo sie genau spezifizieren müssen, welchen Datentyp und welche Länge sie erwarten. Auf diese Weise könnte sichergestellt werden, dass es viel schwerer wird etwas bei der Filterung zu übersehen.

Damals war dies vielleicht aus BC Gründen nicht möglich, mit PHP 6.0 wäre so etwas vielleicht durchzusetzen, aber ich glaube ehrlich gesagt nicht das dies geschieht.

Obwohl PHP noch einige Probleme hat, hast du dich dieser Sprache verschrieben. Was macht gerade PHP für dich so interessant?

PHP und PHP Applikationen sind für mich gerade wegen dieser Probleme interessant. Als Sicherheitsmensch ist meine Aufgabe ja weniger die Entwicklung von oder mit PHP, als das Aufspüren und Beheben von Problemen. Ich empfinde es als Herausforderung nicht nur neue Arten von Sicherheitsproblemen zu finden, sondern gleichzeitig auch noch generische Verteidigungen dagegen auszudenken. Ohne diese Probleme wäre PHP langweilig für mich und letztendlich würde ich dann mit PHP auch kein Geld verdienen.

Schauen wir einfach mal ein Stück in die Zukunft, was denkst du werden die Highlights der nächsten Jahre in der Webentwicklung und inbesondere bei PHP sein?

Im Bezug auf Sicherheit sehe ich in den nächsten Jahren große Veränderungen für PHP und PHP Applikationen. Mehr und mehr Entwicklungen werden nicht mehr auf Plain PHP aufsetzen, sondern das ein oder andere Standardframework nutzen. Diese Frameworks werden dann (bzw. tun sie schon heute) von Haus aus soviele Sicherheitsfeatures mitbringen, wie Inputfilter, Output-Layer mit Escaping, SQL per Prepared Statements und Schutz gegen CSRF, dass es für Programmierer schwer wird die abgedeckten Fehlerklassen in Anwendungen einzubringen. Das setzt natürlich vorraus, dass die Framework Entwickler wissen was sie tun.
Allgemein gesehen wird immer mehr Logik mittels JavaScript, Flash, Silverlight auf den Client ausgelagert werden, die dann mittels AMF, JSON, REST, SOAP, XML mit dem PHP auf dem Server spricht. Ich vermute das dank Adobe AIR und ähnlichen Technologien der Trend von rein browsergesteuerten Webanwendungen zu Desktopanwendungen übergeht, die mittels Webtechnologie implementiert sind.

Eine Standardfrage, die wir all unseren Interviewpartnern stellen ist natürlich an das Thema dieses Blogs angelehnt. Wann hast du dich das letzte mal so richtig über PHP oder die Community aufgeregt?

Ich glaube das war vor einer Woche, als es mal wieder schöne Diskussionen darüber gab, das Suhosin Nutzer bei denen Suhosin eine Memory-Corruption in PHP festgestellt hatte, keinen richtigen Support kriegen.
Sie werden abgespeißt mit Antworten wie: Support gibt es nur, wenn Du PHP recompilierst und es ohne Suhosin reproduzierst, weil Patches gegen PHP führen neue Bugs ein.

Ich hatte dann letzte Woche auch ein etwas längeres Blogposting verfasst, das erklärt warum dieses erhalten problematisch und IMHO unsinnig ist.

Unsere letzte Frage hat nicht wirklich was mit PHP zu tun, ich denke aber, dass die meisten Leser sie trotzdem immer wieder interessant finden und sie auch eine Menge über einen aussagt. Mit wem würdest du gerne mal bei einem Projekt Pair Programming betreiben?

Meine Wahl fällt hierbei klar auf Mark Dowd. Ich weiß zwar nicht in wieweit er ein guter Developer ist, aber er ist zumindest einer der besten Source Code Auditoren der Welt.