nicht angemeldet
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";