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/
Hinterlasse eine Antwort