PHP-Filter für den Eigengebrauch

Teil 7: Sicherheit bei PHP: Bereinigen von Daten durch eine Web-Applikation

Filter sicher anwenden

Die korrekte Filterung aller Eingaben und auch die Nutzung von https-Verbindungen sind zwar löblich, doch alleine damit lässt sich das Sicherheitsproblem nicht in den Griff bekommen.

Der schwache Punkt in dem Sicherheitskonzept besteht in der Aufbewahrung der Sitzungsdaten. Jede Applikation sollte die Session-Daten in einem eigenen Pfad statt in einem gemeinsam genutzten Verzeichnis speichern.

Der Name und der Ablageort sollten nicht leicht zu erraten sein, also nicht etwa /tmp/application1 und /tmp/application2/. Das standardmäßig verwendete /tmp-Verzeichnis stellt keinen idealen Ablageort dar, denn es ist aufgrund liberal gesetzter Zugriffsrechte leicht zugänglich.

Stattdessen gilt es, applikationspezifische Verzeichnisse mit nicht-trivialen Namen zu wählen. Die Zugriffspfade sollten mittels ini_set('session.save_path') gesetzt werden. Die Zugriffsrechte sollten so restriktiv vergeben sein, dass sich Applikation 1 und 2 die Sessiondaten auf keinen Fall gegenseitig auslesen können.

Filter-Sicherheit bei Shared Hosting

Die sichere Implementierung von Web-Applikationen scheidet auch mit PHP-Filtern auf einem Shared-Hosting-Server kategorisch aus. Stattdessen sollte ein dedizierter Server zum Einsatz kommen.

Dadurch kann der httpd-Dämon jederzeit neu gestartet und bestehende Umgebungsvariablen frei konfiguriert werden. Laufen eCommerce-Transaktionen mit https über einen Shared-Hosting-Server, so besteht dagegen die Gefahr, dass die Daten von anderen Anwendern auf demselben Server eingesehen oder über kompromittierte Skripte anderer Benutzer aus dem Web heraus modifiziert werden können - sicherlich keine empfehlenswerte Lösung.

Session-ID-Hijacking

Außerdem gilt es, User-Space-Session-Handler zu vermeiden, denn diese sind aufgrund sogenannter Session Race Conditions verwundbar. Unter Session Race Conditions versteht man einen Systemfehler, der das Resultat vom Timing bestimmter Ereignisse abhängig macht.

Mehrere ungefähr zeitgleich ablaufende Sessions können sich zufällig oder durch gezielte Manipulation gegenseitig beeinflussen. Das nicht immer beeinflussbare Timing macht den Unterschied zwischen sicheren und verwundbaren Transaktionen aus.

Abhilfe bei Session Race Conditions schafft nur das systematische Verschlüsseln der Session-Daten mit einem applikationsspezifischen Code. Binden Sie hierzu eine jeweils einmalige und vorzugsweise zufällige Applikationskennung für die jeweilige Session ein, zum Beispiel in der Art:

if ((string)$_SESSION['application']
!== 'application1') die();

Auf diese Weise würden das Szenario 1 und 2 unmöglich gemacht, da die Session-Cookies zwischen Applikation Nr. 1 und Nr. 2 zueinander inkompatibel sind.

Gleichgültig, ob man die in PHP eingebauten oder verbesserte eigene Filter verwendet, kann man auf die Resultate nur dann vertrauen, wenn die Session-ID nicht kompromittiert wurde. Applikationsspezifische Session-IDs, Pfade zum Abspeichern der Sitzungsdaten und der Einsatz dedizierter Server stellen wichtige Voraussetzungen dar, um den eingesetzten PHP-Filtern vertrauen zu können. Leider gibt es zu viele Szenarien, um PHP-Sessions zu kompromittieren und damit den praktischen Wert von PHP-Filtern infrage zu stellen.

Stellen wir uns nun vor, dass ein bereits eingeloggter Anwender, der durch die Web-Applikation bereits authentifiziert wurde und der eine gültige Session-ID zugewiesen bekam, beschließt, sein Passwort zu ändern.

Es kann ein gutwilliger, weil lediglich vergesslicher, eCommerce-Kunde oder aber ein böswilliger Hacker sein, der die Sitzung soeben entführt hatte. Man sollte aus diesem Grunde niemals das Ändern des Passworts zulassen, ohne das alte und zuletzt gültige Passwort eingeben zu lassen.

Insbesondere sollte man tunlichst darauf achten, einem Anwender, der sich lediglich durch eine Session-ID ausweist, niemals sicherheitskritische Daten anzuzeigen. Anstatt die Kreditkarten-Nummer bei der Übersichtsanzeige der Bestelldaten im Klartext anzuzeigen, sollte man dem Benutzer stattdessen nur die letzten vier Ziffern präsentieren:

xxxx-xxxx-xxxx-3456

Möchte ein Anwender sich erneut einloggen, sollte die Web-Applikation mittels

session_regenerate_id()

immer eine frische neue Session-ID erzeugen, zum Beispiel

session_start();
$alte_sessionid = session_id();
session_regenerate_id();
$neue_sessionid = session_id();
echo "Alte Session-ID: $old_
sessionid<br />";
echo "Neue Session-ID: $neue_
sessionid<br />";
print_r($_SESSION);

Ein potenzieller Hijacker, der die Session-ID missbrauchen möchte, wird die Session-ID voraussichtlich vor dem Einloggen einrichten. Wurde die Session-ID neu generiert, so wird das Login des Hackers abgelehnt.

Mehr zum Thema

HTML5: Quick Reference Guide
Ratgeber: "HTML5"

Die wichtigsten Tags auf einen Blick: In unserem praktischen Arbeitsblatt finden Sie einen wertvollen Begleiter für die Umstellung Ihrer Webprojekte…
internet, webdesign, google, content, ranking, seo, suchmaschine
Ratgeber: Urheberrecht

Einzigartige Inhalte bieten Lesern Mehrwert und sind ein wichtiges Qualitätsmerkmal. Ärgerlich, wenn sich jemand durch Kopieren an fremden…
Die besten HTML5-Tipps
Neue Tipps & Tricks für blitz.io

Wer die Leistung einer Applikation ermitteln möchte, braucht keine Skripte zu schreiben, sondern kann einen der zahlreichen Online-Dienste…
image.jpg
Ratgeber: Webentwicklung

Die clientseitige Javascript-Entwicklung bietet fast keine Entwicklungsumgebungen und auch keine vernünftigen Werkzeuge zur Fehlersuche. Eine der…
internet, webdesign, meteor, webapplikationen
Ratgeber

Mit Meteor sollen Entwickler in kurzer Zeit Umgebungen für Webapplikationen erstellen können, ohne sich um lästige Details kümmern zu müssen. Wir…