Fehlende CGI-Umgebungsvariable HTTP_REFERER

[Norbert Kölln]

Moin, moin!

Ich frage in einem Perl-Script u. a. die oben genannte Variable ab. In geschätzten 5% aller Fälle erhalte ich dabei einen leeren String. Um dem Rätsel auf die Spur zu kommen, lasse ich mir dann mit foreach(keys(%ENV)) alle CGI-Umgebungsvariablen ausgeben. Das Ergebnis ist durchaus unterschiedlich, obwohl das Script ja immer auf dem gleichen Server läuft. Und dort wechselt weder der installierte Web-Server, noch das Betriebssystem häufiger. Auch mein Script pfuscht nicht an den Umgebungsvariablen herum.

Wie also kann es kommen, daß die Liste der Umgebungsvariablen in Fehlerfällen beispielsweise mal so

QUERY_STRING=
SERVER_ADDR=xxx
CONTENT_TYPE=application/x-www-form-urlencoded
HTTP________________=~~~~~ ~~~~~~~
HTTP_ACCEPT_LANGUAGE=de
SERVER_PROTOCOL=HTTP/1.1
TZ=MET
HTTP_CONNECTION=Keep-Alive
REMOTE_PORT=xxx
HTTP_USER_AGENT=Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
HTTP_ACCEPT=*/*
GATEWAY_INTERFACE=CGI/1.1
HTTP_HOST=xxx
SERVER_SOFTWARE=Apache
SERVER_ADMIN=xxx
REMOTE_ADDR=xxx
SCRIPT_NAME=xxx
HTTP________=:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SERVER_NAME=xxx
DOCUMENT_ROOT=xxx
REQUEST_URI=xxx
UNIQUE_ID=xxx
REQUEST_METHOD=POST
CONTENT_LENGTH=6
SCRIPT_FILENAME=xxx
PATH=/usr/local/bin:/usr/bin:/bin
SERVER_PORT=80
HTTP_CACHE_CONTROL=no-cache

und mal so

QUERY_STRING=
SERVER_ADDR=xxx
HTTP_ACCEPT_LANGUAGE=de
SERVER_PROTOCOL=HTTP/1.1
TZ=MET
HTTP_CONNECTION=Keep-Alive
REMOTE_PORT=xxx
HTTP_ACCEPT=image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/msword, application/x-shockwave-flash, application/vnd.ms-powerpoint, */*
HTTP_USER_AGENT=Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705)
GATEWAY_INTERFACE=CGI/1.1
HTTP_HOST=xxx
SERVER_SOFTWARE=Apache
SERVER_ADMIN=xxx
REMOTE_ADDR=xxx
SCRIPT_NAME=xxx
HTTP_ACCEPT_ENCODING=gzip, deflate
SERVER_NAME=xxx
DOCUMENT_ROOT=xxx
UNIQUE_ID=xxx
REQUEST_METHOD=GET
SCRIPT_FILENAME=xxx
PATH=/usr/local/bin:/usr/bin:/bin
SERVER_PORT=80

aussieht? Reale Daten habe ich zum Teil durch "xxx" ersetzt.

Insbesondere irritieren mich im ersten Beispiel Variabele / Werte wie
HTTP________________=~~~~~ ~~~~~~~.

Norbert

[Christian Kruse]

Hallo Norbert,

Ich frage in einem Perl-Script u. a. die oben genannte
Variable ab. In geschätzten 5% aller Fälle erhalte ich
dabei einen leeren String.

Wahrscheinlich dann, wenn kein Referer uebermittelt wurde.

Um dem Rätsel auf die Spur zu kommen, lasse ich mir dann
mit foreach(keys(%ENV)) alle CGI-Umgebungsvariablen
ausgeben. Das Ergebnis ist durchaus unterschiedlich,
obwohl das Script ja immer auf dem gleichen Server läuft.
Und dort wechselt weder der installierte Web-Server, noch
das Betriebssystem häufiger. Auch mein Script pfuscht
nicht an den Umgebungsvariablen herum.

Aber die UAs senden verschiedene Header. Alle HTTP_*-Variablen
kommen direkt aus dem HTTP-Request des Clients. Dabei wird
lediglich alles gross geschrieben und ein Bindestrich wird
durch einen Unterstrich ersetzt.

HTTP________________=~~~~~ ~~~~~~~

Der und...

HTTP________=:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Sind in der Tat seltsam. Schon mal Google gefragt?

Gruesse,
 CK

[Cheatah]

Hi,

Auch mein Script pfuscht nicht an den Umgebungsvariablen herum.

kann es gar nicht, zumal sie rein informativer Art sind. Das Script kann die Werte nur für sich selbst verändern, ohne weitere Konsequenzen.

Wie also kann es kommen, daß die Liste der Umgebungsvariablen in Fehlerfällen beispielsweise mal so

[...]

aussieht?

Diverse Daten stammen vom Client, und der kann so ziemlich _alles_ senden. Insbesondere alle "HTTP_*"-Werte entstammen HTTP-Headern.

Insbesondere irritieren mich im ersten Beispiel Variabele / Werte wie
HTTP________________=~~~~~ ~~~~~~~.

shell > telnet dein.server 80
[...]
GET / HTTP/1.0
_______________: ~~~~~ ~~~~~~~.

Et voilà.

Cheatah

[Norbert Kölln]

Nochmals moin, moin!

Ok, ich habe also gelernt, daß viele der Daten von den Clients gesendet werden, die jeden nur denkbaren Unsinn machen können (Dank für diese Erkenntnis auch an Christian Kruse).

Und dem Schnipsel

shell > telnet dein.server 80
[...]
GET / HTTP/1.0
_______________: ~~~~~ ~~~~~~~.

entnehme ich, daß ohnehin alles mögliche an den Server geschickt werden kann.

Damit hat sich meine Frage erledigt, denn ich kann mich offenbar nicht auf die mich interessierenden Daten verlassen, die in den CGI-Umgebungsvariablen stecken könnten.

Vielen Dank!

Norbert

[Cheatah]

Hi,

Und dem Schnipsel

[...]

entnehme ich, daß ohnehin alles mögliche an den Server geschickt werden kann.

korrekt. Es ist keine Frage der Möglichkeit, sondern nur eine des Aufwandes - und den kann man mit einem einfachen kleinen Script, welches als nicht-transparenter Proxy fungiert, minimieren.

Damit hat sich meine Frage erledigt, denn ich kann mich offenbar nicht auf die mich interessierenden Daten verlassen, die in den CGI-Umgebungsvariablen stecken könnten.

Ebenfalls korrekt. Das meiste - insbesondere das, was mit "HTTP_" beginnt - ist nicht verlässlich und hat daher gerade mal informativen Charakter. Um Tendenzen zu erahnen reichen sie aus, wenn man sich der Unzuverlässigkeit bewusst ist; darüber hinaus sollten sie jedoch auf gar keinen Fall verwendet werden.

Cheatah

[Andreas Korthaus]

Hallo!

korrekt. Es ist keine Frage der Möglichkeit, sondern nur eine des Aufwandes - und den kann man mit einem einfachen kleinen Script, welches als nicht-transparenter Proxy fungiert, minimieren.

Was sind denn "[nicht] transparente Proxys"?

Grüße
Andreas

[Cheatah]

Hi,

Was sind denn "[nicht] transparente Proxys"?

Proxies, deren Existenz man sichtbar bemerkt. In diesem Fall meine ich URLs der Art "http://localhost/mein-proxy.cgi?url=http://...". Bei transparenten Proxies muss man in den Einstellungen nachsehen, um sie zu bemerken, vielleicht vom "hoppla, das war wohl der Proxy-Cache"-Effekt abgesehen.

Cheatah

[Christian Kruse]

Hallo Cheatah,

Was sind denn "[nicht] transparente Proxys"?

Proxies, deren Existenz man sichtbar bemerkt. In diesem Fall
meine ich URLs der Art
"http://localhost/mein-proxy.cgi?url=http://...". Bei
transparenten Proxies muss man in den Einstellungen
nachsehen, um sie zu bemerken, vielleicht vom "hoppla, das
war wohl der Proxy-Cache"-Effekt abgesehen.

Tatsaechlich sind 'transparente Proxies' *wirklich*
transparent ;) Die werden in der Regel ueber Firewall-Regeln
benutzt. Heisst: der User kriegt davon gar nichts mit, es sieht
fuer den Browser so aus, als sei kein Proxy dazwischen und er
kommuniziere direkt mit dem Host. Freenet macht(e?) sowas, z. B.

Gruesse,
 CK