Die Problemstellung

Nun aber zum Thema: für ein aktuelles Projekt benötige ich, von meiner PHP Webapplikation heraus, den Zugriff auf einige Hardwarekomponenten. Zudem will ich einige Fremdbibliotheken verwenden, die sehr rechenintensive Aufgaben übernehmen und auch nur in C++ zur Verfügung stehen. Die Frage ist also: wie kann ich diese Komponenten an mein PHP Programm ankoppeln?

Für Java gibt es eine ganz gute Server Bridge, die innerhalb der Java Virtual Machine einfach einen kleinen Server startet, der XML Anfragen entgegen nimmt, stellvertretend ausführt und das Ergebnis, auch wieder über eine XML Kommunikationsschnittstelle, zur Verfügung stellt. Die nötige PHP Klasse wird ebenfalls durch den Java Server direkt zur Verfügung gestellt. Eine ähnliche Bridge Lösung bringt auch der Zend Server bereits out of the box mit.

Für C++ habe ich so eine Lösung nicht gefunden und als weiteren Ansatz überlegt, eine PHP Extension zu entwickeln. Sowohl für Linux, als auch für Windows, gibt es hier Tutorials (siehe “Extension-Entwicklung unter WAP“, “Wrapping C++ Classes in a PHP Extension” oder “Extension Writing Part I: Introduction to PHP and Zend“). Allerdings ist, neben den Tutorials, der ganze Vorgang nicht gut dokumentiert und scheinbar muss das Kompilat der Extension exakt dem des verwendeten PHP Kompilats entsprechen. Insgesamt also eher eine wackelige Angelegenheit.

Lösungsansatz

Meine Lösung ist hingegen pragmatisch und verfolgt eine eher losere Kopplung: Meine C++ Komponenten werden in ein eigenständiges Programm ausgelagert, das selbst, über einen gewöhnlichen HTTP Server, die benötigten Dienste zur Verfügung stellt. Dabei orientiere ich mich an dem REST Architektur Prinzip und binde jeweils eine Teil-Funktionalität an eine feste URL. Die Parameter und Rückgabewerte werden mittels JSON kodiert. Von PHP Seite aus, wird der Aufruf der C++ Komponenten sauber gekapselt, so dass für das PHP Programm der Eindruck entsteht, dass eine gewöhnliche Funktion aufgerufen wird.

Welche Vor- und Nachteile hat das Vorgehen? Zum einen ist die in C++ implementierte Funktionalität sauber gekapselt und von der Webapplikation getrennt. Dadurch wird die Software leichter wartbar. Durch eine saubere Schnittstellendefinition, kann die C++ Serverkomponente auch unabhängig vom Wissen über die PHP Applikation gepflegt werden. Zum anderen entsteht aber ein zusätzlicher Aufwand (mit zusätzlichen Fehlerquellen). Die Schnittstelle muss definiert und implementiert werden, ein Fehlerhandling muss durchgeführt werden und eine zusätzliche Serverapplikation muss gestartet werden, was hinsichtlich der Sicherheit berücksichtigt werden muss. Dennoch halte ich die Lösung für die eleganteste, denn sie nutzt genau die Vorteile der Vernetzung und der losen Kopplung aus. So könnte die C++ Komponente bei höherer Last auch leicht auf einen eigenen Server umgezogen oder unabhängig von der Webapplikation betrieben werden.

Implementierung

In der Theorie hört sich natürlich immer alles ganz nett an, aber wie sieht das mit dem HTTP Server aus? Hier gibt es eine hervorragende C++ Bibliothek, mit der sich ohne großen Aufwand eine solcher HTTP Server realisieren lässt. mongoose heißt das Wunderding, steht unter der MIT Lizenz unter Google Code zur Verfügung. Es unterstützt Windows, Linux und Mac OS X, bietet eine CGI Schnittstelle, SSL Verschlüsselung, ACL, eine saubere API und ist nicht größer als 60 kB. Die Dokumentation ist zwar recht knapp, aber dank Beispiele findet man sich schnell zurecht und auch die API Beschreibung ist vollkommen ausreichend.

Will man einen eigenen Server starten, so muss zuerst ein neuer Context erzeugt werden:

struct mg_context* ctx;
ctx = mg_start();

Mit mg_set_options, werden die Servereinstellungen geändert. Folgende zwei Zeilen deaktivieren das Directory Listing und setzten 8080 als Port.

mg_set_option(ctx, "dir_list", "no");
mg_set_option(ctx, "ports", "8080");

Aus Sicherheitsgründen erlaube ich nur einen Zugriff vom selben Rechner aus, also erlaube nur die IP Adresse 127.0.0.1:

mg_set_option(ctx, "acl", "-0.0.0.0,+127.0.0.1");

Mit mg_set_uri_callback kann ein Pointer auf eine eigene Funktion an eine URL gebunden werden. Diese wird aufgerufen, wenn der Client die URL aufruft, wobei die URL auch Wildcards enthalten kann.

mg_set_uri_callback(ctx, 'dosomething', &Server::dosomething, NULL);

Als dritter Parameter darf ein Pointer (void*) auf ein beliebiges Objekt übergeben werden. Die Callback Methode bekommt dazu alle notwendigen Parameter, wie die aktuelle Verbindung, den aktuellen Request und das zuvor übergebene Objekt (hier NULL) übergeben.

void Server::capture(struct mg_connection *conn,
 const struct mg_request_info *request_info,
 void *user_data) {
char* param = mg_get_var(conn, "param");
mg_printf(conn, "%s", "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\n\r\n");
}

Mit mg_printf kann dann eine Antwort an den Client gesendet werden. Hier als einfaches Beispiel einfach nur ein OK (HTTP 200). In meinem Szenario wird hier der generierte JSON Text zurück gegeben. Mit mg_get_var können übergebene Parameter (POST, GET) ausgelesen werden. Wichtig: um memory leaks zu vermeiden, müssen diese mit mg_free wieder freigegeben werden.

Natürlich ist das nur die eine Hälfte. PHP muss jetzt auch Funktionen, auf dem Server, aufrufen können. Dazu kommt der Zend_Http_Client zum Einsatz. Dieser ist im Zend Framework enthalten, mit etwas Frickelei kann er aber auch aus dem Gesamtpaket heraus gepickt werden. Da ich aber das Zend Framework für die ganze Anwendung nutze, ist das Aufrufen der URL und das Decodieren des JSON Strings in einen Action Helper ausgelagert, der gleichzeitig eine einfache Fehlerbehandlung durchführt:

class JsonHttpHelper extends Zend_Controller_Action_Helper_Abstract {
   public function get($url, $params = array()) {
      try {
         $client = new Zend_Http_Client($url);
         foreach($params as $param=>$value)
            $client->setParameterPost($param, $value);
            $response = $client->request('POST');
            $res = Zend_Json::decode($response->getBody());
            if($response->isSuccessful()) {
               return $res;
            } else {
               return array("error" => "request not successfully: ".$res["error"]);
            }
      } catch(Exception $e) {
         return array("error" => $e->getMessage());
      }
 }
}

Bisher bin ich mit der Lösung sehr zufrieden. Besonders mongoose kann ich nur wärmstens empfehlen. Auch von der Verarbeitungsgeschwindigkeit ist das Ergebnis zufriedenstellend und kann sich sehen lassen. Um den Rahmen nicht zu sprengen, habe ich die serverseitige Generierung und Verarbeitung von JSON außen vor gelassen. Hier gibt es aber auch zahlreiche Bibliotheken, so dass die Suche nicht schwer fallen dürfte.

phpQuery greift die Vorgehensweise von jQuery auf und bietet eine zentrale Funktion an, mit deren Hilfe DOM Elemente in einem Dokument selektiert werden können. Beispielsweise liefert die folgende Funktion alle ‘ul’ Elemente.

$uls = pq('ul');

Mit phpQuery hat man natürlich auch die Möglichkeit, wie bei jQuery auch DOM Elemente zu manipulieren, zu löschen oder neue einzufügen.

Will man also beispielsweise alle Suchergebnisse von Google abgreifen, so reicht folgender Code aus, der dann alle gefundenen URLs ausgibt:

require('phpQuery/phpQuery.php');
$q = "phpquery";
$doc = phpQuery::newDocument(
	file_get_contents('http://www.google.com/search?q='.urlencode($q))
);
foreach(pq('.g', $doc) as $entry) {
	$url = pq($entry)->find('.r a')->attr('href');
	$title = pq($entry)->find('.r a')->html();
	echo '<a href="'.$url.'">'.$title.'</a><br />';
}

Mir gefällt der Ansatz, die Funktionalität von jQuery teilweise in die Welt von PHP zu übertragen. Jeder, der in irgendeiner Form HTML in PHP verarbeiten muss, sollte sich diese Bibliothek auf jeden Fall genauer ansehen.

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
• visible: (int) Anzahl an Frames die gleichzeitig sichtbar sein sollen
• fade: (int) wird dieser Wert angegeben, so wird anstatt zu sliden das Frame ausgeblendet und das neue wieder eingeblendet. Die Geschwindigkeit des fade Effektes ist dann dieser Wert (siehe aditu.de)

Demo:

• rsslounge
• aditu.de Fotografie (fade Effekt)
• aditu.de Projects (slide Effekt)

Download:

• simple.carousel.0.2

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/

Was ist ein Einmalpasswort?

Wie der Name bereits sagt, kann ein Einmalpasswort nur für einen Login verwendet werden. Dann erlischt die Gültigkeit und ein neues Einmalpasswort wird benötigt. Ein solches Passwort wird durch eine spezielle Hardware (hier OpenKubus Stick) erzeugt. Eine genaue Definition findet ihr auch in Wikipedia, wo auch verschiedene Algorithmen vorgestellt werden. Der englischsprachige Begriff ist One Time Passwort und hierzu findet man auch auf dem internationalen Wikipedia eine interessante Beschreibung.

Vorteile Einmalpasswörter

Zu Beginn stellt sich die Frage, welche Vorteile ein Login mit Einmalpasswörter mit sich bringt. Hier macht es Sinn, sich der Problemstellung von Seite der Bedrohungen aus zu nähern und zu analysieren, ob ein solches System für den eigenen Anwendungsfall eine sinnvolle Maßnahme ist oder nicht. Mögliche Bedrohungen, gegen die ein Einmalpasswort eine risikominimierende Wirkung hat sind:

• an erster Stelle natürlich eine sichere Authentifikation: nur wer den Stick besitzt kann sich auch in das System einloggen
• ungeeigneter Umgang mit Passwörter: es kann nicht sichergestellt werden, dass Benutzer unsichere Passwörter verwenden
• Abhören von Leitungen/Ausspähen des Passwortes: es kann passieren, dass in einer unsicheren Umgebung die eigenen Zugangsdaten abgehört werden. Hier wäre auch eine verschlüsselte Verbindung eine empfehlenswerte Gegenmaßnahme, aber auch ein Einmalpasswort bietet hier einen geeigneten Schutz, da dieses nur für einen Login gültig ist.
• systematisches Ausprobieren von Passwörter: es kann passieren, dass ein Brute Force Angriff auf das System durchgeführt wird. Ein Einmalpasswort ist in der Regel sehr lange und somit schwerer zu knacken
• Trojanische Pferde: am Clientrechner könnte ein Schadprogramm installiert sein, welches die Zugangsdaten ausspäht

Natürlich ist ein Einmalpasswort kein Allheilmittel. So schützt es nicht vor Pishing Angriffen, oder Man in the Middle Attacken, wo die Logindaten abgefangen und erst garnicht an den Server gesendet werden.

Komponenten

An dieser Stelle will ich zuerst die verschiedenen Komponenten vorstellen, die für die Lösung verwendet wurden. Natürlich ist alles OpenSource und frei verfügbar. Auch der Hardwaredongle ist frei und recht günstig zu erstehen.

OpenKubus

Der OpenKubus ist ein kleiner, handlicher USB Stick (der Problemlos an den Schlüsselbund passt), dessen Hardwarelayout frei verfügbar ist und der frei programmiert werden kann. Wird der Stick an einem Rechner angesteckt, so wird er als Tastatur erkannt. Ein Druck auf einen Taster führt dazu, dass der Stick ein neues Einmalpasswort generiert und als Tastatureingabe an den Rechner sendet. Es reicht also, den Cursor auf das Eingabefeld im Login Formular zu setzen und der Stick schießt sein Passwort hinein. Dabei ist der Stick kompatibel zu nahezu allen Systemen, weil er als einfache Tastatur arbeitet.

Der Stick kostet 24,95 Euro und kann im embedded projects Shop bestellt werden. Beispielprogramme und die nötige Software um den Stick zu programmieren (was unter Linux recht leicht möglich ist), sind auf der google code Projektseite zu finden. Dort gibt es auch Anleitungen und ein Beispielserver in Perl. Der OpenKubus kann auch für einen sicheren Linux Login (PAM) verwendet werden.

phpseclib

Um das Passwort zu entschlüsseln (AES), benötigt man eine passende Bibliothek. phpseclib bietet eine komfortable und objektorientierte Lösung, die auf keine PHP Extensions oder ähnliches angewiesen ist. Diese Bibliothek ist in PHP geschrieben, entwickelt man in einer anderen Sprache, so benötigt man irgendwie eine Möglichkeit mit AES Verschlüsselung zu arbeiten.

phpseclib ist aus meiner Sicht für Verschlüsselung allgemein ein Tipp. Es stehen Klassen für die verschiedensten Algorithmen zur Verfügung (z.B. RSA, SSH, DES, 3DES, AES uvm.). Die Bibliothek ist OpenSource und steht unter der LGPL Lizenz.

Ablauf

Um die unten stehende Implementierung zu verstehen, muss man zuerst den gesamten Ablauf kennen. Dieser ist recht simpel. Zuerst muss der Stick einmalig vorbereitet werden. Der Authentifizierungsprozess kann dann beliebig oft durchgeführt werden.

Initialisierung

Der Stick muss mit dem AES Schlüssel und einem zufälligen Datenblock beschrieben werden. Dies funktioniert recht einfach unter Linux:

sudo ./stick-write -p AESKeyundDatenblock

Wobei AESKeyundDatenblock ein 46 Byte langer String ist, der zuerst aus dem AES Key (32 Bytes lang) und dann dem Datenblock (14 Bytes lang) besteht. Der AES Schlüssel und der Datenblock müssen auch dem Server bekannt sein. Zudem muss auf dem Server der Zähler auf 0 gesetzt werden (=das nächste Einmalpasswort ist das erste).

Authentifizierung

Client:

1. Der Stick wird am Client eingesteckt und das Loginformular wird aufgerufen. Nun gibt der Benutzer seinen Benutzernamen ein, setzt den Cursor auf das Einmalpasswort-Feld und drückt auf den Taster am Stick.
2. Der Stick erzeugt nun das Einmalpasswort: Ein interner Zählwert wird mit dem Datenblock verknüpft und mit dem angegebenen Schlüssel (key) AES verschlüsselt. Anschließend erhöht der Stick seinen internen Zähler um eins.
3. Das so generierte Einmalpasswort wird base64 kodiert, so dass es durch gewöhnliche (ASCII) Zeichen darstellbar ist.
4. Der Stick sendet das so generierte, base64 kodierte Einmalpasswort als Tasteneingabe und befüllt so das selektierte Feld. Ein Klick auf “Login” sendet das HTML Formular wie bei einem gewöhnlichen Login an den Server.

Server:

1. Der Server nimmt die Anfrage entgegen und lädt seinen eigenen, zum Stick passenden AES Schlüssel und Datenblock.
2. Dann wird der durch den Client übermittelte base64 String erst einmal korrigiert: ein z am Anfang kennzeichnet ob ein amerikanisches Tastaturlayout vorliegt (entsprechend müssen alle z durch y und alle y durch z ersetzt werden). Zudem werden einige Sonderzeichen ersetzt.
3. Anschließend wird das noch verschlüsselte Einmalpasswort von base64 wieder in einen Bytevektor dekodiert.
4. Nun wird das Einmalpasswort mit AES entschlüsselt.
5. der Zählstand wird ausgelesen und der Datenblock entnommen.
6. Der Login ist erfolgreich wenn der gegebene Zählstand größer dem Zählstand am Server ist und der gegebene Datenblock mit dem intern gespeicherten übereinstimmt.
7. War der Login erfolgreich, so wird am Server der Zählstand des Sticks übernommen: es werden nur Einmalpasswörter akzeptiert, die einen höheren Zählstand haben (alte funktionieren also nicht mehr).

Auch wenn sich alles nun nach einer Menge Arbeit anhört, ist die Implementierung übersichtlich. Ich habe dazu in meiner Applikation einen Action Helper verwendet (in Zend Framework Applikationen eine Hilfsklasse, die in allen Controller zur Verfügung steht). An dieser Stelle eine PHP Funktion, welche nur von phpseclib abhängt und alle Schritte durchführt, die oben unter Server gelistet sind. Jeder Schritt wird nochmal als Kommentar erklärt.

/**
 * @param string $givenOtp Einmalpasswort, dass geprueft werden soll
 * @param string $aesKey der AES Schluessel und Datenteil
 * @param int $number aktueller Zaehlstand des Servers
 */
function otp($givenOtp, $aesKey, $number) {
	// AES Schluessel besteht aus
	// erste 32 Byte: AES Key
	// restliche 14 Byte: Datenblock
	$key  = substr($aesKey, 0, 32);
	$data = substr($aesKey, 32, 14);

	// base64 Kodierung des Sticks korrigieren
	$givenOtp = rtrim($givenOtp);

	// Sonderzeichen in korrekte Sonderzeichen umwandeln
	// (diese werden vom Stick anders vorgegeben, um von
	// unterschiedl. Tastaturlayouts unabhängig zu werden)
	for($i = 0; $i < strlen($givenOtp); $i++) {
		if($givenOtp[$i] == " ") { $givenOtp[$i] = "/"; }
		elseif($givenOtp[$i] == ".") { $givenOtp[$i] = "="; }
		elseif($givenOtp[$i] == "-") { $givenOtp[$i] = "+"; }
	}

	// erstes Zeichen pruefen ob z oder y
	// abhaengig davon alle y durch z ersetzen und umgekehrt
	$z = $givenOtp[0];
	$crypted = substr($givenOtp, 1);

	if($z == "y" or $z == "Y") {
		for($i = 0; $i < strlen($crypted); $i++) {
		  if	($crypted[$i] == 'y') { $crypted[$i] = "z"; }
		  elseif($crypted[$i] == 'Y') { $crypted[$i] = "Z"; }
		  elseif($crypted[$i] == 'z') { $crypted[$i] = "y"; }
		  elseif($crypted[$i] == 'Z') { $crypted[$i] = "Y"; }
		}
	}

	if($z == "Y" or $z == "Z") {
		for($i = 0; $i < strlen($crypted); $i++) {
			if(ctype_upper($crypted[$i])) {
				$crypted[$i] = strtolower($crypted[$i]);
			} else {
				$crypted[$i] = strtoupper($crypted[$i]);
			}
		}
	}

	// base64 String nun in binary dekodieren
	$crypted = base64_decode($crypted);

	// gegebenes One Time Passwort mit AES entschluesseln
	$aes = new Crypt_AES();
	$aes->disablePadding();
	$aes->setKey($key);
	$plain = $aes->decrypt($crypted);

	// entschluesseltes Passwort aufteilen in

	// aktueller Zaehlstand
	$i	 = substr($plain, 0,1);
	$j	 = substr($plain, 1,1);
	$n	 = ord($i) + (ord($j) << 8);

	// und Datenblock
	$plain = substr($plain, 2, strlen($plain)-2);

	// wenn Datenblock korrekt und Laufnummer nach aktueller Nummer:
	// aktuelle Nummer zurueckgeben (Login korrekt)
	if(($plain == $data) and ($n > $number)) {
		return $n;
	} else {
		return false;
	}
}

Natürlich kann das Entschlüsseln auch mit der mcrypt Erweiterung von PHP durchgeführt werden. So benötigt man keine zusätzliche Bibliothek wie phpseclib. Um das Passwort mit mcrypt zu entschlüsseln, muss der Codeteil

$aes = new Crypt_AES();
$aes->disablePadding();
$aes->setKey($key);
$plain = $aes->decrypt($crypted);

durch die entsprechenden mcrypt Aufrufe ersetzt werden:

$td = mcrypt_module_open("rijndael-128", "", "ecb", "");
$iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($td), MCRYPT_DEV_RANDOM);
mcrypt_generic_init($td, $key, $iv);
$plain = mdecrypt_generic($td, $crypted);

Fazit

Ich bin mit der Lösung sehr zufrieden. Die AES Schlüssel/Datenblöcke lassen sich komfortabel in der Datenbank ablegen und auch leicht ändern, falls der Stick verloren geht. Besonders wenn man oft in unsicheren Netzen unterwegs ist (z.B. in der Firma oder an der Uni, in Internet Cafes usw.) ist die Lösung praktisch. Es müssen keine langen Einmalpasswörter von einem Display abgeschrieben werden und der Stick läuft gleichermaßen unter Linux und Windows. Die Integration in die eigene Applikation ist denkbar einfach.

Einziger Nachteil: der Stick hat keine Zeitkomponente, d.h. jemand könnte das Passwort abgreifen und dann die Netzverbindung kappen. Erst wenn sich der Besitzer einloggt, wird das zuvor abgepishte Passwort ungültig. Ebenso lassen sich mehrere Passwörter auslesen: so lange der Besitzer sich nicht einloggt, bleiben sie alle gültig.

Ralf beschreibt in seinem Buch eine gute Möglichkeit eine auf dem Zend Framework basierende Applikation modular zu strukturieren (mit Teilmodule, die nach belieben eingefügt oder ausgehängt werden können). Häufig ist aber auch das zu weit gefasst und eine viel klarere und schmalere Schnittstelle reicht vollkommen aus. Gesucht ist also ein Mechanismus, der Teilfunktionen dynamisch nachlädt und in die Gesamtapplikation einbindet.

Ein Beispiel: mein webbasierter RSS Reader rsslounge kann verschiedene Quellen verfolgen und verarbeiten. So liest er gewöhnliche RSS Feeds. Aber weiterführend kann er auch RSS Feeds als Quelle für Bilder verarbeiten (und extrahiert aus diesen RSS Feeds nur die Bilder). Möglich ist aber auch deviantArt als Datenquelle. Sprich jede mögliche Datenquelle ist denkbar. Nicht nur RSS Feeds, sondern auch normale HTML Seiten (die in irgend einer Weise geparst werden) oder auch der Zugriff auf einen Email Account wäre denkbar. Es macht also Sinn hier eine Abstraktionsebene einzubauen und die Möglichkeit zu schaffen einfach neue Datenquellen hinzuzufügen.

Die Vorgehensweise, welche ich für rsslounge gewählt habe ist simpel: jede Datenquelle ist eine Klasse, welche eine fest vorgegebene abstrakte Basisklasse (rsslounge_source) implementieren muss. Diese abstrakte Basisklasse gibt die Methoden vor, die unbedingt angeboten werden müssen (z.B. load() um die Datenquelle abzurufen).

abstract class rsslounge_source {
	abstract public function load($url);
	abstract public function getHtmlUrl();
	abstract public function getId();
	//...
}

Alle Datenquellen, welche die abstrakte Basisklasse implementieren, werden in einem festen Verzeichnis abgelegt. Die Gesamtapplikation durchsucht diesen Pfad nach verfügbare Datenquellen, prüft, ob sie die nötige Basisklasse implementieren und verwendet sie dann im Programm. Soll beispielsweise ein neues Feed hinzugefügt werden, so werden alle verfügbaren Datenquellen gesucht und im Dialog gelistet:

Angenommen ich entschließe mich ein Jahr später eine neue Datenquelle für die API von Google Analytics zu realisieren, so muss ich lediglich eine neue Klasse von rssloung_source ableiten, die entsprechenden Methoden implementieren und diese dann in das Verzeichnis ablegen.

Dieses Prinzip wird auch Hollywood Prinzip genannt: “Don’t call us, we call you”. Die Datenquelle Klasse bietet Methoden an, welche von der Gesamtapplikation im Bedarfsfall aufgerufen werden. Das Plugin muss von der Gesamtapplikation nichts wissen und ausschließlich ihre eigene Funktionalität und damit die Schnittstelle realisieren.

Die Implementierung basiert auf den Reflection Mechanismus der seit PHP 5 zur Verfügung steht. Mit Hilfe der Reflection Klassen können zur Laufzeit Klassen geladen und deren Eigenschaften ausgelesen werden. Zudem kann über diesen Weg die Klasse dann auch instanziiert werden:

$class = new ReflectionClass("plugin_rss_feed");
$baseClass = new ReflectionClass("rsslounge_source");
$class->isSubclassOf($baseClass); // true wenn plugin_rss_feed die Klasse rsslounge_source implementiert
$obj = $class->newInstance();

Sollen, wie im obigen Beispiel, alle verfügbaren Datenquellen gelistet werden, so wird das Verzeichnis mit den Datenquellen nach PHP Dateien durchsucht, geprüft ob diese von rsslounge_source abgeleitet sind und falls dies zutrifft instanziiert. Alle Objekte der so gefundenen Klassen werden in ein Array gespeichert und dann für die weitere Verarbeitung an die Gesamtapplikation übergeben (die diese Klassen dann auflistet):

$pluginLocation = "/plugins";
$pluginPrefix = "plugins_";
$plugins = array();
foreach(scandir($pluginLocation) as $file) {
	if(is_file($pluginLocation . "/" . $file)
	&& substr($file,0,1)!="."
	&& strpos($file,".php")!==false) {

		$classname = str_replace(".php","",$file);
		$class = new ReflectionClass($pluginPrefix.$classname);

		if($class->isSubclassOf(new ReflectionClass("base_plugin")))
			$plugins[$pluginPrefix.$classname] = $class->newInstance();
	}
}

Natürlich macht es hier Sinn einen Cache einzubauen, da sich die verfügbaren Klassen nicht oft ändern. Zend_Cache bietet hier eine einfache Möglichkeit so ein Array dateibasiert oder mittels memcached zu cachen.

Für meinen RSS Reader habe ich diesen Mechanismus zum Laden der Datenquellen in einen Action Helper ausgelagert. So steht diese Funktionalität in der gesamten Applikation zur Verfügung. Wer an Details interessiert ist, sei an dieser Stelle auf Google Code verwiesen, wo der Quellcode von rsslounge zu finden ist.

Zend Framework

Das Zend Framework ist ein objektorientiertes PHP Framework, das auf dem MVC Pattern basiert und viele viele Funktionen bietet. Das Zend Framework ist in diesem Blog ja ohnehin ein Thema und deshalb will ich an dieser Stelle dazu nicht schreiben. Einen ersten Überblick gebe ich hier, wobei natürlich innerhalb des letzten Jahres einiges hinzu gekommen ist.

jQuery

Auch jQuery ist mittlerweile kein Geheimtipp mehr und wie eine Umfrage des Webstandard Blogs zeigt, auch das beliebteste JavaScript Framework. Ich kann das gut verstehen, nachdem ich bisher auf prototype und script.aculo.us gesetzt habe, hat mich jQuery sofort überzeugt.

Alle weiteren JavaScript Bibliotheken basieren auf jQuery. Die Auswahl an Plugins ist schier unendlich und es gibt eine große Zahl an hervorragenden Projekten, die auf jQuery aufsetzen.

jQuery UI

Aufbauend auf jQuery gibt es jQuery UI, eine Bibliothek, die verschiedene Widgets und Funktionen bietet. Neben Widgets deckt jQuery UI das ab, was bei prototype durch script.aculo.us ergänzt wird: Drag n Drop, sortierbare Listen und animierte Effekte. In rsslounge basiert der Slider für die Priorität, das Drag n Drop der Feeds und Kategorien, sowie die Processbar für den ajaxbasierten Update auf dieser Bibliothek.

Impromptu

Es gibt ja eine ganze Reihe guter Lightbox Skripte. Für rsslounge habe ich aber ein LightBox Skript gesucht, das sich besonders gut für Dialoge eignet. Impromptu bietet hier eine einfache Möglichkeit Buttons zu setzen und eigene Funktionen an die verschiedenen Aktionen der Popup-Box zu binden. Lediglich bei der Positionierung der Box, die pauschal auf top:15% gesetzt ist, war ich nicht zufrieden. Allerdings hat man hier vollen Einfluss auf das CSS, so dass auch das kein echtes Problem ist. Eine sehr gute Alternative wäre die ModalBox gewesen. Diese basiert allerdings auf prototype.

Date Picker

Ein hervorragendes Skript für die Auswahl eines Datumbereichs ist der Date Picker von Stefan Petre. Date Picker für die Auswahl eines einzelnen Datums gibt es ja viele, so bietet jQuery UI hier auch ein grundsolides Widget. Aber wenn es darum geht einen Bereich zu wählen, wird die Auswahl plötzlich sehr klein. Der Date Picker hat ein schickes Design und kann sehr genau konfiguriert und mittels CSS gestaltet werden.

jgrowl

jgrowl orientiert sich an dem Benachrichtigungssystem von Growl, welches für Mac OS X verfügbar ist. Es zeigt Benachrichtigungen in einer kleinen Box am Bildschirmrand an. rsslounge nutzt dieses Skript nur recht selten, für Fehlermeldungen und wichtige Informationen ist es aber hervorragend geeignet.

Ajax Upload

Mit Hilfe dieses jQuery Plugins können bei rsslounge OPML Dateien importiert werden. So lässt sich der Dateiupload mit einem Klick auf den entsprechenden Menüpunkt starten, ohne das explizit ein neu Laden der Seite oder das Datei Eingabefeld nötig ist.

Tipsy

Das Plugin Tipsy ermöglicht beliebige ToolTipps zu erstellen. Diese verwende ich für den Eingabedialog von neuen Feeds. Manchmal bleiben die ToolTipps noch hängen, hier muss ich also nochmal genauer testen. Der erste Eindruck ist aber sehr gut und die zusätzlichen Informationen sind für Neulinge dann doch eine gute Hilfe.

SimplePie

Das Herzstück von rsslounge ist die Bibliothek SimplePie. Diese PHP Bibliothek ermöglicht es sehr einfach RSS Feeds zu lesen und zu verarbeiten. Ich habe mich für SimplePie und nicht für Zend_Feed entschlossen, da es um einiges ausgereifter ist, mit keinem Feed Probleme hat und sich bereits in vielen Applikationen bewährt hat. Ein erster Test hat dann auch gleich gezeigt das SimplePie schwer zu toppen ist. rsslounge selbst ist so aufgebaut, dass sich problemlos SimplePie durch eine andere Bibliothek ersetzen lässt (oder eine zweite Bibliothek optional gewählt werden kann), bisher gab es aber keinen Grund dafür. SimplePie besteht lediglich aus einer Datei und einer Hand voll Klassen.

WideImage

Für das Erzeugen der Thumbnails verwende ich die Bibliothek WideImage, welche sich zwar noch in Beta befindet, aber im Test super funktioniert. WideImage basiert auf der GD2 Erweiterung und kapselt alle Funktionen in eine Klasse und erlaubt es komfortabel Bilder zu laden, zu verkleinern oder anderweitig zu verändern. Ein Beispiel wie das dann aussehen kann:

wiImage::load('image.png')->resize(50, 30)->saveToFile('new-image.jpg');

Icons

An der Stelle will ich auch nicht die Icons vergessen. Diese stammen von DryIcons, welche die Sticker Icons unter einer Free Lizenz anbieten, sowie vom Smashing Magazine. Letztere erlauben eine freie Verwendung der Icons (auch für kommerzielle Zwecke, ohne Einschränkungen).

Die Liste ist ganz schön lange, aber bestätigt mich darin laufend gute Skripte zu sammeln. Besonders Funktionalitäten, die sich gut kapseln lassen, oder kompliziert zu entwickeln sind, sind für eigene Projekte eine wahre Bereicherung.

• Leverage browser caching
• Enable gzip compression

Zwei Apache Module, welche per default auch meist verfügbar sind, schaffen hier Abhilfe. Die Rede ist von mod_deflate und mod_expires. Beide sind im Handumdrehen konfiguriert und bringen einen guten Performanceschub.

mod_deflate sorgt dafür, dass die Inhalte, welche vom Apache Webserver zum Client gesendet werden, zuvor komprimiert werden. Die Konfiguration ist denkbar einfach und kann in der .htaccess Konfigurationsdatei hinterlegt werden. Folgende Konfiguration ist dem Apache Manual entnommen und so auch bei mir im Einsatz:

<IfModule mod_deflate.c>
	# Insert filter
	SetOutputFilter DEFLATE

	# Netscape 4.x has some problems...
	BrowserMatch ^Mozilla/4 gzip-only-text/html

	# Netscape 4.06-4.08 have some more problems
	BrowserMatch ^Mozilla/4.0[678] no-gzip

	# MSIE masquerades as Netscape, but it is fine
	# BrowserMatch bMSIE !no-gzip !gzip-only-text/html

	# NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48
	# the above regex won't work. You can use the following
	# workaround to get the desired effect:
	BrowserMatch bMSI[E] !no-gzip !gzip-only-text/html

	# Don't compress images
	SetEnvIfNoCase Request_URI
	.(?:gif|jpe?g|png)$ no-gzip dont-vary

	# Make sure proxies don't deliver the wrong content
	Header append Vary User-Agent env=!dont-vary
</IfModule>

mod_expires erlaubt es ein Verfallsdatum für den Cache zu setzen. Folgende Konfiguration habe ich Jörns Blog entnommen (der mich zu diesem Eintrag inspiriert hat):

<IfModule mod_expires.c>
	ExpiresActive On
	ExpiresByType text/html "access plus 2 houres "
	ExpiresByType text/xml "access plus 2 houres"
	ExpiresByType image/gif "access plus 3 weeks"
	ExpiresByType image/jpg "access plus 2 weeks"
	ExpiresByType image/png "access plus 3 weeks"
	ExpiresByType video/quicktime "access plus 2 months"
	ExpiresByType audio/mpeg "access plus 2 months"
	ExpiresByType application/pdf "access plus 2 weeks"
	ExpiresByType application/ps "access plus 2 weeks"
	ExpiresByType application/xml "modification plus 2 weeks"
</IfModule>

Durch die IfModule Direktiven ist auch sichergestellt, dass auf die Konfiguration verzichtet wird, wenn die Module nicht vorhanden sind.

Viel weiter habe ich mich zu dem Thema nicht eingelesen, bin mir aber sicher, dass man hier noch einiges mehr herausholen und machen kann. Auf meiner Wunschliste steht zu dem Thema noch das Buch High Performance Websites. Ein erstes Durchblättern hat gezeigt, dass hier noch einiges im Verborgenen liegt. Meistens so unkompliziert wie diese beiden Konfigurationen in die eigene .htaccess hinein zu kopieren. Kommentare zu diesem Thema sind also erwünscht. Wer hier bereits Erfahrung gesammelt hat und etwas empfehlen kann einfach diesen Beitrag kommentieren.

Auch nach vielen Stunden Suche habe ich keinen guten RSS Reader gefunden, den man auch auf dem eigenen Webspace installieren kann und der dabei einfach und praktisch zu bedienen ist. Bisher nutze ich Gregarius, der leider nicht mehr weiter entwickelt wird. Der Google Reader konnte auch überzeugen, aber hier mache ich mir aus Sicht des Datenschutzes sorgen, da die eigene Feedauswahl doch so einige Rückschlüsse auf Interessen und Hobbys zulässt. Ein weiterer interessanter Reader ist Fever, dieser kostet aber $30. Das wäre ich schon bereit zu zahlen, wenn die Software dann auch gut ist. Aber mit einer domainbezogenen Lizenz wollte ich mich dann einfach nicht herumschlagen. tiny tiny RSS scheint auch solide zu funktionieren, ist mir aber zu überladen und irgendwie unpraktisch.

Da Meckern nicht hilft habe ich mich also selbst ans Werk gemacht. Dazu habe ich mir aus bestehenden Reader die Features herausgepickt, die mir besonders gefallen, oder die ich bereits in Gregarius regelmäßig benutze.

Mein Wunsch-RSS-Reader muss darüber hinaus folgende Features haben (und hat sie auch schon):

• Neben normalen Feeds soll der Reader auch Medien lesen können. Ich verfolge viele Fotoblogs und Communitys und die sollen komfortabel als Thumbnailübersicht angezeigt werden (und nicht wie gewöhnliche Textnachrichten).
• Der Reader soll Prioritäten unterstützen. Jedes Feed soll dabei eine Priorität bekommen und je nach gewählten Prioritätsbereich wird nur eine Teilmenge (oder alle) Feeds angezeigt. In stressigen Lebensphasen lassen sich so gezielt Feeds ausblenden und man kann sich auf das Wesentliche konzentrieren. Am Wochenende kann dann der Prioritätsbereich erhöht und der Rest gelesen werden.
• Es soll ein offenes Pluginsystem für die Datenquellen vorhanden sein. Neben gewöhnlichen RSS Feeds soll man auch die Möglichkeit haben später neue Quellen zu definieren. So kann z.B. dann eine Seite manuell geparsed, verarbeitet und verfolgt werden, auch wenn diese kein RSS Feed anbietet (hierzu braucht man dann natürlich Programmierkenntnisse).
• Eine komfortable ajaxbasierte Oberfläche, die schlicht und übersichtlich sein soll. Zudem soll sich alles intuitiv mit Drag n Drop bedienen lassen (z.B. die Feeds zwischen den Kategorien verschieben, oder die Reihenfolge der Kategorien verändern).
• Es soll die Möglichkeit bestehen einen bestimmten Zeitraum vorzugeben, um nur Einträge dieser Periode zu sehen.
• Feeds sollen wahlweise mit Cronjob oder ohne (also via Ajax Aufruf) aktualisiert werden können.

Als Namen habe ich rsslounge aggregator gewählt. Ich finde das ziemlich passend, denn ich lese immer abends oder morgens ganz gechillt, bei einer Tasse Tee meine Feeds. Zudem soll das Prioritätsfeature dabei helfen Stress zu vermeiden und immer nur die Menge an Feeds zu zeigen, für die man auch Zeit hat. Der Rest kann ruhig bis zum Wochenende warten (oder wird nur grob überflogen).

Was nun auf der Agenda steht, ist ein ausführlicher Test. Dazu werde ich den Reader erst selbst einige Monate testen und anschließend einen geschlossenen Betatest unterziehen. Erst dann werde ich den Reader unter GPL in Deutsch und Englisch jedem frei zur Verfügung stellen. Hinzu kommt dann natürlich auch eine Anleitung, wie man selbst Plugins schreiben kann.

Als ersten Einblick gibts erst einmal ein paar Screenshots. Ich hoffe, dass ich bei einigen Interesse wecken kann. Mal sehen was daraus wird.