© saicle/Shutterstock.com
Wie hat sich die Sicherheit von PHP im Laufe der Zeit verbessert?

PHP-Sicherheit von PHP 4.x bis PHP 5.5


PHP erreicht Version 5.5 – Zeit, einmal nachzusehen, wie sich PHP im Laufe seiner Entwicklung im Hinblick auf die Sicherheit weiterentwickelt hat.

Die meisten Schwachstellen in Webanwendungen befinden sich in den Webanwendungen selbst. Aber auch die verwendete Programmiersprache und die eingesetzten Bibliotheken und Frameworks haben Auswirkungen auf die Sicherheit der Anwendung. PHP galt lange Zeit als unsichere Sprache, PHP-Anwendungen als chronisch unsicher. Was aber eigentlich nie an PHP selbst lag, sondern an den Anwendungsentwicklern und Administratoren. Denn was kann PHP dafür, wenn die Entwickler Schwachstellen programmieren und die Administratoren das Ganze dann auch noch unsicher konfigurieren? Trotzdem wurde auch PHP selbst im Laufe der Zeit immer sicherer. Werfen wir einen Blick auf diese Verbesserungen.

Ein Klassiker: register_globals

Ein ständiges Ärgernis waren die automatisch als globale Variablen registrierten GET-, POST- und Cookie-Variablen. Die Beschreibung von register_globals liest sich eigentlich ganz harmlos [1]: „Bestimmt, ob die EGPCS (Environment/Umgebung, GET, POST, Cookie, Server) Variablen als globale Variablen registriert werden sollen.“

Das klingt doch unheimlich praktisch – alle Variablen sind sofort verfügbar, es ist kein mühsamer Import über $_GET. $_POST, $_COOKIE nötig. Wer sollte also etwas dagegen haben? Nun, jeder, der Wert auf Sicherheit legt. Denn wenn diese Variablen alle automatisch registriert werden, bedeutet das auch, dass ein Angreifer jede beliebige Variable mit jedem beliebigen Wert in die Webanwendung einschleusen kann. Nun ist das ebenso harm- wie zwecklos, wenn es diese Variable im Skript eigentlich nicht gibt. Das Skript kennt sie nicht und verwendet sie auch nicht. Aber was passiert, wenn eine Variable eingeschleust wird, die existiert? Normalerweise initialisiert man Variablen, bevor man sie zum ersten Mal verwendet. Aber wenn das nicht passiert, kann ein Angreifer bei aktivierten register_globals einen Wert nach seiner Wahl in diese Variable schreiben. Und das kann sehr gefährlich sein.

Die besten Beispiele liefert das Leben

Vielleicht erinnern Sie sich ja noch daran: Vor einigen Jahren gab es mal eine Vielzahl von Security Advisories zu und Exploits für Mambo-/Joomla!-Erweiterungen, die für Remote File Inclusion, also das Einbinden von PHP-Skripten vom Server eines Angreifers, anfällig waren. Das hatte zwei Ursachen: Zum einen stand ganz am Anfang der Erweiterungsskripte die Zeile require($mosConfi...

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