Nach meinem Blog ist jetzt meine Homepage dran und hat eine Rundumerneuerung bekommen. Sie ist nun auch viel schlichter geworden und soll schnell und unkompliziert einen Überblick über meine Fotografie und meinen Aktivitäten im Netz geben. Feedback ist willkommen und ich bin gespannt ob die Seite gefällt.
Jede sauber programmierte PHP Applikation macht es notwendig, dass Klassen dynamisch nachgeladen werden müssen. Dazu bietet PHP die __autoload() Funktion. Diese wird im Zend Framework natürlich in einem Objekt gekapselt. Nachdem ich den einfachen Weg immer vorziehe, nutze ich natürlich diesen gewöhnlichen Autoloader Mechanismus durch die Klasse Zend_Loader_Autoloader:
$autoloader = Zend_Loader_Autoloader::getInstance();
$autoloader->registerNamespace('application_');
Wird die Zend_Application Klasse verwendet, so wird der Autoloader automatisch aktiviert (die Namespace’s müssen dabei in der Konfiguration gesetzt werden). Verwende ich dann eine Klasse, so wird der Name entsprechend aufgelöst, d.h. zu obigen Beispiel wird bei der Verwendung der Klasse “application_models_items” die Datei “application/models/items.php” eingebunden. Das Problem bei dieser Lösung: hat man ein sehr großes Projekt mit einer tiefen Hierachie, dann wächst der Klassenname entsprechend stark an. Bei meinem RSS Reader rsslounge hab ich das beispielsweise in Kauf genommen, da die Struktur nicht komplex ist. Zudem sieht man am Namen schon sofort, wo die Datei abgelegt ist und welche Funktion die Klasse übernimmt (application_models_items ist ein Model, dass sieht man sofort).
Seit der Version 1.8 bietet das Zend Framework einen eleganten Weg Klassen automatisch zu laden, dabei aber genau zu spezifizieren, wo die Klassen gesucht werden sollen. Dazu wird ein Namespace definiert und für verschiedene “Unter-Namespace” Pfade angegeben. Ein Beispiel veranschaulicht das Vorgehen:
$resourceLoader = new Zend_Loader_Autoloader_Resource(array(
'basePath' => APPLICATION_PATH . '/../einordner',
'namespace' => 'Myproject',
));
$resourceLoader->addResourceType('models', 'models', 'Model');
$var = new Myproject_Model_Xyz();
Zuerst wird die Klasse Zend_Loader_Autoloader_Resource instanziiert. Dabei wird ein Namespace angegeben (im Beispiel “Myproject”) und definiert, in welchem Ordner die zugehörigen Dateien zu finden sind. In einem zweiten Schritt wird dann mit addResourceType ein “Unter-Namespace” definiert und angegeben in welchem Unterverzeichnis die Klassen liegen. Der Aufbau von addResourceType ist wie folgt:
$resourceLoader->addResourceType($name, $ordner, $namespace);
Damit ist der Autoloader für alle Klassen mit dem Präfix “Myproject_Model_” aktiv. Im Beispiel wird eine Klasse Xyz geladen. Dabei wird für die Klasse “Myproject_Model_Xyz” die Datei “APPLICATION_PATH . /’../einordner/models/xyz.php” eingebunden. Es können beliebig viele “Unter-Namespace” definiert werden, was für eigene Klassen wie Models, Forms oder Validatoren sinnvoll ist.
Weitere Informationen und Beispiele sind im Manual zu finden. Keith Pope beschreibt anhand eines Beispiels sehr schön, wie er Zend_Loader_Autoloader_Resource in seinem Projekt verwendet (siehe “Seite 129ff, Zend Framework 1.8 – Web Application Development” von Keith Pope).
Dieser Weg Klassen automatisch zu laden gefällt mir ganz gut, weil er einfach ist und keine spezielle Loader Klasse nötig ist (die z.B. mittels einer statischen Funktion eine Klasseninstanz liefert). Natürlich offenbaren die Namespaces, welche mit PHP 5.3 eingeführt wurden neue Möglichkeiten, die ich mir auch noch genauer ansehen möchte. Oder gibt es eine noch schönere und elegantere Lösung? Dann bitte unbedingt kommentieren!
Seit wenigen Minuten ist die neueste Version 1.3 von meinem kostenlosen, webbasierten RSS Reader rsslounge verfügbar.
Es wurden wieder einige Fehler beseitigt, aber auch neue Features sind auf der Liste der Neuerungen. So gibt es nun Tastenkürzel, mit denen z.B. durch die Einträge navigiert oder Einträge als gelesen markiert werden können. Bei der Wahl der Tastenkürzel habe ich mich am Google Reader orientiert, um es so Umsteiger leichter zu machen. Eine Liste mit allen Tastenkürzel ist hier im Wiki zu finden.
Zudem gibt es zwei neue Einstellungen, mit denen festgelegt werden kann, ob Links in einem neuem Fenster geöffnet werden sollen und ob beim Öffnen externer Links ein Anonymisierungsdienst (z.B. anonym.to) verwendet werden soll.
Das vollständige Changelog könnt ihr ebenfalls im Wiki finden. Zudem habe ich ein RSS Feed für neue Releases eingeführt. Erscheint eine neue Version, so wird dieses Feed aktualisiert.
Wer rsslounge schon installiert hat und aktualisieren will, findet hier eine Anleitung wie das in wenigen Schritten funktioniert: Wiki Update. Wer rsslounge noch nicht benutzt, sollte mal schnell einen Blick darauf werfen. Kann ich nur jedem empfehlen 
Lange ist es her, dass ich etwas an meinem Blog verändert habe. Nun habe ich mich entschlossen meinen Blog von einem selbst entwickelten System auf Wordpress umzustellen. Wenn auch das Backend ordentlich und ausbaufähig war, fehlt mir die Zeit den Blog zu erweitern und mit nützlichen Funktionen anzureichern. Hier macht es einen Wordpress und die große Auswahl an Plugins sehr einfach. Ich bin mir auch noch nicht sicher, was ich von dem Backend von Wordpress halten soll. Doch die Vorteile überwiegen: gut testeter Code, komfortables Backend, leicht anzupassen, viele Plugins usw.
Natürlich bin ich mir im Design treu geblieben und habe den Grünton, der meine Webauftritte nun schon seit 10 Jahren begleitet übernommen. Es soll auch wieder schön schlicht sein und durch Einfachheit und Übersichtlichkeit bestechen. Natürlich darf auch ein stylischer Twitter Vogel (siehe ganz unten) nicht fehlen
Wenn jemand eine Fehlfunktion findet oder mit etwas Probleme hat, dann bin ich über Feedback sehr dankbar. Gerade wenn man etwas neu einführt hackt es immer mal wieder an Details.
Eine große Sache bei der Entwicklung von Webapplikationen ist das Thema Sicherheit. Verfolgt man verschiedene Nachrichtendienste zum Thema Sicherheit, dann stellt man sehr schnell fest, dass zahlreiche Applikationen immer wieder kritische Sicherheitslücken aufweisen. Besonders wenn es sich um OpenSource Software handelt stellt das ein Problem dar, da ein Angreifer den Programmcode einer möglichen Opferapplikation kennt.
Ein Blick in die Literatur offenbart einige grundlegende Bedrohungen, die immer wieder anzutreffen sind:
- SQL Injection: fremde SQL Statements werden in die Opferapplikation eingeschleußt und von dieser ausgeführt
- Command Injection: Einschleusen (Injizieren) bösartiger Befehle zur Kompromittierung der Funktionsschicht
- Cross-Site Scripting: Einschleusen (Injizieren) von bösartigen Programmcode
- Directory Traversal: Technik um an nicht öffentliche, aber zugängliche Daten zu kommen
- Header Injection: Manipulation von dynamisch generierten Header
- Session Hijacking: Technik zur Übernahme einer fremden Session
- Session Fixation: Technik zur Session-Manipulation um Session des Angreifers zu privilegieren
- Cookie Poisoning: Manipulation von Cookies
Eine sehr schöne Übersicht mit möglichen Gegenmaßnahmen zeigt hier das Buch “Pro PHP Security” von Chris Snyder und Michael Southwell auf (apress Verlag, ISBN: 1-59059-508-4).
PHPIDS
Vor einiger Zeit bin ich auf PHPIDS gestoßen, einem Intrusion Detection System für PHP. Dabei handelt es sich um ein Skript, das mittels regulären Ausdrücken und einem generischen Ansatz (Zentrifuge-Ansatz) die übergebenen Parameter (GET, POST, COOKIE, REQUEST) überprüft und mögliche Angriffe erkennt.
Ein erkannter Angriff wird mit einem “Impact” Wert gekennzeichnet, der angibt, wie schwerwiegend der Angriff ist. Ein Impactwert von 2-5 ist unbedenklich, wobei ein Impact 15 schon sehr hoch ist und eine Reaktion erfordert. Ein sehr hoher Wert (25-50) macht eine Reaktion unbedingt erforderlich. Dabei kommt PHPIDS auch mit exotischen Zeichensätze (UTF-7), JavaScript Unicode, dezimal und hexcode usw. zurecht und erkennt alle gängigen Angriffsmuster wie SQL Injection, Cross-Site Scripting Attacken oder Directory Traversal Zugriffe.
PHPIDS steht unter LGPL und kann unter http://php-ids.org frei heruntergeladen werden.
Arbeitsweise
PHPIDS besitzt eine Liste von Filterregeln. Diese definieren reguläre Ausdrücke, welche gängige Angriffmuster erkennen. Dazu wird der Angriff mit einem Tag und einem Impactwert gekennzeichnet. Greifen mehrere Filterregeln, dann werden die einzelnen Impactwerte aufkummuliert. Um neue, unbekannte Angriffe zu erkennen, wird ein Zentrifuge-Ansatz verwendet, d.h. ist ein Parameter ein String von der Mindestlänge von 40 Zeichen, dann wird dieser String durch geschickte Zeichenersetzung auf eine repräsentative, kurze Zeichenkombination reduziert. Hierbei werden:
- alle Wortzeichen sowie Whitespace (berücksichtigt Unicode) entfernt
- mehrfach vorkommende Zeichen werden gestrippt
- bestimmte Zeichengruppen durch festgelegte Zeichen ersetzt (Ziel: Anzahl unterschiedliche Zeichen gering halten)
- unerwünschte Zeichen (z.B. Backslash aus Magic-Quotes-Funktion) entfernt
Das Ergebnis ist ein String aus 4 bis 6 Zeichen. Cross Site oder Code Injection Angriffe führen dabei erstaunlicherweise immer wieder auf ein ähnliches Muster. Taucht ein solches Muster (z.B. “((+::”) auf, so schlägt PHPIDS Alarm.
Installation
Die Installation ist denkbar einfach. In der zentralen Bootstrap Datei einer Applikation werden die PHPIDS Klassen geladen, alle Parameter als Array übergeben und das Ergebnis ausgewertet. Die Reaktion kann selbst ausgestalltet werden und kann von einfachen Logging (PHPIDS bringt hier bereits eine Hilfsklasse mit) bis hin zum Sperren der IP Adresse reichen.
Einbinden und Starten von PHPIDS:
$request = array(
'REQUEST' => $_REQUEST,
'GET' => $_GET,
'POST' => $_POST,
'COOKIE' => $_COOKIE
);
require_once 'IDS/Init.php';
$init = IDS_Init::init('/IDS/Config/Config.ini.php');
$ids = new IDS_Monitor($request, $init);
$result = $ids->run();
// Angriff erkannt? Loggen und Abbruch
if (!$result->isEmpty()) {
require_once 'IDS/Log/File.php';
require_once 'IDS/Log/Composite.php';
$compositeLog = new IDS_Log_Composite();
$compositeLog->addLogger(IDS_Log_File::getInstance($init));
$compositeLog->execute($result);
die("ids error ".$result->getImpact());
}
Hat die eigene Applikation keine Bootstrap Datei, so kann mit Hilfe der PHP Option “auto_prepend_file” eine Datei angegeben werden, die immer vor der eigentlichen PHP Datei geparst wird. Diese kann unter Apache auch in der .htaccess gesetzt werden:
php_value auto_prepend_file phpids.php
phpids.php muss dann den oben stehenden Programmcode enthalten und PHPIDS ausführen.
Hat man beispielsweise einen Blog, wo tatsächlich HTML eingegeben und übertragen wird (z.B. in der Administrationsoberfläche beim Erstellen neuer Blogeinträge), so muss das PHPIDS hier bescheid wissen, da es sonst Alarm schlägt. Hierzu können in der Konfiguration Parameter festgelegt werden, die HTML enthalten dürfen. Ebenso schlägt PHPIDS bei der Verwendung von Google Analytics Alarm. Dieses ist zwar schon vorkonfiguriert, ich musste es aber immer nochmal für REQUEST und COOKIE konfigurieren:
exceptions[] = REQUEST.__utmz exceptions[] = REQUEST.__utmc exceptions[] = COOKIE.__utmz exceptions[] = COOKIE.__utmc
Performance
Natürlich hat PHPIDS auch eine Auswirkung auf die Performance der Applikation. Hier haben die Entwickler verschiedene Szenarien getestet und es hat sich gezeigt, dass PHPIDS lediglich 0,5 % der gesamten Rechenzeit benötigt, wenn z.B. von einer CakePHP Applikation ausgegangen wird. Selbst wenn man davon ausgeht, dass die Zahlen geschönt sind, ergibt sich aus meiner Sicht hier trotzdem kein Problem. Nimmt man beispielsweise einen privaten Weblog, der auf Wordpress basiert, dann dürften sich hier die Besucherzahlen in Grenzen halten und das IDS nicht ins Gewicht fallen.
PHPIDS berücksichtigt das Performanceproblem bereits und verzichtet darauf z.B. den Zentrifuge-Ansatz auf kurze Strings anzuwenden. Zudem beschränkt es sich auf Strings: Integer Werte werden beispielsweise nicht geprüft. Wer trotzdem noch optimieren will, dem bietet PHPIDS ein Caching Mechanismus, so dass die Liste mit den Filterregeln nicht jedes mal neu geparst werden muss. Zudem liegen die Filterlisten nicht nur als XML Datei vor, sondern auch im JSON Format, welches bedeutend schneller geparst wird.
Literatur und Links
- c’t magazin 2009 Heft 10: Alarmanlage – Angriffe auf Webanwendungen mit PHPIDS erkennen, Christian Matthies, 27.04.2009
- PHPIDS Webseite: http://php-ids.org/
Heute ist mein Gastbeitrag auf php hates me erschienen. An der Stelle vielen Dank an Nils, dass er mir Gelegenheit gibt rsslounge vorzustellen. Und jetzt schnell zum Beitrag:
Jedes Jahr gibt es ein Feature zu den schönsten Bilder von deviantArt. Hier die Highlights von 2009.
