• Softwaremetriken,
• Unit Tests,
• Code Coverage Analysen
• und automatisierten Angriffs Tools

für Qualität und Sicherheit gesorgt. Gegen diese Tools ist nichts zu sagen und der Einsatz ist oft unerlässlich aber leider wird oft eine menschlicher Code Review weggelassen. Diese sind aber wesentlich effektiver und bedürfen auch keiner Einarbeitungszeit. Optimalerweise prüft ein Software Architekt den Code nach der Entwicklung einer Phase. Oft würde es aber auch schon reichen wenn wenigstens ein Kollege den Code betrachtet.

Heute musste ich mal wieder feststellen welche gravierenden Sicherheitslücken man finden kann wenn man einfach mal den gesamten Code quer liest. Beim Coden hat man oft nicht den Blick für das Gesamte und ist auf die Problemlösung im Detail konzentriert. Dabei können dann Sicherheitslücken entstehen, die erst sichtbar werden, wenn man das Zusammenspiel aller Komponenten betrachtet.

Deshalb gilt für mich: Regelmäßige Code Reviews erhöhen die Sicherheit enorm.

Mit diesen Tool kann man auch testen ob die eigene Anwendung einen potenziellen Angriff erkennt. Da auf meiner Seite die PHIDS installiert war, hat diese sofort Alarm geschlagen. Auch wenn keine Angriffsmöglichkeit gefunden wurde hat meine Seite den Zugriff auf die Seite nach kurzer Zeit für die IP gesperrt, da ein portenzieller Hacker wahrscheinlich erstmal die Seite auf Schwachstellen scannt.

Das Freeware Tool hat eine Begrenzung der URLs die gescannt werden (1500). Nach dem Ende des Scans bekommt man einen Bericht angezeigt.

Die Freeware Version eignet sich aber trotzdem zum Testen des Verhaltens der eigenen Seite auf solche Angriffe. Laut eine Studie ist fast jede Webanwendung mit solchen Tools angreifbar.

Scrawlr soll eigentlich nur Geschmack auf die Software WebInspect machen.

Diese kann man sich zwar als 15 Tage Demo herunterladen, aber man kann die nur mit einer bestimmten Seite verwenden und nicht mit der eigenen.

Spannend sieht es auf jedenfall aus:

In der Demo Seite werden sehr viele Angriffsmöglichkeiten aufgezeigt, aber auch einfacherer Schwachstellen bei denen ein Angreifer zu viel Informationen über die Seite bekommt.

Dieses Tool prüft auch die Angreifbarkeit von Flash und Ajax Anwendungen und es kann auch eingeloggte User Simulieren. Diese stellen auch eine große Gefahr dar.

Es lassen sich verschiedenste Authentifizierungen einstellen.

Interessant ist das Tool für größere Firmen auf jedenfall. Die Preise für die Software fangen bei 2500$ an.

Deshalb sollte der Inhalt der Datenbanken möglichst verschlüsselt sein um die Nutzbarkeit eines solchen Dump zu verhindern.

Passwörter verschlüsseln

Passwörter sollten immer verschlüsselt in der Datenbank abgelegt sein. Leider geschieht das oft nur mit einer einfachen md5 Verschlüsselung.

<?php
$hash = md5($password);
?>

Für md5 gibt es unzählige Tools um diese wieder in Klartext umzuwandeln (Google: md5 reverse). Auch andere Verschlüsselungs Systeme helfen da nicht, wenn man das Verschlüsseln nicht komplizierter macht.

Zusätzlich zu dem Passwort sollte man noch den Login Namen in den Verschlüsselungs Mechanismus einbauen. Aber auch dass lässt sich mit ein wenig krimineller Energie schnell knacken.

<?php
$hash = md5($password.$login);
?>

Wenn man noch einen Anwendung spezifischen Schlüssel einbaut wird es sehr schwer das Passwort den Benutzers zu ermitteln.

<?php
$salt = 'jfhfg&%55707865gGFds93kjl3ß()(73äü';
$hash = md5($salt.$password.$salt.$login.$salt);
?>

Kreditkarten- und Bankdaten

Kreditkartendaten sind das sensibelste eines Online Shops. Diese Daten sollte man nur speichern wenn man sicherstellen kann dass diese nicht geklaut werden können. Da jeder Benutzer weiß, dass Kreditkartendaten gerne geklaut werden, ist er auch nicht verärgert wenn er seine Daten immer wieder erneut eingeben muss.

Um die Daten dennoch sicher zu speichern gehe ich wie folgt vor:

Ich verschlüssele alle Daten mit einer Verschlüsselung die einen eindeutigen Schlüssel benötigt und wieder entschlüsselbar ist. Zu Beispiel Blowfish.

Wichtig: Der Schlüssel zum Ver- und Entschlüsseln ist dabei nicht in der Anwendung hinterlegt.  Den Schlüssel erzeuge ich bei dem Login den Benutzers anhand seiner Login Daten un speichere diesen dann in der Session.

<?php
$saltkredit = 'jfhfg&%dd55707865gGFds93kjl3ßddd()(73äü';
$hashkredit = md5($salt.$password.$salt.$login);
$_SESSION['KREDITKARTEN_HASH'] = $hashkredit;
?>

<?php
$kreditkartendaten_sicher = crypt($str, CRYPT_BLOWFISH);
$bf = & Crypt_Blowfish::factory('cbc');
$iv = 'd55707865gGFd';
$key = $_SESSIO['KREDITKARTEN_HASH'];
$bf->setKey($key, $iv);
$encrypted = $bf->encrypt('Kreditkartennummer');
?>

Die Kreditkarten- und Bankdaten können somit nur während einer aktuellen Sitzung des Benutzers verwendet werden. Selbst der Shop Besitzer könnte mit den Daten nichts anfangen sofern auch das Passwort richtig verschlüsselt gespeichert worden ist.

PHPIDS ist ein System zur Erkennung von Angriffen auf Webseiten. Es ist ein in PHP geschriebenes Werkzeug mit dem man eingehende Requests auf potenzielle Gefahren wie SQL-Injection, XSS und andere prüfen kann.

Als Basis dient eine XML Datei mit Filtern die regelmäßig aktualisiert wird. Somit ist man auch für die neuen Ideen der Hacker gewappnet.

Das Tool lässt sich besonders einfach einsetzten wenn man das Design Pattern “Filter” einsetzt.

Die Dateien müssen einfach heruntergeladen werden und in den include_path aufgenommen werden.

Config.ini

Als erstes muss man die Config.ini anpassen. Dort müssen die richtigen Pfade eingetragen werden und entschieden werden wie das Caching geschehen soll.

Zu Auswahl stehen:

• Datei
• Datenbank
• Memcache

Wenn man das mitgelieferte Logging verwenden möchte, muss man hier auch Einstellungen vornehmen.
Ich bevorzuge mein bestehendes Logging zu verwenden und einen Angriff über eine Exception zu signalisieren.

Hier kann man auch Felder definieren in den HTML vorkommen darf oder welche Werte nicht geprüft werden sollen.

html[]  = feld_name_mit_html
exceptions[]    = feld_name_welches_nicht_geprüft_wird

Da in dieser Datei wichtige Informationen für Hacker stehen, darf die Datei nicht über das Web sichtbar sein und sollte außerhalb des Webroots liegen.

Filter Beispiel

Hier ein Beispiel eines Filters der vor jeder Aktion auf der Seite ausgeführt.

require_once 'IDS/Init.php';
class Filter_IDS implements Filter_Base{
    /**
     * @param    FrontControler_HttpRequest
     * @param    FrontControler_HttpResponse
     */
    public function execute(FrontControler_HttpRequest $oFrontControler_HttpRequest,
                          FrontControler_HttpResponse $oFrontControler_HttpResponse){
        $aRequest =  array(
            'GET' => $_GET,
            'POST' => $_POST,
            'COOKIE' => $_COOKIE
        );

        $oIDS_Init = IDS_Init::init(/pfad/zu/der/Config.ini);
        $oIDS_Monitor = new IDS_Monitor($aRequest, $oIDS_Init);
        $oIDS_Report = $oIDS_Monitor->run();
        if(!$oIDS_Report->isEmpty()){
            if($oIDS_Report->getImpact()>4){
                    throw new InvalidAccesException('IDS Filter: '.$oIDS_Report);             
            }
        }
    }
}

In diesen Fall wird erst ab einen Impact größer als 4 Alarm geschlagen. In diesen Fall wird eine InvalidAccessException geworfen. Diese wird zusammen mit der IP geloggt und wenn diese IP eine bestimmte Anzahl solcher Einträge hat, werden alle Anfragen von der IP für eine bestimmte Zeit gesperrt.

Fazit

Die Geschwindigkeit von PHPIDS ist sehr gut und die Meldungen sind sehr aussagekräftig (siehe unten).

Wichtig: Die Filter schlagen oft unerwartet Alarm. Deshalb sollte man den Filter erstmal Testweise einbauen und nicht auf die “Angriffe” reagieren sondern die Werte erst mal Loggen da man sonst seine Benutzer verärgern könnte.