© istockphoto.com/aleksandar_velasevic
PHP Security Libraries im Überblick

Nicht immer das Rad neu erfinden!


Es gibt für alles Mögliche Libraries und Frameworks, angefangen bei umfangreichen Paketen für komplette Webanwendungen bis zu ganz speziellen Lösungen für spezifische Probleme – auch für den Bereich Sicherheit. Und die schauen wir uns jetzt einmal an.

Der Einfachheit halber verwende ich im Folgenden immer den Begriff „Library“. Das Gleiche gilt genauso natürlich auch für Frameworks, Komponenten etc.

Generell gibt es viele Gründe, warum man auf eine fertige Library zurückgreift, statt ein Problem selbst zu lösen. Angefangen beim „Warum soll ich das selbst implementieren, wenn es schon was gibt?“ über „Die Library ist schneller/eleganter/besser ...“ bis zum „So gut würde ich das selbst nicht hinbekommen!“. Und letzteres ist das beste Argument, wenn es um die Sicherheit geht.

Sicherheit ist oft nicht trivial

Es ist verdammt schwer, zum Beispiel einen sicheren Verschlüsselungsalgorithmus zu entwerfen. Die sichere Implementierung ist dann wieder eine andere Baustelle. Deshalb sollte man stets bewährte, allgemein als sicher anerkannte Algorithmen verwenden und diese möglichst als fertige Implementierungen, die sich bereits bewährt haben. Das Gleiche gilt für viele andere Aufgabenstellungen.

Das OWASP PHP Security Project [1] war als Sammlung sicherer Libraries für sicherheitsrelevante Aufgaben geplant, wurde inzwischen aber aufgegeben. Der Grund: Die selbst gesteckten Ziele wurden nicht erreicht, der Code war voller Schwachstellen. Das sollte Ihnen zu denken geben – wenn schon die OWASP-Mitglieder, die sich ja hauptsächlich mit Sicherheit beschäftigen, so ein Projekt nicht fertig bekommen, wie sieht es dann erst bei Entwicklern aus, die „Sicherheit“ nur nebenbei machen?

Mitgefangen, mitgehangen

Libraries haben einen Nachteil: Wenn man sie verwendet, wird man sie meist nicht so leicht wieder los. Der Austausch einer Library gegen eine andere oder auch eine eigene Implementierung der verwendeten Funktionen etc. ist meist mit erheblichem Aufwand verbunden. Dies wird zum Problem, wenn die verwendete Library irgendwann nicht mehr weiterentwickelt und dadurch zum Beispiel nicht an die aktuelle PHP-Version angepasst wird. Spätestens wenn die ersten Schwachstellen darin bekannt, aber nicht mehr behoben werden, sollte man an einen Abschied denken. Denn Schwachstellen in Libraries haben für Angreifer einen großen Vorteil: Sie können mit einem Exploit für eine Schwachstelle in der Library viele verschiedene Anwendungen angreifen – alle, die eine betroffene Version der Library verwenden.

Leider gibt es auch im Bereich Sicherheit etliche Libraries, die nicht mehr weiterentwickelt werden. Teilweise wurde die Entwicklung offiziell eingestellt, teilweise ist sie auch einfach eingeschlafen. Ob sich dann noch mal was tut oder ob das Projekt tot ist, lässt sich von außen nicht entscheiden. Aber das ist eigentlich auch egal: Eine seit längerer Zeit nicht mehr weiterentwickelte Library sollte immer als potenzielle Schwachstelle betrachtet und ersetzt werden, egal, ob sie nun offiziell eingestellt wurde oder nicht.

Fremd-Library oder Eigenentwicklung, das ist hier die Frage!

Das unten noch näher vorgestellte URLcrypt [2] ist ein typisches Beispiel für die Frage „Selbst implementieren oder Library nutzen?“. URLcrypt dient zur Verschlüsselung und anschließenden Kodierung von Daten, die sicher in den URL übertragen werden sollen. Das zu lösende Problem ist also überschaubar. Die Lösung selbst zu entwickeln sollte für keinen Entwickler ein unüberwindbares Hindernis sein. Die Hintergründe hat URLcrypt-Entwickler Aaron Francis in seinem Blog erklärt [3].

Das können Sie sicher auch selbst entwerfen bzw. implementieren. Andererseits existiert eine fertige Lösung. Die Zeit, die Sie für eine Eigenentwicklung benötigen, könnten Sie also viel nützlicher für die Arbeit an Ihrer eigentlichen Webanwendung nutzen. Wozu also Zeit verschwenden?

Erst mal ist das natürlich eine Lizenzfrage. Nur wenn die Lizenz der Bibliothek (URLcrypt zum Beispiel nutzt die MIT License) zur eigenen Lizenz passt, kann man die vorhandene Lösung überhaupt nutzen. Dann steht allerdings noch das oben erwähnte Problem mit der Weiterentwicklung im Raum.

Sie sollten eine Library nur nutzen, wenn Sie davon ausgehen können, dass sie zum einen aktuell sicher ist und zum anderen auch in Zukunft weiter von den Entwicklern unterstützt wird.

Wenn die Entwicklung offiziell eingestellt wurde, ist die Entscheidung einfach: So eine Library ist ein potenzielles Sicherheitsproblem und darf nicht verwendet werden.

Aber was ist, wenn die Entwicklung zurzeit etwas zu stocken scheint? Eine Nachfrage bei den Entwicklern gibt schnell Aufschluss darüber, ob das Projekt eingestellt wurde oder noch daran gearbeitet wird. Erklären die Entwickler das Projekt für eingestellt oder reagieren sie gar nicht, ist die Sache klar: Da tut sich nichts mehr. Schwieriger wird es, wenn sie versichern, es werde bald wieder weiterentwickelt. Dann können Sie nur raten, wie es wohl weitergeht. Es sind ja schon oft Projekte verwaist, weil die Entwickler sich zerstritten oder einfach das Interesse verloren haben. Diese Gefahr besteht zwar bei jedem Projekt, aber wenn die Entwicklung schon längere Zeit ruht, ist das meist ein schlechtes Zeichen. Im Zweifelsfall sollten Sie auf den Einsatz der Library verzichten, gerade wenn es um Sicherheitsfunktionen geht.

Aber genug der Vorrede, schauen wir doch mal, was es da so alles gibt. Die Libraries sind nach Themen geordnet, darunter dann in alphabetischer Reihenfolge, sofern Abhängigkeiten nicht eine andere Reihenfolge nahelegen.

Benutzereingaben sind gefährlich

Die meisten Angriffe auf Webanwendungen erfolgen über Benutzereingaben oder andere vom Angreifer manipulierbare Daten, die von außen an die Webanwendung geschickt werden. Diese Daten zu filtern ist also meist der wichtigste Schritt zur Abwehr von Angriffen. Und dabei können Bibliotheken helfen.

HTML Purifier: standardkonformer HTML-Filter

Der HTML Purifier [4] hilft bei der Lösung eines großen Problems: Wie erlaubt man HTML in Benutzereingaben, ohne dass dadurch eine XSS-Schwachstelle entsteht? Der HTML Purifier entfernt Schadcode anhand einer Whitelist: Nur harmlose Eingaben können den Filter passieren. Nebenbei sorgt der „Reiniger“ noch dafür, dass die Daten danach dem HTML-Standard entsprechen.

Die aktuelle Version 4.8.0 wurde am 16. Juli 2016 veröffentlicht und läuft ab PHP 5.0.5. Ein kleiner Nachteil ist die mangelhafte Unterstützung von HTML5. So wird zum Beispiel das video-Tag nicht unterstützt und herausgefiltert [5]. Das Problem lässt sich zwar durch eigene Anpassungen umgehen, aber eigentlich sollte man erwarten, dass ein HTML-Filter im Jahr 2016 HTML5 von Haus aus unterstützt.

htmLawed: noch ein HTML-Filter

htmLawed [6] ist ein weiterer Filter für HTML mit dem Ziel, XSS-Code aus der Eingabe zu entfernen. Die HTML-Elemente und -Attribute sowie HTTP-Protokolle in der Eingabe können mit Black- und Whitelists gefiltert werden. Außerdem ist die Anpassung der Eingabe an die geltenden Standards oder eigene Vorgaben möglich.

htmLawed benötigt mindestens PHP 4.4. Die aktuelle Version 1.1.22 wurde am 5. März 2016 veröffentlicht, für Version 1.2 wurde die Unterstützung von HTML5 angekündigt [7].

PHPIDS: Intrusion-Detection-System für PHP-Anwendungen

Das „PHP-Intrusion-Detection-System“ PHPIDS [8] ist ein auf PHP basierendes Intrusion Detection System (alles andere wäre bei dem Namen auch sehr verwunderlich), also ein System zur Erkennung von Eindringlingen bzw. Angriffen. Dazu wird das PHPIDS-Skript in alle PHP-Skripte eingebunden, die vom Benutzer gelieferte Daten verarbeiten.

Um Angriffe zu erkennen, überwacht PHPIDS mithilfe regulärer Ausdrücke Arrays, über die Benutzereingaben übernommen werden, insbesondere also $_GET und $_POST. Erkannt werden u. a. Cross-site Scripting, SQL Injection, Directory Traversal und Remote File Inclusion. Wird ein Angriff erkannt, werden die gesammelten Informationen in einem Ere...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang