Zuweilen bilden Fehlermeldungen, die der Angreifer direkt lesen kann, den Seitenkanal. Es ist jedoch auch möglich, dass eine Anwendung Informationen durch weniger offensichtliche Indizien verrät. Ein Beispiel wurde in der Version 4.5.4 des Content-Management-Systems Typo3 ausgebessert: Angreifer konnten an der HTTP-Header-Reihenfolge des Typo3-Backends erkennen, ob ein gegebener Benutzername ein gültiger administrativer Benutzer war ( Tabelle 1 ).
Tabelle 1
Typo3-Benutzer
Non-existing user name |
Existing user name |
---|---|
HTTP/1.1 200 OK |
HTTP/1.1 200 OK |
Date: Mon, 25 Jan 2010 11:47:55 GMT |
Date: Mon, 25 Jan 2010 11:47:55 GMT |
Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny4 with Suhosin-Patch |
Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny4 with Suhosin-Patch |
X-Powered-By: PHP/5.2.6-1+lenny4 |
X-Powered-By: PHP/5.2.6-1+lenny4 |
Expires: Thu, 19 Nov 1981 08:52:00 GMT |
Expires:0 |
Last-Modified: Mon, 25 Jan 2010 11:47:55 GMT |
Cache-Control: no-cache, must-revalidate |
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 |
Pragma: no-cache |
Pragma: no-cache |
Last-Modified: Mon, 25 Jan 2010 11:47:45 GMT |
Vary: Accept-Encoding |
Vary: Accept-Encoding |
Content-Type: text/html;charset=iso-8859-1 |
Content-Type: text/html;charset=iso-8859-1 |
Content-Length: 5472 |
Content-Length: 5472 |
Der Fehler entstand, weil Typo3 die Überprüfung von Benutzername und Passwort trennt. Zuerst wird der Benutzername überprüft. Ist er gültig, werden einige Konfigurationswerte des Benutzers geladen und über die PHP-Funktion
»session_start()
«
eine Session gestartet. Dieser Aufruf wirkt sich auch auf die Cache-Einstellungen aus, die der Server über die HTTP-Header preisgibt. Somit werden die Cache-Direktiven im HTTP-Header genau dann verändert ausgegeben, wenn der gewählte Benutzername zu einem gültigen administrativen Benutzer gehört. Interessanterweise findet man diese Unterschiede nur, wenn man gezielt danach sucht, denn einen visuellen Unterschied, den Benutzer oder Programmierer im Browser sehen können, gibt es nicht.
Eine ähnliche Schwachstelle wurde mit Version 2.3.2 von Postfixadmin, einer Management-Web-Anwendung für den E-Mail-Server Postfix, geschlossen. In vorigen Versionen konnten Angreifer herausfinden, ob eine E-Mail-Adresse zu einem gültigen administrativen Benutzer gehörte oder nicht. Dazu musste der Angreifer nur die zu prüfende E-Mail-Adresse als Benutzername in die Login-Maske von Postfixadmin eingeben und bestätigen. In der Folge wurde eine Fehlermeldung ausgegeben und der Benutzer aufgefordert, die E-Mail-Adresse oder das Passwort zu korrigieren. Es gab jedoch den subtilen Unterschied, dass Postfixadmin die vorher eingegebene E-Mail-Adresse nur dann wieder in das Benutzernamensfeld eintrug, wenn sie korrekt war und zu einem Administratorenkonto gehörte. Abbildung 2 zeigt den betroffenen Ausschnitt aus dem HTML-Quellcode der Login-Maske von Postfixadmin. Der grau hinterlegte Teil wird in Abhängigkeit ob eine gültige oder ungültige E-Mail-Adresse übergeben wurde, ein- oder ausgeblendet.
Generell sind solche Informationslecks schwierig aufzufinden, da viele gängige Web-Seiten Teile der HTTP-Header und der HTML-Inhalte dynamisch generieren. Es reicht somit nicht, mehrere Web-Server-Antworten zu vergleichen, sondern man muss gezielt solche Unterschiede finden, die mit vertraulichen Informationen zusammenhängen. Schinzel und Freiling [2] haben 2011 eine Methode vorgestellt, um solche dynamischen Inhalte zu finden, die von vertraulichen Informationen abhängen. Den Kern der Methode zeigt Abbildung 3 . Er wird im Folgenden durch das bereits genannte Login-Masken-Beispiel verdeutlicht.