Heute erschien auf heise ein Bericht von IBM’s Sicherheitscenter X-Force zum Thema Sicherheit. Seit 10 Jahren stellt X-Force Analysen in einem Jahresbericht zusammen, welche Exploits und Patches das Jahr so zu bieten hatte. Eine gute Sache. Leider war der Inhalt erschreckend: Mehr als die Hälfte der entdeckten Lücken blieb ungepatcht.

Die Top-Ten-System-Vendors machten dabei gerade mal 19% der Lücken aus. Im Umkehrschluss bedeutet dies, dass vor allem die Summe kleinerer Software für das Gros der Exploits verantwortlich ist. Und genau dort liegt auch die Patch-Rate am niedrigsten. Also bleiben Bugs und Sicherheitslücken sehr lange offen oder werden gar nicht erst gefixt.

Nimmt man die gesamten Microsoft-Varianten (XP, 2000, Server 2o08 etc.) zusammen, so ist die Redmonder Software-Schmiede immer noch führend in der Kategorie “Schlechtester Code aller Zeiten”, gefolgt von MacOS als meistgefährdetem Einzel-Betriebssystem.

Bugs in Open Source und PHP

Jedoch liegen viele Open-Source-Projekte wirklich dicht auf: Sowohl der Linux-Kernel als auch viele CMS-Systeme, vor allem in PHP, zeigten eine große Anzahl an Schwächen. Auffallend war, dass die wachsende Anzahl von Web-Exploits stets auf PHP traf. Nun ist das Entdecken der Schwächen in Open Source Software auch offizieller Bestandteil des Entwicklungszyklus. Man könnte also locker sagen, das sei alles halb so wild.

X-Force stellte eine Studie über die Art der Schwächen dagegen. Hier wurmt mich folgendes: Die meisten Exploits basieren immer noch auf SQL-Injection, fehlende Input-Validierung, schlechtes Rechte-Management oder Probleme beim Verarbeiten von Datei-Pfaden. Dinge also, die in öffentlichen Repositories, in denen Open Source entwickelt wird, spätestens dem nächsten Entwickler der daraufschaut auffallen sollten.

• Für die Pfade kann ich mir nicht vorstellen, dass es da nicht sauber durchprogrammierte Basisbibliotheken gäbe. Für mich gibts hier eine einfache Regel: Keine Datei-Operationen auf einem Server (ich habe sie auch bisher nicht gebraucht) – kein Stress. Keine Uploads, keine temporären Dateien.
• SQL-Injections: Man verwende einfach durchgehend Maskierung, und die Sache ist geritzt – also wie taub muss ein Entwickler denn im 21. Jahrhundert sein, um so etwas nicht halbwegs zu bedenken? MySQL bietet (nach erfolgreicher Verbindung) sogar eine Funktion dafür an: mysql_real_escape_string($str); Ich selbst benutze ein paar handgeschriebene Funktionen für Datentyp-spezifische Maskierung. Hier kann ich auch mit Casting arbeiten, so brauche ich nicht immer eine Verbindung, und ich kann das Maskierungsverhalten recht fein steuern, zum Beispiel ob NULL erlaubt oder verboten (NOT NULL) ist.
  
• Input-Validierung: Ebenfalls sehr effektiv mit Maskierung, Casting und Längenbegrenzung zu beheben. Das ist nicht schwer. Mein Tipp: Man stelle in der Konfigurationsdatei php.ini den Schalter maqic_quotes_gpc = off, dann gibt es erstmal sauberen Inhalt. Bei einem INSERT INTO ans Maskieren für die DB denken, und bei der Ausgabe an konsequentes Anwenden der Funktion htmlspecialchars($str); (oder htmlentities($str); für Fetischisten) jeglicher Zeichenketten. Und schon gehört dieses Problem der Vergangenheit an.
• Nebenbei kann man in der php.ini eine ganze Reihe von Funktionen deaktivieren. Alle Datei-Funktionen und Funktionen für HTTP-Transport wären gute Kandidaten. Ob die Funktion zum Öffnen einer Datei fopen() auch für URLs benutzt werden darf, darf hier weiterhin getrost verneint werden. Dann die Länge der GET-Parameter, die kann man von 2K sicherlich auf 512 Byte herunterdrosseln, wenn man daran denkt, alles andere konsequent per POST zu machen.
• Es soll ja noch Software aus PHP4-Zeiten geben, die nach dem Umschalten auf register_globals = off nicht mehr richtig tickt. Diese gehört in die nächste greifbare “Standard-Ablage” (/dev/muell) entsorgt. Wer so etwas weiter benutzt, handelt nicht einmal auf eigene Verantwortung, nein er handelt eigentlich komplett verantwortungslos. Zu viele Hoster haben mehr als eine Seite auf dem Server liegen, und es kann durchaus sein, dass man seinen virtuellen Nachbarn mitgefährdet – vor allem bei möglichen Datei-Operationen.

Wer komplexere Seiten baut, braucht sicherlich Sessions. Für die Absicherung gegen das Session-Hijacking ist etwas mehr Grips vonnöten, da eine hundertprozentige Lösung aufgrund der Internet-Architektur leider nicht möglich ist. Als Einstieg kann man diese Basis-Variante für die eigenen Zwecke weiter ausbauen und an seine Befürfnisse anpassen.

Fazit

Der X-Force-Bericht legt uns erst einmal nahe: Wer Drupal, Joomla! oder andere angreifbare PHP-CMS benutzt, begibt sich selbst in Gefahr. Und das zieht den Ruf von PHP zu Unrecht in den Dreck. Eine gut abgesicherte Seite ist mit PHP wirklich nicht schwer. Es gibt genügend tiefergehendes Material zu all diesen Problemen, sogar Dokumente à la “Wie baue ich eine sichere Homepage mit PHP” für absolute Einsteiger. Vorausgesetzt, man nimmt sich am Anfang eines Projekts ein wenig Zeit, spart sich später viel Ärger. Oder anders gesagt: Wer flüchtig tippt, tippt zweimal. 😉

Ich wünsche happy coding!