Carsten Eilers Selbstständig

„Falls man während der Entwicklung ein sicherheitsrelevantes Problem hat, dürfte es sich oft lohnen, nach einer passenden Library zu suchen. Man muss 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 mal 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 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 potentielle Schwachstelle betrachtet und ersetzt werden, egal ob sie nun offiziell eingestellt wurde oder nicht.

Den vollständigen Artikel lesen Sie in der Ausgabe:

PHP Magazin 6.16 - "Hello Chatbot"

Alle Infos zum Heft
274678PHP Security Libraries im Überblick
X
- Gib Deinen Standort ein -
- or -