Kein Frage,
- PHP hat immer wieder Sicherheitslücken
- Ja, die sollten schneller geschlossen werden
- Ja, das QA-Management von PHP ist bestimmt nicht (immer) optimal
ABER:
Wenn Sprachen, welche als "sicherer" oder "professioneller" bezeichnet werden, genauso weit verbreitet bzw. auf jedem x-beliebigen Webserver für jeden DAU verfügbar wären wie PHP, dann gäbe es für Applikationen in diesen "supersicheren" Sprachen mit Sicherheit ähnlich viele Angriffsziele wie für PHP-Applikationen.
Wenn ich mir anschaue, über welche Löcher Angreifer bei uns Webserver aufmachen, dann sind das in den allermeisten Fällen (> 90%) entweder üble Bugs in den Applikationen selber oder "irgendjemand" der nicht mal ansatzweise ein Verständnis dafür hat was er da gerade tut, installiert sich Applikation XY auf seinem Webspace ohne diese abzusichern.... In den Specs der Web-Applikationen die man so im Netz findet steht ja auch meistens: kein Thema, das können Sie ganz einfach auf jedem Webserver mit PHP laufen lassen, auspacken und gut ist.
Ist PHP also unsicher weil...
- es so erfolgreich und beliebt geworden ist?
- viele (PHP)Programmierer kein ausreichendes Sicherheits-Bewusstsein haben?
Klar könnte PHP als Sprache es den Programmierern schwerer machen unsichere Applikationen zu schreiben (Stichwort "tainted mode", o.ä.) aber dann gibt es immer noch den Unsicherheitsfaktor User. Wie soll eine Programmiersprache seine User denn vor Unwissenheit und/oder Dummheit schützen?
Hier mal ein kleine Liste der Schwachstellen in PHP Scripten über die böse Buben nach meiner Erfahrung so reingekommen:
- include()/require() mit ungeprüften Usereingaben als Parameter
- exec() | system() mit ungeprüften Parametern aus Usereingaben
- Cleartext Passworte ungeschützt innerhalb der Document-Root
- SQL-Queries mit ungeprüften Usereingaben als Parameter
- ungeprüften Usereingaben....
- noch mehr ungeprüften Usereingaben....
Findet sich alles leider auch in Nicht-PHP-Applikationen, nur eben (noch?) nicht so weit verbreitet und je nach Sprache nicht so einfach.
Zugegeben, "
Remote File Inclusion" Lücken einzubauen ist mit PHP ein Leichtes und (leider) auch sehr verbreitet (
siehe google codesearch). Aber hey, keiner hat behauptet das jeder ein guter Programmierer ist, von was würden wir denn Leben wenn es so einfach wäre gute Software zu schreiben?
Anderes Beispiel: Vor ein paar Tagen war eine Bekannte bei uns und hat uns ihr Leid geklagt: eine "Profi-IT-Firma" soll die Website neu machen, würde dabei aber keinen so besonders kompetenten Eindruck machen. Ich habe mir deren Seiten dann (nur aus Interesse ;-) mal kurz angeschaut und schwups was haben wir denn da? XSS-Lücken, SQL-Injection, sehr sprechende Fehlermeldungen, die Datenbank wird mit einem User angesprochen der auch Zugriff auf die mysql-System-DB hat (mal eben die user Tabelle auslesen und so...), kurzum, alles was Spass macht. Na, da steckt doch bestimmt wieder dieses miese PHP dahinter, oder? Wahrscheinlich auch wieder so ein Frickel-Open-Source-Projekt. Aber nein, hinter der Seite läuft ein lizenzpflichtiges CMS auf Zope/Python Basis! Das nenn ich doch mal echte Profi Software bestimmt irgendwas mit "enterprise", da merkt man doch gleich den Unterschied zu diesen ganzen PHP-Frickel-Scripten!
Man kann und sollte sich niemals nicht darauf verlassen, dass Applikationen sicher oder unsicher sind, nur weil sie in der einen oder anderen Sprache geschrieben wurden.
Wirkliche Sicherheit auf Webservern, auf welchem Kunden/User die Möglichkeit haben eigene Scripte mit welcher Sprache auch immer auszuführen, ist meiner Meinung nach nicht (mehr?) machbar.
Als Admin kann man hier nur noch Schadensbegrenzung erreichen und dafür sorgen, dass die User "nur" ihre eigenen Daten kaputt machen können, bzw. bei Auffälligkeiten (Spam-Schleuder, IRC-Bot, File-Server, etc) den Stecker ziehen.
Es ist noch gar nicht so lange her da erschien die vollkommen neue Version 2.5 von der beliebten Blog Software Wordpress. Und schon sind die Entwickler wieder dabei Verbesserungen nach zu legen. Diese behebe eine schwerwiegende Sicherheitslücke. ...
Aufgenommen: Apr 28, 07:12