Wohnzimmerhostblogger

Ich habe in der Tat erst gestern zum ersten Mal von HTTPOXY gelesen - beim CERT.at. Seitdem Hanno Böck heute auf Golem.de darüber berichtet hat verbreitet sich die Nachricht sicherlich etwas schneller. Ein wenig unangenehm ist es mir irgendwie schon, denn im Prinzip ist das mögliche Problem hierbei bereits seit 2001 bekannt. Doch was genau soll hier überhaupt das Problem sein und ist es wirklich eines?

Wird eine HTTP-Anfrage über CGI oder FastCGI an einen anderen Prozess, z.B. einen PHP-Interpreter, zur Bearbeitung weitergegeben, so werden die HTTP-Header als Umgebungsvariable registriert. Jeweils mit einem HTTP_-Prefix und dem Namen aus dem HTTP-Header in Großbuchstaben, Bindestriche werden dabei zu Unterstrichen. Ruft dieser Prozess nun einen anderen Prozess auf oder arbeitet mit einer Bibliothek bzw. einem Framework die auf spezielle Umgebungsvariablen zugreifen, so lassen sich hier eventuell über eine HTTP-Anfrage ungewünschte Werte injezieren - so erinnert es in abgemilderter Form an die register_globals von PHP, die vor Jahren per default aktiviert waren und für jede Menge Kopfschmerzen gesorgt haben.

Problematisch wird es bei HTTPOXY, wenn die besagte Software mittels einer weiteren HTTP-Anfrage auf einen externen Dienst zugreifen soll und hierzu die Umgebungsvariable HTTP_PROXY bei der Auswahl eines eventuell vorgeschalteten Proxy zu Rate zieht. In diesem Fall könnte ein Angreifer von außen alle HTTP-Anfragen über einen eigenen Server umleiten und Einsicht in den Datenverkehr nehmen solange dieser nicht verschlüsselt ist. Je nach Gründlichkeit der Entwickler ist auch denkbar einen Man-In-the-Middle-Angriff auf HTTPS-Verbindungen zu nehmen - hierbei gelten natürlich die üblichen MITM-Hürden: Die ursprüngliche Anwendung dürfte das SSL-Zertifikat nicht validieren oder müsste eine falsche Domain dort stillschweigend akzeptieren, damit dieser Angriff auch für HTTPS funktioniert.

Bei uns im Hosting kann ich natürlich nicht für die Skripte unserer Kunden sprechen, aber ich habe zur Sicherheit bereits gestern mal einen Blick auf die Software-Umgebung geworfen, wie wir sie jedem Kunden bereitstellen. Grundsätzlich bin ich hier beruhigt: Es fanden sich 3-4 Hinweise in einigen vorinstallierten PEAR-Bibliotheken von PHP sowie in der von uns verwendeten libXML2. Bei libXML2 wollte ich noch nachschauen, ob dies überhaupt ein Problem sein könnte - z.B. wenn ein XML/HTML-Dokument von extern geladen wird - aber das steht noch auf meiner ToDo und spielt auch eigentlich schon keine Rolle mehr...

... denn selbstredend sind wir den Vorschlägen gefolgt und haben eine Handvoll Proxy-Header in HTTP-Anfragen gesperrt. Dabei sind wir den Empfehlungen der CERT.at gefolgt und haben nicht nur den Proxy-Header sondern noch ein paar weitere Varianten gesperrt. Ich habe überlegt, ob es legitim ist einfach so und pauschal Header-Einträge aus dem Verkehr zu nehmen, allerdings ist kein Proxy-Header bei der IANA registriert und nicht-Standard-Header sollten entsprechend einen "X-"-Prefix tragen (Ich bin ein alter, alter Mann).