Wie sichere ich eine fremde Webanwendung ab?

Verwendet man für die eigenen Projekte oder für seine Kunden fremde Open- oder Closed-Source – PHP-Websoftware, so wird man irgendwann mit Sicherheitsmeldungen konfrontiert werden, die diese eingesetzte Software betreffen. Jetzt können folgende Szenarien eintreten:

1. Doppelt Glück: der Entdecker der Schwachstelle ist ein „Guter“ und gab dem Softwarehersteller einige Zeit um den Fehler zu beheben, was dieser auch prompt tat.
2. Einfaches Glück: der Entdecker der Schwachstelle ist ein „Guter“ aber der Softwarehersteller behebt den Fehler nicht.
3. Kein Glück: der Entdecker ist ein „Böser“, der die Sicherheitslücke gleich publik gemacht hat (Zero-Day-Exploit). Der Softwarehersteller liefert bald einen Patch.
4. Pech: der Entdecker ist ein „Böser“, der die Sicherheitslücke gleich publik gemacht hat und der Softwarehersteller behebt den Fehler nicht.

Unter Umständen (Punkte 2-4) läuft also die Zeit und man steht einsam da. In vielen Fällen besteht keine einfache Möglichkeit zu einer anderen Applikation zu migrieren, sodass also die vorhandene Version um diese Schwachstellen bereinigt werden muss – in Eigenarbeit.

„Blind Patch“: Schwachstellen beheben ohne Codeänderung

Die Sicherheitsbibliothek SSEQ-LIB hält zum Beheben dieses Misstandes die Funktion SEQ_SANITIZE bereit. Dieser Funktion wird eine Liste von Parameternamen übergeben, die einer Prüfung unterzogen und konvertiert werden, bevor sie in die Anwendung einfließen. An dieser Stelle muss man aus den Exploits die Parameternamen herausfinden, die für die Angriffe missbraucht werden und diese in die Liste eintragen. Oder man erstellt nach Möglichkeit eine Liste aller verwendeter POST, GET und COOKIE Parameter und pflegt sie in die Liste ein.

Ein Beispiel an eine WordPress-Schwachstelle

Nehmen wir diese Meldung als Beispiel:

SQL injection vulnerability in wp-uploadfile.php in the Upload File plugin for WordPress allows remote attackers to execute arbitrary SQL commands via the f_id parameter.

Der Angriff erfolgt also über die Datei wp-uploadfile.php und dem Parameter f_id.

Wir öffnen die besagte Datei und binden die Sicherheitsbibliothek dort ein:
<br />
<?php
include_once('sseq-lib/seq_lib.php');
?><br />


Jetzt definieren wird die Liste der zu prüfenden Parameter. Getrennt durch Raute-Zeichen (#) werden angegeben:

1. Parametername
2. Quelle (G=GET, P=POST, C=COOKIE)
3. Wertetyp (INT= Zahl, STR=Zeichenkette)
4. Minimaler Wertebereich (oder bei Zeichenkette: minimale Länge)
5. Maximaler Wertebereich (oder bei Zeichenkette: maximale Länge)
6. Schutz vor Cross Site Scripting (true=ja, false=nein)
7. Schutz vor SQL-Injection (true=ja, false=nein)

Das kaufmännische „und“ (&) trennt mehrere mögliche Parameternamen voneinander und schließt immer die Zeile ab. In diesem Fall haben wir nur ein Parameter zu filtern:

Es wird also der Parameter f_id geprüft in POST unf GET auf Datentyp INTeger im erlaubten Interval von 1 bis 64, nicht (false) gegen Cross Site Scripting konvertiert sondern (true) gegen SQL-Injection maskiert. Abschließend wird die Funktion mit diesem Filter aufgerufen:

WordPress – Blind Patch

Der komplette Code, der eine WordPress-Installation vor diesen Angriff schützt besteht aus 3 Zeilen:

ANMERKUNG:
Das Filtern der Daten aus POST, GET, COOKIE usw. schützt nicht in alle PHP-Skripte. Ein Artikel über das „Warum“ wird folgen.