Hijacking und dadurch DC immer noch ein Problem, oje... ;)

Beitrag von **SloMo** » 24.10.2005, 10:49

Airport1 hat geschrieben:Man kann natuerlich auch Keep-Alive auf ON setzen und Anfragen wo abzusehen ist dass sie nur 1 Request lang andauern mit connection: close begluecken.

Ich meine gelesen zu haben, dass connection:keep-alive Voraussetzung dafür ist, keep-alive:xxx setzen zu können. Damit würde der gleichzeitige connection:close flachfallen. Also bräuchte man bei Keep-Alive immer mindestens 2 Requests, nämlich connection:keep-alive gefolgt von connection:close. Naja, das sind Details und liegen meilenweit neben dem Thema.

Warte immer noch auf die Loesung des AnjaK Mystic-Raetsels, waere naemlich zu schoen wenn das SO ginge

Geht nicht... und ich bezweifle, dass jemals ein keep-alive:302 empfangen wurde. Wahrscheinlich war die 302 nur in irgend einem kryptischen Cookie oder so.

Weißt Du zufällig, ob eine 301-Weiterleitung zur gegenwärtigen Url von den Clients ignoriert wird? Also 301 von https://www.example.com/ nach https://www.example.com/ ? Ich glaube zwar, dass es nicht ignoriert wird, sondern zur endlosen Weiterleitung führt. Aber falls es ignoriert wird, könnte man den bots dadurch vielleicht einbläuen, dass der letztendliche Status doch ein 301 ist.

Gruß, SloMo

von **Anzeige von ABAKUS** »

Hochwertiger Linkaufbau bei ABAKUS:

Google-konformer Linkaufbau
nachhaltiges Ranking
Linkbuilding Angebote zu fairen Preisen
internationale Backlinks

Wir bieten Beratung und Umsetzung.
Jetzt anfragen: 0511 / 300325-0

Beitrag von **KeepCool** » 24.10.2005, 10:52

Hallo,

Ich glaube, Ihr habt Euch bei dem Thema 302-Trap vergaloppiert:

a. Nehmen wir an, Eure Seite ist MeineSeite.com
b. Der 302-er-Link auf einer Präsenz ist 302domain.com/302link-id123.php
c. Der Link aus (b) leitet mit 302 auf MeineSeite.com

Ein Client (sei es Browser oder Spider), klickt auf (oder verfolgt) den 302-er Link --> daraufhin bekommt der Client den 302-er und wird auf MeineSeite.com umgeleitet.

Der Server von MeineSeite.com *** sieht niemals einen 302-Header *** des Clients, sondern maximal die Referer-URL (in diesem Fall 302domain.com/302link-id123.php)...und das nur wenn KEIN Proxy, Ofuscation, etc. dazwischen ist...

Die einzige Möglichkeit wäre dann, die Header der Referer-URLs (falls gespeichert) nachträglich abzurufen und auf 302 zu untersuchen...

Nochmal: Woher soll der Server von MeineSeite.com den 302-er-Header herbekommen ? Von einem Browser oder von einem Spider wohl kaum.

@Airport1

Ich denke, Du studierst irgendetwas mit Informatik; da würde es Sinn machen, etwas zwischen client- und serverseitegen Abläufen unterscheiden zu können...Von den Mechanismen der Header-Übergabe ganz zu schweigen...

Gruss,

KC

Beitrag von **Airport1** » 24.10.2005, 11:08

KC: dann musst Du erst mal lesen lernen, denn genau das mache ich ja, ich rufe die URLs nachtraeglich auf, lese sie ein und schaue mir die Antwort an. Nur ist das keine wirkliche Loesung, da der Referer seltenst der der tatsaechlichen Weiterleitungsseite ist, also fass Dich an die eigene Nase

Nochmal fuer kleine Nicht-Lesen-Koenner *fg* :
ich habe bspw. eine seite www.hase.de/katalog.php
auf der sind redirect links verbaut z.b.

goto.php?ashdf
goto.php?dsfiusdiu3

klickt der user nun darauf wirf nicht etwa als referer goto.php?dsfiusdiu3 geschickt sondern www.hase.de/katalog.php .

Das ist der eigentliche Knackpunkt: ich muesste theoretisch auch noch alle Links dieser Seite ueberpruefen. Das ist lastig ohne Ende.

von **Anzeige von ABAKUS** »

Beitrag von **SloMo** » 24.10.2005, 11:10

KeepCool hat geschrieben:Die einzige Möglichkeit wäre dann, die Header der Referer-URLs (falls gespeichert) nachträglich abzurufen und auf 302 zu untersuchen...

Nope, es wird im Referer nicht die Forwarder-Url geliefert, sondern lediglich die Url der Seite vor dem Forwarder. D.h. Du musst alle Links der Referer-Seite verfolgen, und prüfen, ob einer dieser Links per 302 zu Deiner Seite weiterleitet.

Das hatten wir oben schon.

Gruß, SloMo

Edit: Da war ich wohl zu langsam

Edit2: Das taugt auch nicht als 302-Trap, sondern bestenfalls als Benachrichtigungs-Mechanismus. Dann müsste man die 302-Verursacher um Entfernung des Link bitten.

Beitrag von **Airport1** » 24.10.2005, 11:21

Nochmal fuer alle, denen es noch nicht klar ist:

Der 302 wird an der Quelle generiert, an der Stelle wo umgeleitet wird, aber das Ziel weiss nicht(s davon) dass es ein 302er war.

Das glauben viele erst mal gar nicht, der Gegenbeweis darf SEHR gerne angetreten werden

Beitrag von **Airport1** » 24.10.2005, 11:27

Selbst in den Apache Logs steht nur die Request Method (aber NICHT der Request HTTP Code), der einzige HTTP Code der dort abzulesen ist ist die ANTWORT des eigenen Servers

Beitrag von **KeepCool** » 24.10.2005, 11:55

@SloMo

Links der Referer-Seite verfolgen, und prüfen, ob einer dieser Links per 302 zu Deiner Seite weiterleitet.

...nichts Anderes habe ich gesagt...Header der Referer-URL reicht schon zur weiteren Untersuchung...

@Airport1

Sorry, hatte Deine Ausführung nicht aufmerksam gelesen; ja, ja, das Alter...

Ging mir darum, zu betonen, dass 302-er - clientseitig - nicht "durgeschliffen" / übergeben werden.

PS: Bei einem ev. vorliegenden Metarefresh ist es ja noch aussichtsloser...

*Hast Du KONKRETE Hinweise, dass die von Dir erwähnten Präsenzen per "302 gehijacked" worden sind, oder könnten auch sehr wohl noch andere Faktoren zur Herabstufung geführt haben ? (Canonical URL, internal DC in Massen, etc.) ?
Die Tatsache, dass eine andere Seite (oder mehrere) unter dem eigenen namen *oben* besser gelistet ist (sind), reicht nicht für einen 302-Verdacht.

Aufgrund der "alten Ergebnisse", könnte es schon sein, dass derzeit dieser Verdacht nochmals aufkommt; wenn der Index bereinigt ist, sollte dieses Problem endgültig der Vergangenheit angehören...

Gruss,

KC

Beitrag von **Airport1** » 24.10.2005, 12:15

Auch witzig: der IE liefert u.U. den Referer "1 Ebene/Seite in der History zu spaet", der Opera liefert u.U. den Referer "1 Ebene/Seite in der History zu frueh", abhaengig von den Aufrufen (z.B. GET / POST Formular, normale Links oder via javascript). Wenn nur einer den Referer wirklich an Punkt 0 liefern wuerde, dann waer das ja schon mal die halbe Miete .. seufz

Beitrag von **AnjaK** » 24.10.2005, 14:18

hab deinen Code mal probiert Bull, ich bekomme einen Keep-Alive 300.
Gebe ich den Code im Firefox aus, erscheint dort in etwa 70% aller Fälle ein 302.
Warum, das weiß der Geier, vielleicht meine Firewall? Ich weiß et nit....
Jedenfalls bin ich scheinbar meinen eigenen Scripten auf den Leim gegangen *schäm*

Ich nehme daher alles zurück und werde eine Runde "Dummes Huhn" vor dem Spiegel spielen

Aber auch mein Provider kann sich die 302 nicht erklären, er meint auch, dass da nur 300 stehn kann, aber niemals 302.

Aber dennoch denke ich dass die 301er Methode funktioniert!
Gut, man kann nun einen Kreisverkehr nicht mehr ohne weiteres ausschließen, aber da gibts ja Abhilfe.

Den GoogleBot kann ich ja erkennen.
Wenn nun der Googlebot auf die Startseite kommt, dann speichere ich irgendwo eine temporäre Variable zwischen. Solange diese Variable nicht gesetzt ist, wird der Bot per 301 auf die gleiche Seite geleitet. Da nun die Var gesetzt ist, wird der Bot beim 2. Mal nicht weitergeleitet. Die Variable kann nun wieder gelöscht werden.
Ich muss also gar nicht den 302 prüfen, ich muss nur den Googlebot jedesmal per 301 einmal im Kreis laufen lassen. Das sollte meinem Verständnis nach das Problem beheben, auch ohne 302 im Headerdatenstrom. Das müsste dann 100% aller Fälle abdecken, incl. meta-refresh.

Oder seh ich das falsch?

Beitrag von **Fox Mulder** » 24.10.2005, 14:39

AnjaK hat geschrieben:Oder seh ich das falsch?

Leider ja. Du verlängerst so nur die Weiterleitungskette. Die Zuordnung Hijackerseite zu Deinem Dokument bleibt trotzdem.

Gruss

Beitrag von **AnjaK** » 24.10.2005, 14:54

@Fox

Aber eigentlich müsste das dennoch funktionieren.

Google bekommt nen 302er und denkst so, dass die Zielseite zu der aufrufenden Domain gehört. Kommt der Bot nun auf meine Seite, denkt er, er wäre immernoch auf der 302er Seite. Wenn ich nun aber eine 301 "verheadere" dann denk Google doch, dass die Seite umgezogen ist und nun nur noch unter der Zieladresse erreichbar ist.
Zumindest war das bislang mein Verständnis von diesen beiden Header.

Beitrag von **SloMo** » 24.10.2005, 16:11

Das hängt allerdings von der Implementation der Bots ab. Wenn ein Bot sich nur einen einzigen Status merkt, und dieser Status immer der letzte Status der gesamten Weiterleitungskette ist, dann funktioniert das vielleicht. Die Überprüfung und Beweisführung dürfte allerdings eher schwierig sein.

Gruß, SloMo

PS: Es wäre aber anders herum logischer, denn wenn ich von A nach B eine temporäre Umleitung mache, dann bleibt die Verbindung A->B auch dann temporär, wenn B dauerhaft nach C umleitet. Die erste Umleitung bestimmt also den Charkter der gesamten Umleitungskette.
@AnjaK: Soll heißen, falls Dein Mechanismus funktioniert, würde er auf einem Googlebug beruhen.

Beitrag von **AnjaK** » 25.10.2005, 19:01

<< @AnjaK: Soll heißen, falls Dein Mechanismus funktioniert, würde er auf einem Googlebug beruhen.

Wäre ja nicht der erste Mechanismus, der auf sowas aufbaut

Aber selbst wenn sich der Bot alle Statusse (Stati? Startussis?) merkt, wird es sicherlich so sein, dass der letze zählt. Alles ander wäre eigentlich auch unlogisch, wozu sollte der Bot sowas tun. Um was herauszufinden? Letzendlich zählt doch die Information, welche dem Bot den Weg des geringsten Widerstandes zeigt, das ist doch Sinn der Sache. Der Bot tut doch das nicht um die SEOs zu ärgern sondern um relevante Suchergebnisse zu nennen.

Wenn ich die Post von hier zum Nachbarort leite mit Umweg über alle Städte der Welt, wird die Post letzendlich hier bei mir ankommen. Das nächste Mal denkt sich die Post "bin ich deppert? Ich geh doch nicht den ganzen Weg durch die Ganze Welt, wenn ich doch nun weiß, dass der Empfänger direkt nebenan wohnt".

Und so denke ich, dass auch der Bot so "denkt". Er bekommt als letzes einen 301er und damit ist für ihn klar, dass er in Zukunft nur noch den direkten Weg geht. Damit spart er sich Mühe und Zeit. Warum sollte er immer wieder über die 302er-spendenden Links gehen, wenn er es doch einfacher haben kann, was man ihm per 301 mitteilen kann.

Ich denke schon, dass das klappen kann.

Beitrag von **Dusti** » 26.10.2005, 19:22

Hmm *grübel*

@AnjaK:
Also wenn ich Dich richtig verstehe, dann möchtst Du G-Bot beim ersten Zugriff auf eine Seite (und von dort an jeden zweiten Zugriff) genau auf dieselbe Seite per 301 Umlenken?

tja, ist wohl eine gute Frage was sich G-Bot dann "denkt". Vielleicht fühlt er sich ja auch verschaukelt, wenn eine Seite auf sich selber umgeleitet ist? Wenn x.tld/a.html auf x.tld/a.html per 301 Umleitet, dann denkt er vielleicht, man wolle ihn in eine Endlosschleifenfalle locken und verschwindet erstmal wieder?
Warum sollte G-Bot auf die Idee kommen, die Seite ein zweites mal direkt danach erneut zu lesen, wenn er sowas findet? Aber wer weiss schon, was in G-Bot so vorgeht

Allerdings vermute ich mal, wird G-Bot immer die letzte Version einer Seite die er findet für gültig halten. Wenn er beim zweiten mal die Seite ganz normal bekommt, wird er vermutlich davon ausgehen, dass die alte Version mit dem 301er durch die neue, normale Version ersetzt wurde.
Die Seite mit dem 302er hat sich aber nicht geändert, so dass er die Beziehung zwischen beiden Seiten vermutlich auch wieder genauso wie vorher auch einschätzen wird (also der Hijack-Bug bestehen bleibt).

Aber damit das mit dem "Merken per Variable" geht, müsste man sich doch auch die genaue Seite und die IP des G-Bots merken, oder?
Ansonsten stelle ich mir das chaotisch vor, wenn die cawler im Rudel kommen. Also zumindest bei mir kommen oft mehrere crawler gleichzeitig und teilen sich die Arbeit, in dem sich jeder andere Seiten anguckt. Ich vermute mal, bei euch wird es ähnlich sein.
Wenn sich crawler A dann Seite x anschaut und den 301er bekommt, und crawler B dann Seite y anschaut bevor der andere Crawler sich wieder Seite x ansieht ja ebenfalls ein 301er bekommen.
Also müsste man es schonmal seitenabhängig machen.
Und was ist, wenn Crawler A sich Seite x anschaut, aber dann erstmal auf Grund der vermuteten Endlosschleife (oder weil ihm einmal nach der Seite schauen für eine Zeit erstmal reicht) sich erstmal Seite b widmen will? Dann müsste er dort ja erstmal ebenfalls einen 301er bekommen.
Das ganze lässt sich noch beliebig verkomplizieren, so dass man sich eigentlich genau den Crawler und die Seiten merken müsste.
Aber da die Crawler keine komplett eigenständigen Einheiten sind, sondern sich untereinander "absprechen" bzw. die Arbeit teilen, wird es eigentlich ganz unmöglich nachzuvollziehen wann man dann den 301er senden müsste. Wenn erst Crawler A mal auf Seite x einmal nachschaut, und nach beliebiger Zeit Crawler B mal nachchauen will was nun mit Seite x ist, willst Du dann diesen Zugriff noch als zugehörig zum ersten von Crawler A zählen oder lieber doch nicht?

Bevor ich mir noch weiter das Gehirn verrenke und mich dann nachher komplett selber verwirre:
Google wird doch vermutlich immer die letzte Version einer Seite die es findet für die nun gültige Version halten (alles andere macht ja auch irgendwie keinen Sinn). Als letztes (oder besser: Jedes 2. mal) findet er immer die "normale" Version, also die ohne 301er.
Damit wird das ganze doch komplett wirkungslos, oder?

Im schlimmsten Fall wertet er Deine Seite vielleicht sogar ab, weil sie dauernd abwechselnd mal Content und mal einen 301er enthält (und dazu noch so einen auf sich selber). Eventuell stuft Google das dann auch als (schlecht funktionierende

) Cloaking-Seite ein.

Bitte meinen Beitrag nicht falsch verstehen: Er ist nicht negativ gegen Dich oder Dein Vorhaben gemeint. Im Gegenteil, es wäre schön etwas wirkungsvolles gegen diesen 302er-Bug zu finden, und ich finds es gut dass Du uns an Deinen Experimenten und Überlegungen dazu teilhaben lässt.
Ich sehe halt nur nicht, wie diese Methode überhaupt funktionieren könnte. Eher nur, dass sie Deiner Seite bei Google sogar schaden könnte.

Aber wer weiss, vielleicht finden wir hier in diesem Forum ja doch mal eine Methode sich gegen diesen Bug zu schützen. Oder was noch schöner und einfacher wäre: Vielleicht schafft Google es endlich mal den zu beheben *träum*

Beitrag von **AnjaK** » 26.10.2005, 21:51

Ich glaube dass du zu kompliziert denkst. Google macht es (meine Meinung nach) nicht anders als die Natur: Gehe den Weg des geringsten Widerstandes. Wenn es Google NICHT so macht, sind es Looser und brauchen neue Programmierer

Nein, aber mal im Ernst:

a) kommen nicht mehrere Googlebots gleichzeitig, da dies ein Multiprozessing des Server voraussetzen würde. Es wird also jeder Bot sequentiell abgearbeitet, zwar im Nanosekundenbereich, aber dennoch sequentiell. Daher kommt schön ein Bot nach dem anderen. Aber das ist eigentlich auch unerheblich denn der Bot kommt ja immer nur auf EINE Seite, nämlich die Seite, die der 302er verlinkt. Was er danach macht ist nicht mehr von Belang, denn alles was danach kommt zählt er ja dann (im Idealfall) zu meiner Seite und nicht mehr zu dem 302-Spendierer.
Ok, der Redirect auf sich selber könnte vom Bot als merkwürdig empfunden werden, zugegeben. Aber auch hier gibt es Abhilfe. Statt auf sich selber zu verlinken, schicke ich ihn einfach ins Impressum. Idealerweise findet er von dort natürlich selber wieder zurück zur Startseite. Somit wäre es keine Botverarschung sondern eine ganz normale 301er Umleitung. Der Bot denkt dann nicht "Startseite existiert nicht mehr da 301 aufs Impressum", sondern er findet (über DIESEN LINK) die Startseite gar nicht, sondern der Link geht für den Bot (da über htaccess gesteuert) direkt ins Impressum. Und da er per 301 dort hingeleitet wird, gehört die Seite ab da wieder mir.

Ich halte daher noch immer dran fest, dass dies funktionieren kann, ich bin fast sicher, dass mein etwas unbeholfener Weg über die Header durch Zufall einige dieser 302er geknackt hat, jedenfalls legen meine Auswertungen diesen Verdacht nah.

Jetzt wäre mal wieder der Zeitpunkt gekommen, meine Seite "www.ich-bin-ein-spammer.de" zu hijacken, damit ich das dort testen kann, das Letzte Mal hat leider nicht so richtig geklappt mit dem Hijacken.