Cheatah: nochmal zum Referer

Beitrag lesen

Hi,

Okay, techn. habe ich es nun verstanden. Aber wo sollte der generelle Sinn liegen, das zu machen?

wo liegt der generelle Sinn, einen falschen User-Agent vorzutäuschen?

Einmal gibt es den Standpunkt: "Außen soll man nicht wissen, was sich innen tut." Darum haben Programme wie der WebWasher meist die Möglichkeit, solche Header vorzugeben.

Andererseits gibt es schlecht(!) erstellte Seiten, bei denen die Funktionalität von bestimmten Headern abhängt - deswegen konfigurieren viele Lynx-User ihren Client so, daß er sich als "Mozilla" ausgibt; andernfalls werden sie von diversen Seiten ausgesperrt, nur weil der Webmaster keine Ahnung hatte.

Wenn mir jemand die URL einer Grafik auf members.xoom.com gibt, nehme ich beispielsweise schnell ein Script von mir zur Hand, trage Location und Referer gleich ein und bekomme die Grafik zu sehen, anstatt eines Xoom-Logos. _Das_ ist der generelle Sinn, nämlich den Unsinn zu umgehen.

Wenn ich bspw. irgendwo was ausfüllen soll, suchen will...schickt mich das CGI-Script zum "Teufel" wenn der Referer nichts im geringsten mit der Domain zu tun hat, sofern es der Programmierer will.

Dann hat der Programmierer geschlampt und nicht beachtet, daß sein Script viele Leute ausschließt - ganz einfach.

Für mich liegt darin (im Gegensatz zum js-Referer) auch kein Sicherheitsrisiko.

Solange Leute aus Sicherheitsgründen Cookies deaktivieren, wirst Du mit diesem Argument nicht weit kommen.

Übrigens ist der HTTP-Referer mit dem JS-Referrer identisch; nur daß es bei Grafiken etc. keinen JS-Referrer gibt, weil Grafiken keinen JS-Code enthalten können. Der Unterschied liegt darin, daß der JS-Referrer lokal vorliegt, während der HTTP-Referer versendet wird - letzterer ist also genaugenommen das höhere Sicherheitsrisiko, wenn es denn eines gibt.

Da aber CGI (normalerweise) für Prozesse wie Suchen, usw. verwendet wird, das entspr. Suchformular meist in der gleichen Domain hängt, liegt es hier (in der Praxis) anders, da das Script ja wohl prüfen will, ob die Daten wirklich aus der eigenen Domain kommen.

Eine Sessionvariable zu vergeben, die an die IP geknüpft ist, ist dabei das deutlich geeignetere Mittel, weil diese übertragen wird - sofern keine bewußte Manipulation vorliegt.

< http://www.w3solutions.de>

Aeh... und was ist da?

Tja, nix....:-)

Stimmt. Es ist eine Kontaktadresse da, aber mehr auch nicht.

Warum um alles in der Welt schaltest Du da eine Umleitung vor, die clientabhängig ist? Die nachfolgende Seite jedenfalls funktioniert problemlos ohne; und wenn sie es nicht täte, wäre sie schlecht gemacht.

Außer einem Script, was versucht, den Referrer herauszubekommen. Wenn es wirklich jemand schaffen sollte, den gezielt zu zerhackstückeln, könnte ich es eben hier sehen. Sonst nix!

Was meinst Du mit "gezielt zerhackstückeln"? Wo genau greift das Script, wann gibt es ohne Referer welches Ergebnis, und was möchtest Du genau sehen? Unter Umständen kann ich Dir einen Link geben, der auf ein Script von mir verweist; je nachdem, was Du eigentlich sehen willst.

Aber, ob das in der Praxis sehr oft vorkommt (siehe oben: Frage nach dem Sinn), wage ich zu bezweifeln!

Nein, eher selten, das stimmt. Aber von einem ausreichenden Prozentsatz, um beachtet zu werden.

Ich glaube es noch immer nicht ganz. Wie funktionieren denn Eure Zähler dann, wenn Ihr noch nicht mal wißt, woher der Scriptaufruf stammt???

Parameter! Oder aber Serverlog, dem ist es eh egal, ob ein Referer übermittelt wird oder nicht.

Cheatah