zur Fotoserie: munich 3 to 8

Wer meinen Blog liest, kennt phphatesme bereits von meinem Gastbeitrag über rsslounge. Jedem anderen empfehle ich einen Blick auf den Blog zu werfen, der täglich interessante Themen aus der Softwareentwicklung mit PHP aufgreift.

Slide Effekte und Carousel Skripte gibt es im Internet viele, überzeugen konnte mich keines. Meistens sind sie zu umfangreich oder es ist spezielles CSS notwendig, das dann unüberschaubar eingebunden bzw. die eigene Struktur daran angepasst werden muss. Nachdem jQuery sehr komfortabel ist und ich die meisten meiner Projekte auf jQuery aufbauen, habe ich mich entschlossen selbst ein einfaches jQuery Plugin zu schreiben. Dieses kommt ohne spezielles CSS aus und ist mit 1,8 kB auch schön kompakt.

Das Skript erwartet folgende HTML Struktur:

<ul id="carousel">
 <li>erster Frame (z.B. ein Bild)</li>
 <li>zweiter Frame (z.B. ein Bild)</li>
 <li>dritter Frame (z.B. ein Bild)</li>
 <li>vierter Frame (z.B. ein Bild)</li>
 ...
</ul>

Um nun aus der Liste ein carousel zu machen, reicht beispielsweise folgender Aufruf aus:

$("#carousel").simplecarousel({
 slidespeed: 700,
 auto: 5000,
 width: 480,
 height: 280
});

In obigen Fall ist das carousel 480×280 Pixel groß, wechselt automatisch alle 5 Sekunden zum nächsten Frame und der Wechsel (Geschwindigkeit des slide Effektes) dauert 0,7 Sekunden.

Es werden folgende Parameter unterstützt:

• width: (int) Breite
• height: (int) Höhe
• next: (jQuery Objekt/Selector) wird auf dieses Objekt geklickt, wird der nächste Frame aufgerufen
• prev: (jQuery Objekt/Selector) wird auf dieses Objekt geklickt, wird der vorhergehende Frame aufgerufen
• vertical: (boolean) true = vertikales carousel; false = horizontales carousel
• auto: (int/boolean) false = kein automatischer Wechsel; Wert in Millisekunden = pause bis automatisch zum nächsten Frame gewechselt wird
• slidespeed: (int) Geschwindigkeit des Wechsels in Millisekunden

Demo:

• rsslounge
• www.aditu.de

Download:

• komprimiert: simple.carousel.0.1.min
• unkomprimiert: simple.carousel.0.1

$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!

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

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.

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:

1. alle Wortzeichen sowie Whitespace (berücksichtigt Unicode) entfernt
2. mehrfach vorkommende Zeichen werden gestrippt
3. bestimmte Zeichengruppen durch festgelegte Zeichen ersetzt (Ziel: Anzahl unterschiedliche Zeichen gering halten)
4. 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/