$_SERVER['SERVER_NAME'] und Sicherheit?

[Roland]

Hi!

Ich hab grad ein Tool programmiert, das auf zwei Domains laufen soll, das Problem jetzt:
ich müsste das ganze Tool 2 mal unterschiedlich haben, einmal mit der einen, einmal mit der anderen Domain (brauch leider nen absoluten Pfad).

Jetzt hatte ich die Idee statt der Domain einfach <?php echo $_SERVER['SERVER_NAME']; ?> zu schreiben. Ist das sicher oder kann da mit XSS (wie bei $_SERVER['PHP_SELF']) was gemacht werden?

Vielen Dank
Roland

[Cybaer]

Hi,

Jetzt hatte ich die Idee statt der Domain einfach <?php echo $_SERVER['SERVER_NAME']; ?> zu schreiben. Ist das sicher oder kann da mit XSS (wie bei $_SERVER['PHP_SELF']) was gemacht werden?

Nein. Aber es ist dennoch ggf. ungeschickt, SERVER_NAME zu verwenden. Grund: SERVER_NAME ist vom Administrator konfigurierbar. Zwar ist *normalerweise* dort der wirkliche Servername enthalten (das ist beim Apache voreingestellt), aber z.B. der Hosenjodler, der bei 1&1 die Shared-Server (bzw. die Konfigurationssoftware) konfiguriert hat, hat dort wohl einen festen Wert eingetragen. D.h., bei einem Request von einem 1&1-Server www.example.com, steht in SERVER_NAME nur example.com.

Hier empfiehlt sich also HTTP_HOST als Alternative.

Das sind zwar Daten vom User, aber wenn der Inhalt nicht korrekt wäre, würde der Request gar nicht erst ankommen ...

Gruß, Cybaer

[Christoph Jeschke]

Guten Tag,

Hier empfiehlt sich also HTTP_HOST als Alternative.

Das sind zwar Daten vom User, aber wenn der Inhalt nicht korrekt wäre,
würde der Request gar nicht erst ankommen ...

Das stimmt nicht. Der Apache (2.x) verwendet den ersten VHost, wenn kein Vhost gefunden werden kann, dessen ServerName- oder -Alias-Direktive mit dem Host-Header korrespondiert. Man kann also den Host-Header durchaus dazu verwenden, gefährliche Inhalte zu übergeben.

Merke: Jeder Input vom User ist zu prüfen, ggf. abzulehnen und auf keinen Fall zu reparieren.

Gruß
Christoph Jeschke

[Cybaer]

Hi,

Man kann also den Host-Header durchaus dazu verwenden, gefährliche Inhalte zu übergeben.

Beispiel?

Gruß, Cybaer

[dedlfix]

echo $begrüßung;

Man kann also den Host-Header durchaus dazu verwenden, gefährliche Inhalte zu übergeben.
Beispiel?

Gefährlich ist so etwas immer dann, wenn man Werte ungeprüft und nicht dem Kontext gerecht ausgibt. Eine andere Frage ist, wie der Apache mit offensichtlich ungültigen Hostnamen umgeht.

echo "$verabschiedung $name";

[Cybaer]

Hi,

Gefährlich ist so etwas immer dann, wenn man Werte ungeprüft und nicht dem Kontext gerecht ausgibt.

Sowieso. =:-)

Eine andere Frage ist, wie der Apache mit offensichtlich ungültigen Hostnamen umgeht.

Mir fällt halt spontan keine Möglichkeit ein, wie man einen gültigen Request mit gefährlichen Daten verbinden könnte, so daß (bei irgendeinem Server) HTTP_HOST mit gefährlichen Daten besetzt wird.

Daß Vorsicht immer die Mutter der Porzellankiste ist, versteht sich von selbst (oder sollte sich zumindest von selbst verstehen). Aber mich würde schon interessieren, wie das in diesem Fall überhaupt funktionieren soll ...

Gruß, Cybaer

[dedlfix]

echo $begrüßung;

Mir fällt halt spontan keine Möglichkeit ein, wie man einen gültigen Request mit gefährlichen Daten verbinden könnte, so daß (bei irgendeinem Server) HTTP_HOST mit gefährlichen Daten besetzt wird.

Die Verbindung vom Client wird ja letztlich stets zu einer IP-Adresse aufgebaut. Damit bist du schon mal im Apachen, der Rest ist HTTP, also Nutzdaten. Du kannst nun als Host-Header irgendwas beliebiges angeben. Im besten Fall findet der Apache eine passende VHost-Konfiguration und reicht quasi den Request dorthin weiter. Wird keine passende Konfiguration gefunden, nimmt der Apache den ersten konfigurierten VHost als Ziel. Damit ist es theoretisch möglich, dass dort ein "komischer" Host-Header ankommt. Ob es praktisch möglich ist, müsste man probieren. Nutzen hat man als Angreifer nur dann einen, wenn dieser Default-VHost mitspielt.

echo "$verabschiedung $name";

[Cybaer]

Hi,

Damit ist es theoretisch möglich, dass dort ein "komischer" Host-Header ankommt.

Ja, theoretisch ist es auch möglich, daß ich beim Nasebohren stolpere, mit dem Ellenbogen aufschlage, und sich mein Zeigefinger durch mein Hirn bohrt. >;->

Ob es praktisch möglich ist, müsste man probieren.

Deswegen eben meine Frage, da ich mir nicht vorstellen kann, eine Request irgendwohin zu senden, und gleichzeitig Schadcode in irgendeiner Form im HTTP_HOST unterzubringen - ganz egal welcher VHost nun den Request bekommt.

Gruß, Cybaer

[dedlfix]

echo $begrüßung;

Deswegen eben meine Frage, da ich mir nicht vorstellen kann, eine Request irgendwohin zu senden, und gleichzeitig Schadcode in irgendeiner Form im HTTP_HOST unterzubringen - ganz egal welcher VHost nun den Request bekommt.

Das "irgendwohin" ist doch schon erledigt. Es wurde vom Client aus eine TCP/IP-Verbindung zu einem Apachen aufgebaut. Dazu braucht es zunächst keinen Host- oder DNS-Namen, die Verbindung wird und muss sowieso von IP-Adresse A zu IP-Adresse B aufgebaut werden. Die Verbindung steht also und nun schickt man einfach Text. Ein GET / HTTP/1.1 gefolgt von Host: mit beliebigem nachfolgenden Text. Und dieser landet im Default-VHost, wenn der Apache keine Prüfung auf plausible Zeichen in der Host-Header-Zeichenkette durchführt.

echo "$verabschiedung $name";

[Roland]

Also von der Theorie zurück zur Praxis!

Wenn in der Seite nicht ersichtlich is, das damit gearbeitet wird is es
vollkommen ungefährlich!?
Ich glaub nicht das es Angreifer gibt die ne kleine Website hacken wollen
und dafür mit sowas arbeiten, oder?
Vor allem da es ja teilweise noch echt große Lücken gibt, alla beim login-pw
[i]' or 1=1[/i] reinschreiben ;)

lg
Roland

[Malcolm Beck´s]

hi,

Wenn in der Seite nicht ersichtlich is, das damit gearbeitet wird is es vollkommen ungefährlich!?

Wenn du nur vergleichst, ja.

Ich glaub nicht das es Angreifer gibt die ne kleine Website hacken wollen und dafür mit sowas arbeiten, oder?

Warum nicht, richtige hacker hacken aus Prinzip, das ist wie mit richtigen Graffiti-Künstlern, je mehr Ordentliche Tags du auf Wände bringst, umso mehr Respekt bekommst du von gleichgesinnten[1].

holla holla
[1] Sinn und Unsinn von Graffiti mal außen vor gelassen

[dedlfix]

echo $begrüßung;

Also von der Theorie zurück zur Praxis!

In der Praxis hat man beim Massenhoster das Host-Header-Manipulationsproblem sicherlich nicht, denn der Default-VHost sollte ein providerseitiger sein. Wenn nicht und man ist zufällig die erste VHost-Konfiguration oder man betreibt einen eigenen Server kann es schon ein XSS-Problem werden, wenn man den Hostnamen einfach so ausgibt.

Wenn in der Seite nicht ersichtlich is, das damit gearbeitet wird is es
vollkommen ungefährlich!?
Ich glaub nicht das es Angreifer gibt die ne kleine Website hacken wollen und dafür mit sowas arbeiten, oder?

Auch kleine Seiten, die vielleicht sogar kaum bis gar nicht vom Administrator überwacht werden, eignen sich als Angriffsziel. Man kann dort wunderbar Dateien hinlegen, auf die von anderen manipulierten, besser frequentierten Seiten verwiesen werden kann.

Vor allem da es ja teilweise noch echt große Lücken gibt, alla beim login-pw ' or 1=1 reinschreiben ;)

Na, das lässt sich ebenso wie XSS-Probleme durch konsequentes kontextgerechtes Behandeln der auszugebenden Werte vermeiden.

echo "$verabschiedung $name";

[Cybaer]

Hi,

Das "irgendwohin" ist doch schon erledigt.

Kommt wohl drauf an. Ich stelle mir das in einem zustandslosen Protokoll nicht so trivial vor. Oder kann man das auf die Schnelle mal auf einem lokalen Apache nachvollziehen?

Es gibt aber auf jeden Fall eine indirekte Schwachstelle beim Host-Header (u.a. im Apache bis 2.0.42) in Verbindung mit SSI: Apache HTTP Server is vulnerable to cross-site scripting, caused by improper filtering of server signature data by Server Side Include (SSI) error pages.

Gruß, Cybaer

[dedlfix]

echo $begrüßung;

Das "irgendwohin" ist doch schon erledigt.
Kommt wohl drauf an. Ich stelle mir das in einem zustandslosen Protokoll nicht so trivial vor. Oder kann man das auf die Schnelle mal auf einem lokalen Apache nachvollziehen?

Ja, das kommt auf das OSI-Modell an, doch das setze ich bei einer TCP/IP-Verbindung im Internet der Einfachheit halber als gegeben voraus.

HTTP ist zwar zustandslos, doch das ist hier nicht relevant. Ein Request-Response-Ablauf findet verbindungsorientiert mit TCP als einer unteren Schicht statt. Zwischen IP-Adresse A und B ist eine TCP-Verbindung aufgebaut worden. Schicht 1 bis 4 stehen also. Damit sind beide Endpunkte der Kommunikation bereits bekannt. Erst jetzt kommt HTTP zum Einsatz. Und was dabei hin- und hergeredet wird, beeinflusst die darunter liegende TCP-Verbindung nicht weiter. Deshalb ist es problemlos möglich, einen beliebigen Host-Header zu verwenden oder selbigen gar wegzulassen, wie das bis HTTP 1.0 der Fall war. Der Zusammenhang zwischen einem Hostnamen und einer IP-Adresse ist nicht weiter relevant, der wird nur vom DNS hergestellt. Ein Client braucht den Hostnamen nur, wenn ihm die IP-Adresse des Ziels nicht bekannt ist. Dann kann er diese beim DNS erfragen. Danach ist der Hostname nicht weiter relevant, da die Verbindung über die IP-Adressen und nicht über einen Namen hergestellt wird.

HTTP ab Version 1.1 macht hier aufgrund der VHost-Problematik eine Ausnahme, indem es den Host-Namen in einer höheren Schicht mitsendet. Der Webserver kann sonst nicht wissen, welcher der vielen Namen, die alle auf die gleiche IP-Adresse zeigen, gemeint ist, da er es über die Schichten 1 bis 4 nicht mitgeteilt bekommt.

Es gibt aber auf jeden Fall eine indirekte Schwachstelle beim Host-Header (u.a. im Apache bis 2.0.42) in Verbindung mit SSI: Apache HTTP Server is vulnerable to cross-site scripting, caused by improper filtering of server signature data by Server Side Include (SSI) error pages.

Ja, das ist sogar ein Beispiel, das mit einem handelsüblichen Browser funktioniert. Hier ist der Apache selbst bei der Ausgabe einer 404-Fehlerseite betroffen. Aufgerufen werden soll, beispielsweise durch einen Link, den man dem Opfer unterjubelt:

http://%3CIMG%20SRC%3D%22%22%20ONERROR%3D%22alert%28document%2Ecookie%29%22%3E.example.org/raise_404

Oder in lesbar:

http://<IMG SRC="" ONERROR="alert(document.cookie)">.example.org/raise_404

Voraussetzung ist, dass example.org ein Catch-All im DNS eingerichtet hat, so dass beliebige Subdomain-Anfragen mit des Webservers IP-Adresse beantwortet werden. Daraufhin geht der Browser in die Spur und baut die TCP/IP-Verbindung auf. Darüber schickt er in der HTTP-Schicht als Host-Header dieses komische Gebilde mit. Die 404er Fehlerseite zitierte den falschen Namen ohne kontextgerechte Behandlung, was im HTML-Kontext zu HTML- und Javascript-Code führte.

Wenn solch eine Anfrage keinen 404er liefert, sondern eine Applikation erreicht, die den Hostnamen ebenfalls ungeprüft weiterverarbeitet, kann das auch zu einem ungewünschten Ergebnis führen, je nachdem, was die Anwendung damit anstellt. Der Apache selbst kann hier nicht allzuviel machen. Er kann eigentlich nur dafür sorgen, dass seine 404er Ausgabe sauber bleibt. Wie soll er sich jedoch gegenüber der Anwendung verhalten? HTML-gerechtes Kodieren von <, > und " ? Das wäre nicht seine Aufgabe, er weiß nicht, welcher Kontext in der Anwendung vorliegt. Er kann es im Prinzip nur durchreichen oder den Request ganz ablehnen.

echo "$verabschiedung $name";